. NET that Thing (03) build, deploy, and manage

Build, deploy, and manage
1 How to generate a strongly signed assembly
2 How to put an assembly into the GAC
3 delay signature and its effect
4 The version of the assembly is divided into several parts

1 How to generate a strongly signed assembly
When you build an assembly, the CLR provides two optional types:
Strong-Signed assemblies.
Weak-Signed assemblies.

A strong-signed assembly is an assembly with public and digital signatures, each of which can be uniquely identified by four elements: file name, version number, language culture, and public key. This information is included in the assembly's manifest. Relative to MPFSO signed assemblies, weak-signed assemblies have exactly the same metadata, CLR file headers, and assembly manifests, except that weak-signed assemblies do not have public keys and are not digitally signed. Weak-Signed assemblies cannot be placed in the global assembly cache (GAC) and can only be privately deployed.

Here is a brief introduction to the basic concepts of cryptography. When we are dealing with private information, we need to use encryption technology. Commonly used encryption technology has symmetric encryption technology, asymmetric encryption technology and non-reversible encryption technology. NET public key private key mechanism belongs to asymmetric encryption technology. The basic concept of asymmetric encryption is that the cryptographic party encrypts the information with the public key, and the decryption party needs to decrypt the encrypted information using the public key and its paired private key. Asymmetric encryption is characterized in that the public key can be exposed, the encryption algorithm is exposed, and the only key to control decryption is the private key, so in asymmetric encryption, the public key is often sent along with the encrypted information to the receiver, and the receiver through the public key to find their paired private key and decryption. There are RSA algorithms and DSA algorithms commonly used in asymmetric algorithms.

Back. NET encryption mechanism, when a strong signature program is generated, its public key is added to the program manifest. Also, when an assembly is published (Publish), a digital signature is generated that contains the hash value of the assembly manifest, which in turn contains the hash value of all modules in the assembly, in which case no changes to the assembly can be made unless the public and private keys of the assembly are owned. Visible in a strong-signed assembly, the public key and the digital signature implement the protection of the Assembly.

Shows the internal structure of a strong-signed assembly, and the structure of other assemblies that reference the assembly. Assembly 2 references the reference in assembly 1, so the public key token for assembly 1 is preserved in the CLR header of assembly 2.

Note: Because the public key is too long, the assembly reference can use the public key token instead of the public key. A public key token refers to a hash value of the public key, which is 8 bytes long.

Having understood the basic principle of the public key, I now take the C # compiler CSC.exe as an example to illustrate how to generate a strong-named assembly. First, you need to prepare a pair of unique public/private keys for the new strong-named assembly. The. NET Framework provides a useful tool: Sn.exe.
Open a command console for Visual Studio 2010 and enter this command:
Sn–k c:/mypublicprivatekey.snk

Sn.exe will generate a mupublicprivatekey.snk file for us under the C packing directory. This file stitching the public and private keys together, with a size of 596 bytes, where the first 160 bytes belong to the public key and the last 436 bytes to the private key. The user can control the input parameters of the Sn.exe to obtain only the public key or implement other functions.

With the public/private key pair ready, you can generate a strong-named assembly. Open a command console that comes with Visual Studio 2010 and enter the directory where Xxx.cs is located, and enter the following command:
Csc.exe/t:library xxx.cs/keyfile:c:\mypublicprivatekey.snk

A strong named assembly called XXX is generated, and the reader can attempt to write an assembly that references the strong named assembly, and try to replace it with a weak-named assembly. Of course, this is not possible, and the public key token and digital signature will ensure that the assembly cannot be arbitrarily tampered with.

An assembly that generates strong signatures requires a public/private key pair. After a public/private key pair is obtained, you can control the compiler's input parameters to get a strong signed assembly. For C # compiler CSC.exe, the/keyfile parameter can be used to make use of that public/private key file.

2 How to put an assembly into the GAC

The so-called GAC is the global assembly cache (Globals Assembly cache). Assemblies that are placed in the GAC can be guaranteed to be found and loaded by the CLR, no matter where they are referenced by other assemblies. In simple terms, the GAC is a canonical directory structure. If the host is using a Windows operating system and the operating system is installed under C:\Windows, the GAC will be installed under c:\windows\assembly\.

This kind of display and the General folder display way is very different. In fact, the. NET framework comes with a viewer for the global Assembly Cache Assembly Viewer, which is a display feature that clearly lists 4 elements that uniquely identify an assembly: name, version, culture, and public key token, and It also lists another element that affects the directory structure of the assembly in the GAC: Processor architecture. Readers can see the true face of the GAC catalog by turning off the viewer feature. The practice is to establish a DWORD value named Disablecacheviewer under Registry Hkey_local_ Machine\software\microsoft\fusion and set the value to 0. Readers will find that the GAC is a multi-layered directory structure that conforms to certain specifications.
Note that unless you need to learn the GAC directory structure, you should not manually modify the GAC directory at any time, and any operations on the GAC directory should be done through a tool.

Under normal circumstances, the GAC has the following advantages:

• When the assembly is referenced in multiple places, it can effectively reduce the memory cost.
• The latest version of the assembly can be effectively published by the publisher policy.
• Multiple versions of the same assembly can coexist and can be toggled by configuration.

If all the assemblies can be put into the GAC, the answer is no. Only strong-Signed assemblies with public keys can be deployed to the GAC, when the assembly is placed in the GAC. NET checks the assembly's CLR headers and encrypted values to ensure that the Assembly has not been tampered with. Placing the assembly in the GAC can be deployed manually or through a tool. The simplest way to do this is to drag the assembly directly into the GAC directory shown in the Assembly viewer using the assembly viewer described previously.

Note: The drag-and-drop mentioned here actually uses the Assembly viewer function instead of copying the assembly directly to the GAC folder. Again, readers should not manually modify the structure of the GAC directory.

The. NET Framework also provides a tool to effectively manage GAC:GACUTIL.exe. The author generates a strongly signed assembly: Compile.dll. Now, try putting it in the GAC:
Gacutil–i Compile.dll
Entering the Assembly viewer, the reader will find the new assembly that has just joined: compile.dll,0.0.0.0.

The GAC is a folder with a specific directory structure, and all strongly signed assemblies can be placed in the GAC. You can simply drag to add an assembly to the GAC through the. NET Framework's Assembly Viewer, or you can use a command line to add it using tools such as Gacutil.exe. In summary, any method, in the final analysis, is based on the GAC's specifications and the characteristics of the Assembly itself, creating the corresponding subdirectory structure in the GAC directory.

3 delay signature and its effect

When a strong-signed assembly is generated, public and digital signatures are added to the CLR header, and public keys and digital signatures protect the assembly from arbitrary tampering. But, experienced. NET programmers or project managers have such a personal experience that an assembly with tamper-proof functionality becomes extremely inconvenient during the development and testing phases. In order to use and modify the assembly, the project team had to distribute the very important private key, which would pose a great threat to the confidentiality of the project.

Therefore, in the project development and testing phase, the delay signature technology will be used frequently. As the name implies, the basic concept of delay signing is to defer the private key encryption until the project is actually released. During the development and testing phase, the programmer will use only one public key to generate a strong-signed assembly. In this way, only the public key in the assembly's CLR header is not digitally signed, and the space for the digital signature is preserved, and all files are not encrypted.

In the CLR header, the space for the digital signature is preserved, and the file is not hashed. In other respects, delayed signatures have no effect. In this case, the reader may wonder if the delay-signed assembly can be put into the GAC. As described in the previous section, the GAC's requirement for an assembly is that the Assembly is a strong-signed assembly with a public key. A deferred signature assembly has a public key, so in principle it can be put into the GAC, but because the GAC validates the assembly, the delay-signed assembly lacks a private key and does not experience any hash processing, so the deferred signed assembly needs to be notified before it is placed in the GAC. NET do not encrypt the assembly for authentication.

Delay signing means that the private key encryption and digital signature of a strong signed assembly are deferred until the actual publication. Delayed signing improves the efficiency of the development testing phase and facilitates the organization and project team to manage their own private keys.

4 The version of the assembly is divided into several parts

There are four elements that uniquely identify a strong-signed assembly, namely the name, version number, culture, and public key. The version number of an assembly is usually made up of four parts, which are:

• Major version number (Major versions)
• Minor version number (Minor versions)
• Build version
• Revision number (Revision Version)

By default, the larger the version number represents the newer the system. The general major version number and minor version number of the definition is clear, when the system undergoes a relatively large upgrade, the major version number will be changed, and in one major version, the release of the small feature will be published through the minor version number. With regard to the build number and revision number, there is a greater divergence of understanding. In general, a build number represents an integration cycle within the system, and a revision number represents a compilation in the integration cycle.

For example, within a system organization that currently has a version number of 12.2, the decision is made to make 6 integration cycles before the release 12.3 is released, one week for each integration cycle, and the compilation system set to compile at midnight every day. In this case, the system will typically generate 6 build numbers for 6 integration cycles, from 12.3.1 to 12.3.6. With each build going through 7 compilations, the system will have 7 revision numbers. For example, a second version will have 7 version numbers: 12.3.2.1 to 12.3.2.7.

Note: The division of the version number does not have a clear specification. But a component publisher should follow a common definition to determine the version number of the product, and a weird version number would mislead the component consumer.

Reprint please specify the source:

Jesselzj
Source: http://jesselzj.cnblogs.com

. NET that Thing (03) build, deploy, and manage