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

-a--- 2/4/2006 4:11 PM 1172 pcpro.snk

[C:\PCPRO]: ./client.exe

In Maths Client

In Strongly Named Maths2.dll

2 + 2 = 4

[C:\PCPRO]:

As you can see in this snippet, maths2.dll isn't now in the /pcpro folder, but when you call the client.exe application .NET finds it in the GAC, loads and executes it. See Knowledge Base 325682 for more information on the GAC, as well as msdn.microsoft.com or tinyurl.com. For more information about Gacutil, see tinyurl.com or tinyurl.com

Publisher Policy

It's often the case that the publisher of a software title needs to issue an update. However, with .NET and strong naming, this presents some challenges. Since each strongly named assembly is digitally signed, any change to its code would result in a different digital signature, so it isn't really possible to ship a new version of the called assembly alone.

Since there's a need for publishers to get updated modules to customers as quickly and painlessly as possible, Microsoft has implemented in .NET what's known as a publisher configuration file. Also known as 'publisher policies', these files provide a neat solution to the problem of safely and securely updating individual assemblies. A publisher configuration file is an XML configuration file that's wrapped as a separate assembly and installed into the GAC.

There are good reasons why Microsoft chose to deliver publisher policies as assemblies and not as raw XML files, the principal one being that it ensures that the publisher policy really did come from the publisher. This is achieved by requiring the publisher policy file to be signed with the same key as was used to create the original strongly named assembly. Since only the publisher has the original set of keys, only the publisher can issue an updated publisher file. This approach also provides the publisher with much flexibility, as he can issue updated publisher policies if an earlier one isn't correct for whatever reason. In general, publisher policies aren't meant to be used to ship new functionality, but should be, and generally are, restricted to security matters or urgent bug fixes.

If you look at the maths.dll file, suppose you had to ship an urgent update to it. You could create an updated source file such as:

// Maths3.CS - update for Maths2.dll

using System;

using System.Reflection;

[assembly:AssemblyVersion("1.1.2.100")]

[assembly:AssemblyCulture("")]

public class Maths

{

public long Add(long a, long b)

{

Console.WriteLine("In Updated Strongly Named Maths.dll");

return a + b;

}

}

If you compare this with the earlier version, you'll see two small changes (a version number change and a small change in the output). You'd compile this assembly as follows:

C:\PCPRO>csc /t:library /out:maths2.dll maths3.cs /keyfile:pcpro.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.

[C:\PCPRO]: ls maths2.dll

Directory: Microsoft.Management.Automation.Core\FileSystem::C:\PCPRO

Mode LastWriteTime Length Name

---- ------------- ------ ----