Gallery

Managing assemblies

Posted on 20 Mar 2006 at 12:18

Thomas Lee delves deeper into the world of .NET assemblies and their deployment management in the enterprise

This approach allows developers to provide just the public key to the compiler(s) and switch off the detailed key checking during testing. Once each assembly is fully tested, a trusted administrator with access to the private key can sign them all. Typically, this would be done as part of the development organisation's release cycle. For more information on the al.exe and sn.exe commands, see the online SDK at msdn.microsoft.com or tinyurl.com

If you're an administrator managing the use of .NET applications, you're probably not going to be doing much signing or checking of signatures - for the IT pro, such low-level stuff is all pretty much taken care of by the developer. However, in order to make use of the Global Assembly cache, all the assemblies you manage must have strong names, so it's important to understand the basics of how this all works.

To illustrate this, I'm going to show you a simple client application that calls an external, strongly named DLL. Here's the client program:

using System;

public class client

{

public static void Main()

{Console.WriteLine("In Maths Client");

Maths m = new Maths ();

long r1 = 2;

long r2 = 2;

long r = m.Add(r1, r2);

Console.WriteLine ("2 + 2 = {0}", r.ToString() );

}

}

This application calls an externally defined class called Maths to perform simple addition. When you compile this application, you reference the assembly containing this class, and the compiler does the rest.

The external class, which at runtime is found in a separate DLL, looks like this:

using System;

using System.Reflection;

[assembly:AssemblyVersion("1.1.1.100")]

[assembly:AssemblyCulture("")]

public class Maths

{

public long Add(long a, long b)

{

Console.WriteLine("In Strongly Named Maths2.dll");

return a + b;

}

}

As you can see, the external class specifies its version number and culture using attributes, plus the key file to use as part of the compilation process. To compile these two bits of code using the built-in compilers, and then run the client application, the commands would look something like:

C:\PCPro>csc /t:library maths2.cs

C:\PCPro>csc /r:maths2.dll client.cs

C:\PCPro>client

In Maths Client

In Strongly Named Maths2.dll

2 + 2 = 4

C:\PCPro>

The strongly named assembly in this case resides in the same folder as the client executable. The simplest method of deploying this application and its supporting DLL would be to place them both in their own separate folder, independent of any other applications with the same name. To see the strong name created by the compilation of the maths2.sll, use ILDASM to view the assembly's manifest, where you can see the strong name, public key and version numbers of this assembly. If you were to use ILDASM to examine the manifest of client.exe, you'd see an external reference for maths.dll, and this reference would include the public key and the version number.

Global Assembly Cache

When you install the .NET Framework onto a PC, the installer creates a machine-wide assembly cache known as the Global Assembly Cache (GAC). You can use the GAC to store assemblies that are used by multiple applications, and a key requirement for any assembly you wish to place in the GAC is that it must have a strong name.