I want a setup like this:
+- /ApplicationFolder
-- App.exe
-- Core.dll
-- AnotherShared.dll
+- /PluginsFolder
-- plugin1.dll
-- plugin2.dll
But because plugin1.dll references to Core.dll and Shared.dll when I compile the application it drops a copy of "Copy.dll" and "Shared.dll" to plugins folder as well and if I remove them it doesn't work any more.
How can I solve this problem?
When you create an AppDomain you can define a path for loading assemblies. Set AppDomainSetup.PrivateBinPath and pass to AppDomain.Create domain.
Using an AppDomain is a good idea for plugins (allows different CAS and unloading).
To avoid VS/msbuild copying referenced assemblies to the output directory, change "Copy Local" to false in the properties of the reference.
My MEF application is set up so that plugin projects compile to their own folder (as the is the default), then I use a post-build command to copy specific files to the output extensions folder.
The other way is to have the project build directly into the appropriate output folder and, as the other poster said, open the "Properties" panel for each relevant reference in your plugin project and set "Copy Local" to false.
you can try this: How can I set PrivateBinPath in MEF?
or you can try handling the Appdomain.AssemblyResolve event that is raised anytime .net cant locate an assembly. there you can implement custom logic to locate and load assemblies from anywhere.
the AssemblyResolve eventhandler jsut returns either the assembly that is beeing looked for or null, so you could return the already loaded Core.dll from available from the AppDomain.GetAssemblies() method.
however in your case it should be ok to simply not include Code.dll with plugin1.dll, .net should already realize that Core.dll is loaded and use that instance
