Q
Problem solve Get help with specific problems with your technologies, process and projects.

Loading assemblies from another directory without using Assembly.Load

Published: 10 Feb 2004
I have several .NET assemblies (dll) I've developed which I use in my applications. Every time I create new site, IDE copies them to a bin directory (since I declare it as Copy Local). When I deploy the application on production server, I have to copy all dlls from the bin directory on my computer to the proper directory on server. How can I tell the .NET framework to load assemblies from another directory, say c:myCommons without using Assembly.Load? Can I do it just by playing with enviroment variables or the registry or maybe some properties of .NET framework?
You can specify an alternate directory source for assemblies outside of the application directory structure by specifying a <codebase> setting within a publisher policy file. This requires you to strongly name your assemblies and you must specify the specific assembly version that the codebase binding applies to. The following application configuration shows how to locate version 1.0.0.0 of the ServerLib assembly in the c:\SharedDependencies directory: 
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
   <runtime>
      <assemblyBinding 
      xmlns="urn:schemas-microsoft-com:asm.v1">
         <dependentAssembly>
         <assemblyIdentity name="ServerLib"
                           publicKeyToken="ada0a9d1dd805043"
                           culture="neutral" />
         <codeBase version="1.0.0.0"
                   href="c:\SharedDependencies\ServerLib.dll"/>
       </dependentAssembly>
      </assemblyBinding>
   </runtime>
</configuration>
If you are trying to share assemblies between multiple applications, you should consider using the Global Assembly Cache (GAC), which removes the need for specifying a publisher policy to override how the runtime locates assemblies. The runtime always looks to the GAC first for an assembly. This also requires that assemblies are strongly named, but in general using strong names is recommended so that you can leverage version control and security features of the .NET runtime.

For sample code and a brief article related to this subject, see the following link:
http://www.dotnetdashboard.com/DesktopDefault.aspx?tabindex=13&tabid=89

Dig Deeper on Topics Archive

SearchSoftwareQuality
SearchCloudComputing
TheServerSide.com
Close