This is a common issue, where developers have some directory that stores their dlls and want their applications to reference that directory.
Assembly.Load is not really your answer, because when you compile your application, the compiler needs all the metadata of referenced libraries in order to use any of their methods. So when you compile, you would need to reference the dlls anyways, and the reference process makes a copy of the library in your local output directory.
The CLR documentation clearly stipulates:
At run time, a reference must exist in either the Global Assembly Cache (GAC) or the output path of the project.
Dynamically loading and unloading assemblies is an odd construct of Reflection. From an application standpoint, even if you got it to work, I would not recommend it as the solution just so that you can reference a common library. I believe its intent is geared towards memory management and the ability for a process to load/unload an (already referenced) assembly to/from memory as needed.
Is this just for one client, or for an application that will be distributed? If distributed, that gets complex, so I won't list all the scenarios here.
If just for one client, I would recommend one of two options (the GAC option was already posted)
- export your common library to the GAC.
- in your project, add the path to your common library to the Project properties:
How to: Set the Reference Path (C# , J#) - It will still copy those dlls to your output directory on each compile, but it will always retrieve the latest version from that common directory on each compile.