Chapter III Shared assemblies and strong-Named assemblies

Directory:

3.1 Two types of assemblies, two deployments

3.2 Assigning strong names to assemblies

3.3 Global Assembly Cache

3.4 Referencing strong-named assemblies in a generated assembly

3.5 Strong named Assemblies tamper-proof

3.6 Delay Signature

3.7 Private deployment strong-Named assemblies

3.8 ' runtime ' how to resolve type references

3.9 Advanced Management Control (configuration)

3.1 Two types of assemblies, two deployments

The CLR supports two types of assemblies: weak-named assemblies and strong-Named assemblies

A strong-named assembly is signed with the publisher's public/private key. This pair of keys allows the assembly to be uniquely identified, protected and versioned, and allows the assembly to be deployed anywhere on the user's machine, and on the Internet.

Assemblies are deployed in two ways: private or global.

An assembly that is privately deployed is an assembly that is deployed to the application base directory or to a subdirectory. Weakly named assemblies can only be deployed privately.

An assembly that is deployed globally refers to an assembly that is deployed to some recognized locations. Strong-Named assemblies can be either privately deployed or globally deployed.

3.2 Assigning strong names to assemblies

Strong naming of assemblies has four important features: they collectively uniquely identify the assembly: file name (excluding extension), version number, language culture, and public key. Public key Token--a small hash value derived from the public key.

Weakly named assemblies can embed the assembly version and language culture in the inventory data; However, when the CLR finds satellite assemblies by probing subdirectories, the version number is ignored and only language culture information is available. Because weak-named assemblies are always private, the CLR uses only the assembly name when searching for assembly files in the application base directory or subdirectories.

Strong-named assemblies are signed with the publisher's private key in addition to the file name, assembly version number, and language culture.

The exact meaning of signing a file is: When a strong-named assembly is generated, the assembly FILEDEF the Qingdao metadata table lists all the files that make up the assembly. Each file is added to the manifest, and the contents of the file are hashed. The hash value and the file name are stored together in the FileDef table.

After the PE file containing the manifest is generated, the full contents of the PE file (except Authenticode Signature, assembly strong name data, and PE header checksum) are hashed.

3.3 Global Assembly Cache

Global Assembly CACHE,GAC is an assembly-recognized location that all programs need access to. The specific location of the GAC is an implementation detail that varies by version.

The GAC catalog is structured: It contains many subdirectories, the subdirectory name is generated by the algorithm, and all the assembly files are not manually copied to the GAC directory, which is done with tools.

Global deployment in the GAC is a form of registering an assembly.

3.4 Referencing strong-named assemblies in a generated assembly

When you install the. NET Framework, you actually install two sets of copies of Microsoft's assembly files. A set of subdirectories installed into the compiler/clr directory and another set installed into the GAC. The files in the compiler/clr directory make it easy for you to generate assemblies, while copies in the GAC are easy to load at run time.

Assemblies in the compiler/clr directory do not depend on machines, which contain only metadata. Because the IL code is not required at compile time, the directory does not have to contain both the Assembly x86,x64, and the arm version.

Assemblies in the GAC contain both metadata and IL code, because code is required only at run time, and because the code can be optimized for a specific CPU schema, the GAC allows multiple copies of an assembly. Each CPU architecture has a dedicated subdirectory to accommodate these copies.

3.5 Strong named Assemblies tamper-proof

The assembly is signed with the private key, and the public key and signature are embedded in the assembly, and the CLR verifies that the assembly was modified or destroyed.

When an assembly is installed to the GAC, the system hashes the contents of the file containing the manifest, comparing the hash value to the RSA data signature embedded in the PE file (after the signature is released with the public key). If the two values are completed consistently, the content is not tampered with. In addition, the system hashes the contents of other files in the assembly and compares the hash value to the stored hash value in the manifest's filedef table. Any one of the hashes does not match, indicating that at least one file in the assembly has been tampered with and the assembly cannot be installed to the GAC.

3.6 Delay Signature

A deferred signature is also known as a partial signature. Deferred signing allows assemblies to be generated only with the company's public key, temporarily without the private key. To implement a deferred signature, you need to obtain the public key value stored in the file, passing the file name to the implementation application used to generate the assembly.

To develop an assembly using delay signature technology:

1. During development, obtain a file containing only the company's public key, and compile the Chen assembly using the/keyfile and/delaysing compiler switches:

Csc/keyfile:mycompany.publickey/delaysign MyAssembly.cs

2. After generating the assembly, execute the following command, so that the CLR temporarily trusts the contents of the assembly, does not hash it, and does not compare the hash value.

SN.EXE-VR MyAssembly.dll

3. Be ready to package and deploy the assembly, get the company's private key, and execute the following command.

Sn.exe-ra MyAssembly.dll Mycompany.privatekey

4. Re-enable the validation of this assembly in order to test the execution of the following command in a real-world environment:

Sn-vu MyAssembly.dll

3.7 Private deployment strong-Named assemblies

Private deployments achieve a "simple replication Deployment" goal and better isolate the application and its assemblies.

Assemblies can also deploy directories that are known only by a few applications (not recommended)

3.8 ' runtime ' how to resolve type references

Running the application, the CLR loads and initializes itself, reads the assembly's CLR header, looks for the methoddeftoken that identifies the application entry method, checks the MethodDef metadata table to find the offset of the method IL code in the file, and then JIT compiles the IL code to the cost code, The last execution of native code.

The IL Code is JIT-compiled, and the CLR detects all types and member references and loads their defined assemblies if they are not already loaded.

When you parse a reference type, the CLR may find the type in three places.

Same file: Access to types in the same file can be found at compile time, which is called early binding. The type is loaded directly from the file, and execution continues.

Different files, same assembly: "Runtime" ensure that the referenced file is in the FileDef table of the current assembly metadata, check the directory where the assembly manifest file is loaded, load the referenced file, check the hash value to ensure file integrity. The member that discovers the type, execution continues.

Different files, different assemblies: If the referenced type is in a file in another assembly, run time loads the referenced assembly's manifest file. If the type you want is not in the file, continue to load the file that contains the type. The member that discovers the type, execution continues.

3.9 Advanced Management Control (configuration)

When compiling a method, the CLR determines which types and members it refers to, and according to this information, the runtime examines the AssemblyRef table of the assembly being referenced and determines which assemblies are referenced when the assembly is built. The CLR then checks the assembly/version in the application set configuration file for the specified version number redirection operation. Subsequently, the CLR looks for a new, redirected assembly/version.

The system allows you to use an assembly version that is not exactly matched to the metadata that is logged.

Publisher Policy Control

Chapter III Shared assemblies and strong-Named assemblies