Die, Die My Darling: a GAC alternative

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.

<runtime>
<assemblyBinding xmlns=”urn:schemas-microsoft-com:asm.v1″>
<dependentAssembly>
<assemblyIdentity name=”nBaked” publicKeyToken=”2a6f8gc6611eh9s1″ culture=”neutral” />
<codeBase version=”1.0.0.0″ href=”file:///C:/nBaked/bin/nBaked.dll” />
</dependentAssembly>
</assemblyBinding>
</runtime>

About Jeremy Mullinax-Hill

I am a lead/senior developer with more than 10 years experience in both the public and internal applications for Fortune 500s and mid-sized View all posts by Jeremy Mullinax-Hill

3 responses to “Die, Die My Darling: a GAC alternative

  • Farrukh

    What about using RegAsm? I guess, you can put your assemblies in a separate folder and use RegAsm /CodeBase to register these. You don’t need GAC here.

    http://msdn.microsoft.com/en-us/library/tzat5yw6.aspx

  • matt

    This solution seems far harder to maintain then just using the gac.

    Farrukh, RegAsm is for registering objects with com so different type of registration.

  • Eric

    I see one slight issue with this approach. A great benefit of the GAC is that a new version of an assembly can be registered and all dependant applications redirected, with a policy, to use the new version. If assemblies were to remain un-registered and referenced via path at the application level web.config, as the solution conveys, the web.config of every consuming application would then require an update for the new version. There is also the problem of assemblies that depend on other assemblies that an application itself does not necessarily use; you’ll have to include all the binding information for the dependencies’ dependencies. A better approach to your solution would be to place the binding information in the framework or root web.config so that only one place would require an update. If an application requires a different version, simply override it in the local web.config.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: