Gallery

Assembling assemblies

Posted on 17 Jan 2006 at 16:25

Thomas Lee looks at what .NET assemblies are made up from and shows you how to make them

Identifying Assemblies

An important feature of any runtime framework is that it can find the various files that contain needed components. In traditional Win32 programming, a program is identified by name only, so when a client program calls an external DLL, that DLL is identified by only the name of its file. If your Win32 app calls a library routine that some other app's installer later overwrites, your app may or may not work correctly - this crude feature of Win32 is not so fondly referred to in the business as 'DLL Hell'.

The .NET Framework addresses this problem by introducing the concept of a 'strong name'. In Win32, and by default in .NET as shown in the example above, assemblies are weakly named and just use the filename as a way of identifying a unit of code to load and execute. A strong name consists of four components: filename, assembly version, an optional culture name and a public key and associated digital signature. To create an assembly with a strong name, you have to carry out a few simple steps. First, you generate a key-pair using the strong name program sn.exe, which gets installed with the .NET SDK. In the .NET 1.1 and 1 frameworks, the key size was fixed at 1,024 bits, but in .NET Framework 2 you can have longer keys.

To create a key-pair with sn.exe, use the -k switch, specifying an output filename and an optional key length, as follows:

[MSH] C:\demo> sn -k 2048 pcprokey.snk

Microsoft (R) .NET Framework Strong Name Utility Version 2.0.50727.42

Copyright (c) Microsoft Corporation. All rights reserved.

Key pair written to pcprokey.snk

Once you've created the key-pair, you need to add attributes to the app's source. Attributes are special code statements placed in an app's source files that tell the .NET language compiler, among other things, how to create a strongly named assembly. For example, you can add the appropriate attribute for the version number into the maths.cs source file like this:

using System;

using System.Reflection;

[assembly:AssemblyVersionAttribute("1.2.3.4")]

public class Maths

{

public long Add(long a, long b)

{

Console.WriteLine("In strong named maths.dll");

return a + b;

}

}

Lastly, you need to recompile the application using the key you just generated, and then run it. This looks like:

[MSH] C:\demo>csc /t:library /out:maths.dll maths2.cs /keyfile:pcprokey.snk

Microsoft (R) Visual C# 2005 Compiler version 8.00.50727.42

for Microsoft (R) Windows (R) 2005 Framework version 2.0.50727

Copyright (C) Microsoft Corporation 2001-2005. All rights reserved.

[MSH] C:\demo>csc /r:maths.dll client.cs

Microsoft (R) Visual C# 2005 Compiler version 8.00.50727.42

for Microsoft (R) Windows (R) 2005 Framework version 2.0.50727

Copyright (C) Microsoft Corporation 2001-2005. All rights reserved.

[MSH]./Client.exe

In Client.exe

In strong named maths.dll

Result: 2 + 2 = 4

Finding Assemblies At Run Time

The CLR locates and binds to an assembly whenever one running assembly needs to use another, such as our client.exe app calling maths.dll. References are usually static, like client.exe's reference to maths.dll, but .NET enables you to create dynamic references on-the-fly using its reflection capabilities. The CLR locates the needed assembly, using the following steps:

The CLR examines all applicable configuration files, including the app configuration file, publisher policy file and machine configuration file. I'll cover these configuration files in next month's column, as they're important in deployment of apps.