Global Assembly Cache
The Global Assembly Cache (GAC) is a collection of assemblies on a pc/server which are available to any .net code running on that pc. I guess this is simillar to the old style of registering a com object. The GAC starts off with all the assemblies which come with the .net framework out of the box.
You can easily see existing GAC contents since they are simply stored in one folder which is in a folder called "assembly" which you will find in your windows folder. You can see a sample below:
Note that when you browse to this folder then windows explorer changes the way it behaves so that it has the appropriate layout and column headings etc.
The reality of the GAC folder is that there is more to it than meets the eye. If you examine this folder through a command prompt by Start, Run, Cmd then navigate to the assembly folder with something like CD\ then CD windows\assembly you can see what is actually there. You can look around the folder structure yourself or just type Tree to get an overview which will look something like below.
You will no doubt recognise some of the assemblies above eg System.Data. What we will now look at is writing our own assembly which we will then register in the GAC and finally consume from a client application. For this example I will be using Visual Studio 2005.
Ok so first we need to fire up Visual Studio and create a new class library project. This library will contain various validation utilities - eg testing to see if a string is a valid number, or date for example. I have called my project DACS.ApplicationBlocks.Validation. DACS is my company name and I envisage that I may have other Application Bocks - eg a data access layer so this seems a sensible naming convention.
Ok so to get things working we just initially need one working method. I have added a class called Tools which looks like this:
Ok so this is pretty straightforward - we have a Tools class with a static method for testing if a string equates to an integer - eg "45" does and "45x" doesn't.
If we compile this then it is almost ready to be registered in the GAC. First though we need to give our assembly a strong name.
A strong name uniqueley identifies an assembly. A strong name is not just the textual name of an assembly - it comprises of the textual name along with the version and culture information (if provided) — plus a public key and a digital signature. For a more in depth look at strong names see
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconstrong-namedassemblies.asp
To sign an assembly with a strong name, you must have a public/private key pair. This public and private cryptographic key pair is used during compilation to create a strong-named assembly. You can create a key pair using the Strong Name tool (Sn.exe).
One of the things which happens during compilation is that a unit of information is stored within the assembly manifest. This chunk of information contains some kind of hash of the entire assembly using some algorithm or other and is called the digital signature. This digital signature is encrypted using the private key. This enables client code which uses the assembly to tell if the binary code has been tampered with. This is done at run time. What I think happens is that the .net runtime can perform the same hashing algorithm and then compare this with the results which are encrypted. This is easily done as the digital signature can be decrypted simpy using the public key which is available in the manifest. If any malicious user or code did try and change the assembly then they would be unable to alter the digital signature correctly to match their changes as they wouldn't possess the private key to do so.
Key pair files usually have an .snk extension. To create a key pair at the command prompt, type the following command:
sn –k DACS.ApplicationBlocks.Validation.snk
When you execute this command you should use the Visual Studio Command Prompt which will know where to find the sn program:
Of course you don't have to use the Visual Studio command prompt - you can run the sn program from where it exists in the file system, or you can put it's location into the path environment variable but using the Visual Studio command prompt is nice and easy.
We will now need to tell our library project about this file. We do this by editing the AssemblyInfo.cs file. When you open this file you will see several existing assembly attribues.
We need to add one something like this:
[assembly: AssemblyKeyFile(@"G:\My Documents\Visual Studio 2005\Projects\DACS.ApplicationBlocks\DACS.ApplicationBlocks\DACS.ApplicationBlocks.snk")]
The location of the snk file goes in the above attribute so prior to doing this you may want to move this file to within your project folder structure if it isn't already there. Once we have updated the AssemblyInfo.cs file then we can compile the project in release mode and it will be given a strong name using the snk file.
Now we can add the assembly to the GAC. The easiest way to do this is to open two windows explorer windows. Point one at the assembly folder, located in your Windows folder wherever that was installed. Point the second explorer window at your dll which will be in the bin folder of your project. Make sure you use the Release version and not the Debug version. All you now need to do is drag the dll from the project window into the window showing the GAC and we are good to .
Now at this point any code which uses this dll will work on this pc as our assembly is now in the GAC. If we use Visual Studio to create a project which needs to reference this assembly then we still have some work to do. To get to this point lets create a new console project called GACClient. If you now right click on the References node in the solution explorer in Visual Studio and click Add Reference you will see the following:
You will see that our assembly isn't listed here. This becuase the list isn't populated by looking at the contents of the GAC folder. The list is populated in another way. To be honest I'm not sure where the entire list does come from but in order to get our assembly in there we can add it to one of the Visual Studio Folders:
E:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PublicAssemblies
In the above path Visual Studio was of course installed on drive E. There are other registry related ways of achieving this as well. A useful look at this can be found here:
http://weblogs.asp.net/jdanforth/archive/2003/12/16/43841.aspx
Whichever method you choose, you should now be able to add the assembly as a refernence. We can then use it in our Test Client project as follows:
using System;
using System.Collections.Generic;
using System.Text;
using DACS.ApplicationBlocks.Validation;
namespace GACClient
{
class Program
{
static void Main(string[] args)
{
string aNumber;
aNumber = "44";
Console.WriteLine(Tools.IsInteger(aNumber));
Console.Read();
}
}
}