Ask the Expert

Loading assemblies from another directory without using Assembly.Load

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?

    Requires Free Membership to View

    Login

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

This was first published in February 2004

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.
    Back to top