The Global Assembly Cache is an excellent feature and does provide a solution to prevent DLL Hell (if you are a software company with a release strategy that is). What about the rest of us that live in the real world with aggressive timelines and budgets. We have one release called “Production”. The GAC is a decent solution for the globalization of custom framework and helper assemblies for a suite of applications, but not the right solution for most of us, especially those in the corporate sector.
The Pros: globalized assemblies, supports multiple concurrent versions, assemblies usually run with full trust, can be installed/uninstalled with a setup project.
The Cons: cannot be xcopy deployed, gacutil is unreliable, must physically be on the machine as an administrator to install, IIS applications do not automatically restart after a DLL is published, complicates the development cycle.
What are the alternatives? If the GAC was all-that-and-a-bag-o-chips you wouldn’t see forum after forum post asking for ways to get around it.
All of my applications (ranging from ASP.NET to Windows Services) reference a fairly large central framework that handles database actions, caching, encryption, etc. Trying to copy this DLL around could mean deploying it to 25 or more different bin directories (and the list will continue to grow). This would have forced me to create a fairly robust automated deployment mechanism comprised of manifests and such. Yuck. My previous solution was to use the GAC — a very hard sell to someone like me in the first place. After months of compounding small frustrations, I decided to look for alternatives. The answer is surprisingly simple, yet nearly impossible to find searching the Internet.
Information on assembly binding can be found here: http://msdn.microsoft.com/en-us/library/0ash1ksb.aspx
Basically this will redirect JIT compiler to an alternate assembly file when it attempts to compile the library. There was one trick which threw me off for a day or two getting this to work. CodeBase only accepts an HREF not a file path. You must use the URL file path syntax you might see when accessing a directory through Internet Explorer. The benefits of this method are the same as using assemblies directly in the bin folder, but you only have to deploy to a single location. You can even point to different versions for different applications if necessary.
<assemblyIdentity name=”nBaked” publicKeyToken=”2a6f8gc6611eh9s1″ culture=”neutral” />
<codeBase version=”184.108.40.206″ href=”file:///C:/nBaked/bin/nBaked.dll” />