| A shared assembly is shared among multiple applications on a machine. The .NET Framework requires all shared assemblies to have a strong name. A strong name uses four attributes to identify an assembly: The .NET Framework provides special storage for shared assemblies in the form of the Global Assembly Cache (GAC). In addition to providing a shared location, the GAC provides an integrity check, security, and side-by-side versioning for shared assemblies. Assigning a Strong Name to an Assembly A strong name is a cryptographic construct that provides protection against tampering. To create a strong name, you need a key pair, which consists of a public key and a private key. You can create a key pair with the .NET Framework Strong Name tool (sn.exe), using the -k switch: sn -k KeyPairFile.snk When you create a strongly named assembly, the public key is stored in the assembly manifest along with other identification information, such as name, version number, and culture. To verify that only the legitimate owner of the public key has created the assembly, an assembly is signed using the publisher's private key. The private key is assumed to be known only to the publisher of the assembly. The combination of a public key and a private key is known as a key pair. Data encrypted with the private key can be decrypted only using the public key. It is also computationally infeasible to determine the private key if you know only the public key. The purpose of this public key cryptography is not to encrypt things so that they can't be decrypted. Rather, it is to encrypt them so that their origin is known. If you keep your private key private (as you should!), you can use it to produce messages that can come only from you. To create a strong name, you need an assembly's simple name, a version number, an optional culture identity, and a key pair. The key pair consists of two related pieces of binary data: a public key and a private key. The process of signing an assembly and verifying its signature works like this: Signing an assembly When you sign an assembly, a cryptographic hash of the assembly's contents is computed. The hash then is encoded with the private key and is stored within the assembly. The public key is stored in the assembly manifest. Verifying the signature When the CLR verifies an assembly's identity, it reads the public key from the assembly manifest and uses it to decrypt the cryptographic hash that is stored in the assembly. It then recalculates the hash for the current contents of the assembly. If the two hashes match, this ensures two things: The contents of the assembly were not tampered with after the assembly was signed, and only the party that has a private key associated with the public key stored in the assembly has signed the assembly.
After you create a key file containing the key pair, you can produce a strongly named assembly by using the AssemblyKeyFile attribute to reference that file (in a Visual Studio .NET project, this is done in the AssemblyInfo.cs file): [assembly: AssemblyKeyFile("KeyPairFile.snk")]  | An assembly signed with a strong name does not automatically verify a company's identity, such as its name. For that purpose, you can use an Authenticode signature, in which case the company's identity is verified. You can use the File Signing tool (signcode.exe) to attach an Authenticode signature to the assembly. An important thing to know is the order of commands when using both sn.exe and signcode.exe tools to sign an assembly. You must sign your assembly with the Strong Name tool (sn.exe) before you sign it with the File Signing tool (signcode.exe). |
Adding an Assembly to the GAC After you have associated a strong name with an assembly, you can place the assembly in the GAC. You can add an assembly to the GAC in several ways: Drag and drop the assembly to the GAC folder on your hard drive. This will be usually be C:\Windows\Assembly, but it might vary depending on your installation. Use the .NET Framework Configuration tool (mscorcfg.msc), and click the Add an Assembly to the Assembly Cache hyperlink. Use the Global Assembly Cache tool (gacutil.exe) to add an assembly to the GAC: gacutil /i MyAssembly.dll Run a setup package that uses Microsoft Windows Installer to deploy the assemblies to the GAC. This is the preferred method of adding assemblies to the GAC.
Binding Policy for Shared Assemblies For shared assemblies, the binding policy specifies where to search for the assembly and which to bind to the application. When the CLR searches a shared assembly, it goes through three stages of binding policy resolution: Application policy resolution At this stage, the CLR looks for an application configuration file for the binding rules. This configuration file can be used to specify additional search paths for an assembly. In addition, you can use this file to redirect the CLR to a specific version of an assembly. The application-specific binding rules are usually set either by the application developer or by an administrator. Publisher policy resolution The publisher policy is set by the publisher of a shared assembly to distribute service pack like updates to customers. For example, the publisher could redirect all applications to use version 1.1 of the assembly rather than version 1.0. By default, the binding rules specified in the publisher policy override the application policy. However, if you want an application to override the updates and continue using the existing versions, you can bypass the publisher policy file by specifying the <publisherPolicy apply="no"/> XML element in the application configuration file. Administrator policy resolution The binding rules at this stage are specified by the administrator in the machinewide configuration file named machine.config. This file is stored in the config subdirectory under the .NET Framework installation directory on a machine.
 | The settings specified in the machine configuration file override any settings specified in the application policy and the publisher policy. |
How the CLR Binds to a Shared Assembly The CLR uses the following steps to locate a shared assembly: The CLR first determines the correct version of the assembly by examining the application configuration file, the publisher policy file, and the machine configuration file in the order mentioned in the preceding section. The CLR checks whether the assembly is already loaded. If the requested assembly has been loaded in one of the previous calls, it binds to the already loaded assembly and stops searching any further. The CLR then checks the GAC. If the assembly is in the GAC, it loads the assembly from there, binds to it, and stops searching any further. If a <codeBase> element is specified in the configuration files, the CLR locates the assembly by using the paths specified in the <codeBase> element. If the CLR finds the assembly, the binding is successful; otherwise, the binding request fails and the CLR stops searching any further. The CLR follows the steps needed to probe for a private assembly, as explained previously in the section "How the CLR Binds to a Privately Deployed Assembly," to locate the assembly.
|
