Creating and Sharing .NET Assemblies For a .NET Application Projects

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace TestGACRegistration
{
    public class TestDLL
    {
        public string mymethod()
        {
            return "M1";
        }
    }
}

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace MyConsoleApp
{
    class Program
    {
        static void Main(string[] args)
        {
            TestGACRegistration.TestDLL testdll = new TestGACRegistration.TestDLL();
            Console.WriteLine(testdll.mymethod());
            Console.ReadLine();
        }
    }
}

Again the practices differ from team to team and project to project so there are no defined practices to be followed. It should always be considered based on what is best for the team.

To deploy the shared DLLs into the GAC, we need to generate a strong name first using sn.exe. More information on this can be found in the MSDN.

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

Now we need to generate a strong name in our example for the class library "TestGACRegistration" in order to deploy it to the GAC.

Go to the Microsoft Visual Studio command prompt and run the strong name key utility as below.

The key should be specified in the AssemblyInfo.cs of the class library. It will be available in the properties folder of the Class library project. Normally, the key would be copied into the organization's secured folder path and will be referenced.

Add the key attribute as below.

If you forget to add the key file attribute you would get an error during deployment.

Deployment

Now, after the coding is completed how can I deploy the shared DLLs in the GAC of the production server? The answer is we can do in two ways:

• Using a tool for registering the DLL in the GAC i.e., GACUTIL.exe
• Using a Microsoft setup project

We use the setup project option since we can add all the required DLLs in one shot and we can build and run the MSI file. The MSI file deploys the DLLs into the GAC without the GACUTIL.exe as it is intelligent enough to sense based on where the files are to be copied.

Add a new setup project to the solution and name it "SetupDLLs".

After the project is created right-click on the project and click "View | File System" and you see 3 project folders already present and so add another folder by right-clicking on the "File System On Target Machine" and select "Add Special Folder" and select the "Global Assembly Cache" folder. By default, any files that are copied to the "Global Assembly Cache Folder" will be deployed automatically by the setup project.

Now add the DLLs to be deployed to this special folder. In our case, we add only one. Now build the setup project. Let us see what happens if the strong name key was not added to the assembly. Just for testing purposes, I remove the key attribute in the "AssemblyInfo.cs" file and try to build the setup project again.

You would see an error if a shared assembly does not have a strong name specified. Now, revert back to the change and run the setup project again. You would see the following content in the output window now: ------ Pre-build validation for project 'SetupDLLs' completed ------

Build started: Project: SetupDLLs, Configuration: Debug

Building file 'C:\TestGACRegistration\SetupDLLs\Debug\SetupDLLs.msi'... Packaging file 'TestGACRegistration.dll'.

Build 1. succeeded or up-to-date, 0 failed, 0 skipped

Now you will see the two files are copied into the bin/release folder based on the mode you have built the setup project.

Now run the setup.exe and deploy the DLLs. You can manually run the exe file or run it from the command prompt. We do it manually, but if you would like to learn about silent installation, refer to the following URL:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa372024%28v=vs.85%29.aspx

After the installation is successful, you can go and check if the DLLs are successfully deployed to the GAC. The location of the GAC is normally C:\Winnt\assembly or C:\Windows\assembly.

You see now the DLL is successfully registered in the GAC.

Now we can test if this works. One question to ask is: If I change the class library code locally in my solution and build the DLL, does my console application refer to the new DLL?

The answer is No. If you have a DLL registered in the GAC with the same version as you have in your local application, always the one in the GAC is referenced. If you want to test the new code, you have to change the version of the DLL in your local application by changing the version in the "AssemblyInfo.cs" class located in the property folder of the class library. I have compiled the assembly with version 1.1.0.0 and deployed it in GAC for our example.

If you would like to test it, let us go and change the code in the method as below.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace TestGACRegistration
{
    public class TestDLL
    {
        public string mymethod()
        {
            return "M2";
        }
    }
}

Now my method should return "M2" instead of "M1" if the console application is referencing the local DLL. Now build the class library and run the console application to see the result.

Still, you see the output as "M1" only. If you want to test it more thoroughly you can delete the class library reference and add it to the console application project to test it and you see it always returns "M1" only.

Now I will change the version and test it again.

// [assembly: AssemblyVersion("1.0.*")]
[assembly: AssemblyVersion("1.2.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]

Now build the class library and add the reference to the new DLL/project for clean testing. You will now see the value displayed as "M2".

One drawback observed while using the setup project is you cannot uninstall the assembly from the GAC directly unless you uninstall the setup project instance in the computer. This helps in uninstalling the previous version and installing the new one. If we make new changes to the DLL and these code changes are made for only one of the application's purposes, then we would like the other applications with our new version deployment. If we want to do that, we need to change the upgrade code of the setup project and install another version of the same DLL. We all know GAC supports side-by-side execution of multiple DLLs having the same name and different versions.

In real-time, you might find more flexibility in deploying shared DLLs using the setup project.