How To Deploy Multiple Version of Component In GAC?

Scenario

I believe many programmers like to create shared component or common library in their work. When you see the code can be reusable and it is common for multiple different application, I am sure you will convert it into a framework and then apply them into your projects, so that you can save time from rewriting the same code for the same functionality again and again.

The most common way to deploy the shared component is to put the assembly into your application sub directory (the bin folder) and set the assembly reference in your application. The bad thing is it require you to do a lot of manual work by replicating and deploying the same assembly into every application sub directory.

Solution

We can deploy the shared component to Global Assembly Cache (GAC). Then, make your application reference the assembly from GAC.

Pre-requisite

Before you can deploy your assembly into GAC, you need to sign your assembly first. Just open up Visual Studio, go to your assembly project properties, then at the Signing page, check the "Sign the assembly" box.

Choose <New> from the drop down list to create a new strong name key file.

Simply put a key file name, and protect it with password (optional).

For testing, I have created a simple HelloWorld library to show the assembly version, and it will be used by multiple different application.

Folder Preparation

Create folders for your compiled assemblies for different versions.

Assembly Info

Set the assembly info in the project, and then compile it, finally put into the setup folder as above.

Set the AssemblyVersion and AssemblyFileVersion value for 1.0.0.0 and compile it and keep it into the folder for 1.0.0.0.

Now, make some code changes, then change the version value for 2.0.0.0, compile it and make sure not to overwrite the version 1.0.0.0 assembly file by placing them into different folder.

I changed the code to make it tells me its version is 2.0.0.0.

Installation

Open up Visual Studio Command Prompt. Change directory to where you keep the assembly files.

Run the gacutil.exe command with /i argument to install the assembly to GAC.

Verification

After the installation, you can check your assembly in GAC by running the following command:

gacutil /l HelloWorld

Add Reference

Now, change the assembly reference in your application from bin folder to GAC.

From the Add Reference dialog, you will not find your assembly from there. You have to click the Browse button and locate it from GAC assembly folder which is located at C:\Windows\Microsoft.NET\assembly\GAC_MSIL.

The assemblies in different version are being separated into different folder. The folder name convention is <.net version>_<assembly version>_<public key token>

Deployment

The assemblies installation to GAC is expected be done in both development and production environment. When the application reference the assembly from GAC in the development environment, it will do the same when it is deployed to production server.

Advantage

It is going to save time in deploying the same assembly file to every application and reduce human error. Sometimes developers forget to deploy the required assembly which is used by the application. They will notice it only when they failed to run the application.

Another reason is to save disk space. Instead of duplicating the same assembly into multiple different application sub directory (bin folder), you just have one copy from GAC and every application reference the same file.

Hmm, I find the above 2 advantages are just lame. :)

The good thing that I can think of is when all application are reference one same shared assembly source from GAC, when there is a bug fix for that assembly, you do not need to copy and replace the assembly in every application folder one by one. You can do a "on the fly update" by replacing the assembly in GAC, it will automatically apply the fix to all application which is using it.

The other good thing is side by side versioning. Sometime, you may encounter a situation when there are only a few application require the patch, the rest remain referencing version 1.0.0.0 assembly, those require patch will reference the new version 2.0.0.0 assembly. You can change the affected application assembly reference by using <codeBase> element in config file.

Will write more about using <codeBase> element in config file in my next post if I have time.