Shared Assembilies and Strongly Named Assemblies

　　the .NET Framework has in place to deal with versioning problems.

Two Kinds of Assemblies, Two Kinds of Deployment

　　weakly named assemblies 、 strongly named assemblies

　　same:use the same portable executable (PE) file format, PE32(+) header, CLR header, metadata, manifest tables, and Intermediate Language (IL).use the same tools, such as the C# compiler and AL.exe

　　different:strongly named assembly is signed with a publisher’s public/private key pair that uniquely identifies the assembly’s publisher.it allows the assembly to be deployed anywhere on the user’s machine or even on the Internet.allows the CLR to enforce certain known-to-besafe policies when an application tries to bind to a strongly named assembly

 

　　be deployed in two ways: privately 、 globally

　　

Giving an Assembly a Strong Name

　　qustion：Two (or more) companies could produce assemblies that have the same file name. Then, if both of these assemblies get copied into the same well-known directory, the last one installed wins, and all of the applications that were using the old assembly no longer function as desired. (This is exactly why DLL hell exists today in Windows, in which shared DLLs are all just copied into the System32 directory.)

　　answer：differentiating assemblies simply by using a file name isn’t good enough.The CLR needs to support some mechanism that allows assemblies to be uniquely identified.（strongly named assembly.

　　A strongly named assembly consists of four attributes that uniquely identify the assembly: a file name (without an extension), a version number, a culture identity, and a public key.

　　

　　standard public/private key cryptographic technologies(allows two companies to create assemblies that have the same name, version, and culture without causing any conflict.)

　　1.creating a strongly named assembly is to obtain a key(SN.exe)

　　　　SN –k MyCompany.snk

　　　　SN –p MyCompany.snk MyCompany.PublicKey sha256

　　　　SN –tp MyCompany.PublicKey

　　　　

　　2.signs the assembly with the private key, and embeds the public key in the manifest.

　　　　csc /keyfile:MyCompany.snk Program.cs

　　　　或者，using Visual Studio, you can create a new public/private key file by displaying the properties for your project, clicking the Signing tab, selecting the Sign The Assembly check box, and then choosing the <New…> option from the Choose A Strong Name Key File combo box.

　　

　　The AssemblyRef metadata information (obtained by using ILDasm.exe)

　　　　

The Global Assembly Cache

　　how to deploy this assembly and how the CLR uses the information to locate and load the assembly.

　　question：If an assembly is to be accessed by multiple applications, the assembly must be placed into a wellknown directory, and the CLR must know to look in this directory automatically when a reference to the assembly is detected

　　answer：This well-known location is called the global assembly cache (GAC). The exact location of the GAC is an implementation detail that is subject to change with different versions of the .NET Framework（%SystemRoot%\Microsoft.NET\Assembly）

　　an algorithm is used to generate the names of these subdirectories.should never manually copy assembly files into the GAC;instead, you should use tools to accomplish this task（GACUtil.exe）

　　Installing assemblies into the GAC breaks the goal of simple application installation, backup, restore, moving, and uninstall. So it is recommended that you avoid global deployment and use private deployment whenever possible.

Building an Assembly That References a Strongly Named Assembly

　　how to use CSC.exe’s /reference compiler switch to specify the assembly file names you want to reference.

　　If the file name is a full path, CSC.exe loads the specified file and uses its metadata information to build the assembly. As mentioned in Chapter 2, if you specify a file name without a path, CSC.exe attempts to find the assembly by looking in the following directories (in order of their presentation here):

　　1. Working directory.

　　2. The directory that contains the CSC.exe file itself. This directory also contains the CLR DLLs.

　　3. Any directories specified using the /lib compiler switch.

　　4. Any directories specified using the LIB environment variable.

　　The files in the compiler/CLR directory exist so that you can easily build your assembly,whereas the copies in the GAC exist so that they can be loaded at run time.

Strongly Named Assemblies Are Tamper-Resistant

　　Signing an assembly with a private key and embedding the signature and public key within an assembly allows the CLR to verify that the assembly has not been modified or corrupted.

　　1.the CLR uses the referenced assembly’s properties (name, version, culture, and public key) to locate the assembly in the GAC

　　2.the CLR looks in the application’s base directory

　　3.in any of the private paths identified in the application’s configuration file;

　　4.if the application was installed using MSI, the CLR asks MSI to locate the assembly

　　5.If the assembly can’t be found in any of these locations, the bind fails, and a System.IO.FileNotFoundException is thrown;if founded，its containing subdirectory is returned, and the file holding the manifest is loaded（assures the caller that the assembly loaded at run time came from the same publisher that built the assembly the code was compiled against.This assurance is possible because the public key token in the referencing assembly’s AssemblyRef table corresponds to the public key in the referenced assembly’s AssemblyDef table.）

Delayed Signing

　　When you’re ready to package your strongly named assembly, you’ll have to use the secure private key to sign it.

　　question：while developing and testing your assembly, gaining access to the secure private key can be a hassle.

　　answer：the .NET Framework supports delayed signing, sometimes referred to as partial signing

　　Delayed signing allows you to build an assembly by using only your company’s public key; the private key isn’t necessary.

　　will lose all of the tampering protection afforded to you because the assembly’s files won’t be hashed, and a digital signature won’t be embedded in the file.

　　develop your assembly by using the delayed signing technique:

　　1. While developing an assembly, obtain a file that contains only your company’s public key, and compile your assembly by using the /keyfile and /delaysign compiler switches.

　　csc /keyfile:MyCompany.PublicKey /delaysign MyAssembly.cs

　　2. After building the assembly, execute the following line so that the CLR will trust the assembly’s bytes without performing the hash and comparison. This allows you to install the assembly in the GAC (if you desire). Now, you can build other assemblies that reference the assembly, and you can test the assembly. Note that you have to execute the following command line only once per machine; it’s not necessary to perform this step each time you build your assembly.　　SN.exe –Vr MyAssembly.dll

　　3. When ready to package and deploy the assembly, obtain your company’s private key, and then execute the following line. You can install this new version in the GAC if you desire, but don’t attempt to install it in the GAC until executing step 4.

　　SN.exe -Ra MyAssembly.dll MyCompany.PrivateKey
　　4. To test in real conditions, turn verification back on by executing the following command line.
　　SN.exe –Vu MyAssembly.dll

Privately Deploying Strongly Named Assemblies

　　the GAC is usually secured so that only an administrator can install an assembly into it. Also, installing into the GAC breaks the simple copy deployment story.

　　you deploy assemblies into the GAC only if the assembly is intended to be shared by many applications.If an assembly isn’t intended to be shared, it should be deployed privately.

How the Runtime Resolves Type References

　　

Advanced Administrative Control (Configuration)

　　how an administrator can affect the way the CLR searches and binds to assemblies

　　how a referenced assembly’s files can be moved to a subdirectory of the application’s base directory

　　how the CLR uses the application’s XML configuration file to locate the moved files.

Publisher Policy Control

　　question：when a publisher fixes a bug in an assembly,the publisher would like an easy way to package and distribute the new assembly to all of the users.

　　answer：What the publisher needs is a way to create policy information that is installed on the user’s computer when the new assembly is installed.

　　packaged together with the new Some-ClassLibrary.dll assembly file and deployed to users.

　　1.create an XML configuration file

　　

　　2.assembly by running AL.exe as follows.

　　AL.exe /out:Policy.1.0.SomeClassLibrary.dll

　　　　　　/version:1.0.0.0
　　　　　　/keyfile:MyCompany.snk
　　　　　　/linkresource:SomeClassLibrary.config

　　the administrator would like to tell the CLR to ignore the publisher policy assembly：edit the application’s configuration file and add the following publisherPolicy element（<publisherPolicy apply="no"/>）.