This question already has an answer here:
I am using EmguCV for a project and when our program runs it needs some dlls like "cxcore.dll" etc. (or it throws runtime exceptions). At the moment, I put the files in the root of the output folder (selected "Copy Always" in the file's properties in Visual Studio).
However it looks a bit messy, to have about 10 different dlls just there. Is there someway where I can move it to a subfolder in the output folder and it'll still find it.
You can keep it elsewhere and still link it. In the reference properties, set the "Copy local" to false and set the path accordingly. This will work. If the external DLLS are suppose to change version, you can set "Specific version" to false to be able to link to any version.
To get the assemblies in a sub-directory you can copy them there manually, use a pre- or post-build event or something completely different.
To load them, you can use the AppDomain.AssemblyResolve Event, or (as noted by TomTom) the
<probing>
Element. From MSDN:The GAC is of course another place to dump your assemblies, but that wouldn't really count as a sub-directory... unless you install your application somewhere it really shouldn't be installed :P
Amazing answers so far. None right ;) Well,
yes, you can put the assemblies in separate locations.
In the corresponding application config (
app.config
which gets copied toyour.exe.config
) add:According to:
http://msdn.microsoft.com/en-us/library/823z9h8w.aspx
This will make the program look into the private path (folders under it's own folder) for assemblies - much like a web application looks for /bin.
You can also put them into the GAC, but that should be avoided unless there are other reasons for this.
That being said, you really dont need to. Users wont get confused if you install the application properly in the start menu ;) I never had that problem, including projects with 50+ assemblies. Users simlpy never see them.
You can copy the dll's to the place you want using the pre/post build events, and the macros that telling you where your output folder is.
But, if the dll's are not in the same directory as the executable is, they won't be loaded. If they are managed, you can load them manualy using the Assembly.Load methods. If they are unmanaged, I don't know how you can do it.