C# ПІДРУЧНИКИ / c# / MS Press - Msdn Training Programming Net Framework With C#

A Strong-Named Assembly

*****************************ILLEGAL FOR NON-TRAINER USE******************************

The client applications discussed in the preceding topics show the basics for constructing a complex program, but they are limited in that they only illustrate the use of assemblies that are private to the Client.exe and do not demonstrate the use of assemblies that are shared by more than one application.

This topic discusses the problems that may occur when multiple applications share components. It then introduces the use of strong names, the .NET Framework solution to these problems.

Issues with Sharing Components

Many applications use assemblies that are shared by more than one application. These shared assemblies, which are typically provided by third-party developers, are installed in a common location on the system, the global assembly cache. By default, the system looks for each application’s assemblies in the global assembly cache.

In classic COM and COM+ applications, the sharing mechanism depends heavily on the Windows System Registry in which information about each component, including its version and physical file location, is stored. This mechanism allows multiple applications to share a single component, but it also allows a component of a newly installed application to replace an existing component and possibly cause other applications to break.

Such overwriting of existing components is often difficult to detect because the application that is causing the problem appears to work properly.

Strong Names

In the .NET Framework, you can solve the problems that are caused by the sharing of components with multiple applications by more strongly associating a distinct build of a component assembly with the client application. A distinct build is indicated by a combination of a version number and a special value that is called the publicKeyToken.

Important Strong names provide a strong integrity check. Passing the .NET Framework security checks guarantees that the contents of the assembly have not been changed since it was built. Note, however, that strong names in and of themselves do not imply a level of trust, such as that provided by a digital signature and supporting certificate.

When component assemblies are associated with a distinct build, the system can isolate these component assemblies, thus allowing different versions to run at the same time for different client applications. This system of protection is sometimes called side-by-side execution. It differs from backward compatibility because with side-by-side execution, applications can run alongside other versions of the same applications without affecting their respective execution environments.

You can facilitate side-by-side execution by assigning strong names to your assemblies. A strong name consists of the assembly’s identity, which includes its simple text name, version number, and culture information, if provided, and a public key.

To demonstrate these additional build attributes the client and component scenario is extended by adding an assembly named AReverser. This assembly contains a class with a method that is named Invert, which uses the System.Array.Reverse method to reverse an array of strings.

Note The code details of AReverser are not relevant to deployment issues and therefore are not shown. This module’s lab contains the complete code details.

Building the Assembly Without a Strong Name

You begin by building the new component assembly without specifying any options to make it have a strong name. First, you compile the new AReverser assembly, as follows:

csc /target:library /out:AReverser.dll AReverser.cs

After compiling the new AReverser assembly, you can examine the metadata by using the MSIL disassembler. The MSIL disassembler indicates that the assembly does not have an established version number, as shown in the following code:

.assembly AReverser

{...

.hash algorithm 0x00008004

.ver 0:0:0:0

}

.module AReverser.dll

Generating a Public-Private Key Pair

To create an assembly with a strong name, you must compile the assembly by using a private key. Public keys are used for verification. Therefore, before compiling the assembly, you must first generate a public-private key pair. You use the Strong Name tool (Sn.exe) to generate a new key pair and place them in a file, as in the following example:

sn –k orgKey.snk

Compiling a Strong-Named Assembly

Now that you have a private key, you are ready to compile the component, specifying the key file and the version number to be assigned. You can do this by specifying AssemblyVersion and AssemblyKeyFile attributes in the AReverser.cs file using the STRONG conditional compilation symbol:

#if STRONG

[assembly: System.Reflection.AssemblyVersion("1.0.0.0")] [assembly: System.Reflection.AssemblyKeyFile("orgKey.snk")] #endif

You must then define STRONG in the compile process:

csc /define:STRONG /target:library /out:AReverser.dll! AReverser.cs

If you run the MSIL disassembler again on AReverser.dll, you can verify that the assembly is now strong-named from the presence of a .publickey property and a non-default version, which is specified by the .ver property of 1:0:0:0.

The following example shows the disassembled code:

.assembly AReverser

{

...

.publickey = (00 ... 71 8A 7D 6A D7 )

.hash algorithm 0x00008004

.ver 1:0:0:0

}

.module AReverser.dll

For more information about the Strong Name tool, see Packaging and

Deployment Tools in this module.

The output of this command is:

...

AReverser, Version=1.0.0.0, Culture=neutral, PublicKeyToken=!

0588613cb04b772e, Custom=null

...

You can also examine the system assembly cache by navigating to the \WindowsDirectory\Assembly directory and by using the cache shell extension.

Uninstalling a Strong-Named Assembly from the System Cache

Cleaning up applications that use strong-named assemblies requires more work than cleaning up the simple applications or componentized applications that are described in the preceding topics. In addition to deleting the executable files, you should remove the shared component file from the global assembly cache since the global assembly cache is not automatically scavenged.

To remove a shared component file, an administrator can use the cache shell extension, select the appropriate components, and delete them. Developers and administrators who want to automate the process, however, should use the command-line interface to the assembly cache manager as follows:

gacutil /u AReverser

To confirm the removal, you can view the contents of the global assembly cache by using the following command:

gacutil /l

For more information about installing and uninstalling shared assemblies to the global assembly cache, see Packaging and Deployment Tools in this module.

Each segment of this number has a specific meaning to the .NET runtime as it decides which version of an assembly to load. Logically, the compatibility version number has three parts, with the following meanings:

1.Incompatible

A change has been made to the assembly that is known to be incompatible with previous versions.

Example: Major new release of the product

2.Maybe Compatible

A change has been made to the assembly that is thought to be compatible and carries less risk than an incompatible change. However, backward compatibility is not guaranteed.

Example: Service Pack or release of a new daily build

3.Quick Fix Engineering (QFE)

An engineering fix that customers may want to upgrade to. Example: An emergency security fix

These three logical parts correspond to the physical four-part version number as follows:

For example, an assembly with compatibility version number 2.0.0.0 is considered incompatible with an assembly whose compatibility number is 1.0.0.0. Compatibility number 2.0.2.11 is considered a QFE to compatibility number 2.0.2.1.

You add the following to the AReverser.cs file in the AReverser_v2.0.1.0 subdirectory:

#if STRONG

[assembly: System.Reflection.AssemblyVersion("2.0.1.0")] [assembly: System.Reflection.AssemblyKeyFile("orgVerKey.snk")] #endif

You compile both of these versions by using the commands:

csc /define:STRONG /target:library! /out:AReverser_v2.0.0.0\AReverser.dll! AReverser_v2.0.0.0\AReverser.cs

csc /define:STRONG /target:library! /out:AReverser_v2.0.1.0\AReverser.dll! AReverser_v2.0.1.0\AReverser.cs

If you run the MSIL disassembler on these two updated files, you can verify that the assemblies are strong-named as indicated by the version number, 2.0.0.0 or 2.0.1.0, depending on which one you inspect with the MSIL disassembler.

Notice that these two assemblies have the same publickey property, but the value of this property is different than the previous version 1.0.0.0 AReverser.dll. This property is different because a different key pair was used, orgVerKey.snk, instead of orgKey.snk.

The following example shows the MSIL disassembler output for version 2.0.1.0 of the AReverser.dll:

.assembly AReverser

{

...

.publickey = (00 24 ... 82 B1 F2 A0 )

.hash algorithm 0x00008004

.ver 2:0:1:0

}