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

In earlier columns, I've looked at .NET assemblies, what they are and how you work with them, which included installing and using the .NET 2 Framework and the .NET 2 Framework SDK, as well as compiling some simple code. Last month, I showed you how ASP.NET works and how it can bring the benefits of .NET to the web programmer without increasing the management complexity. I also discussed the use of Visual Web Developer Express Edition for creating great ASP.NET-based websites. This month, I want to examine assemblies, in particular deployment management of assemblies in an enterprise environment, which includes the use of the NGEN utility, the Global Assembly Cache and publisher policies.

As you may recall, assemblies are self-describing units of functionality as well as being the key units of code deployment. An assembly contains executable code plus a 'manifest' that describes what's inside the assembly and what resources it needs from the outside. In most cases, an assembly's manifest is automatically generated by your .NET language compiler. You'd only need to worry about the manifest if you were trying to create a single assembly out of components produced by different compilers, which isn't common.

With ASP.NET, an individual web page either contains code that gets compiled into an assembly or a reference to a separate code-behind file containing code that's compiled into an assembly. Most developers are going to use one of two methods to create assemblies: either a text editor like Notepad and the C# or VB.NET compilers that come with .NET (or ASP.NET for web applications) or Visual Studio - the free Express editions or the full-blown commercial packages.

More on Strong Naming

As I mentioned in earlier articles, an assembly can have either a strong or a weak name. The weak name is just the filename of the assembly to be loaded, such as maths.dll, while the strong name includes the filename, a version number, culture and public key token. The developer defines the strong name by decorating the source code with attributes and additional coding statements. The strong name allows the .NET common language runtime (CLR) to perform two key tasks: first, it can verify cryptographically that the assembly hasn't changed since it was signed; second, it allows the CLR to be precise about exactly which assembly to load.

Microsoft uses asymmetric or public-key cryptography for signing assemblies, so in order to create the strong name you need a cryptographic key pair, generated by the sn.exe utility. To sign an assembly, the signer has to have the private key from this key pair, and this creates an issue of trust for administrators: do you really trust the signer? The more people who have access, the greater the potential risk of a rogue individual misusing the private key. As an admin, you have to ask yourself whether the development group can be trusted.

There are a couple of ways the development organisation can manage key pairs. You could issue all your developers with the key pair, enabling them to sign their code at compile time, but that's a potential security weakness, particularly once the number of developers with access to the private keys gets large. To reduce these risks, .NET supports delayed signing. In a fully signed assembly, .NET hashes the file that contains the manifest and signs that hash with the private key from the appropriate SN-based key pair. The resulting digital signature is stored with the manifest. With delayed signing, assemblies aren't signed at compile time, but instead .NET reserves space in the file so the signature can be added later. You sign the assembly later using the /delaysign+ and /keyfile options of the Assembly Linker (al.exe) command, a tool installed as part of the .NET Framework SDK.