C # basic compilation knowledge (3)

This article will focus on the introduction of Strongly-named assembly in the future. The emergence of Strongly-named assembly is actually to solve the version control problem. For example, after the release of the new assembly version, we want to retain the reference to the old assembly in the system, and some places can reference the new Assembly. For example, different companies provide different functions for the Assembly, these inventory classes are placed in a public directory, and sometimes the names are the same. A strongly-named assembly can solve these problems. A Strongly-named assembly is uniquely identified by four attributes: public key, assembly version number, Region attribute, and assembly name, the version of the newly released library file is different from that of the previous release. Different version references can be identified in the metadata, which will not affect each other, in addition, in the case of 99.99%, the four attributes of the Assembly generated by different companies will not all be the same, which can greatly reduce the risk of application deployment.

Components of a strongly-named assembly

Version Number

[assembly: AssemblyVersion("1.0.0.2")]

As we all know, the Assembly version is identified by custom attribute at the Assembly level. A version number always contains four parts: Major version (main version) and minorversion (minor version ), build and revision can be specified according to your version number. The build version number or revision version number can be automatically generated. The assemblyversion attribute value here can be 1.0.0. * Or 1. 0. * When this method is used, the automatically generated build is the number of days from, and the revision is the number of seconds/2 from 00:00:00 a.m. Let's give a simple example.

Using system; using system. reflection; [Assembly: assemblyversion ("1. 0. * ")] public class A {public static void main () {datetime dtbase = new datetime (2000,1, 1); datetime dtweehours = new datetime (datetime. now. year, datetime. now. month, datetime. now. day, 0, 0); console. writeline ("build version:" + datetime. now. subtract (dtbase ). days); console. writeline ("revision version:" + (INT) datetime. now. subtract (dtweehours ). totalseconds/2 );}}

The running result is as follows:

The dll version number is as follows (revision number is separated by 1 because the Compilation Time and running time are different. If you use the version number to calculate the generation time, this problem will not occur)

　　

This makes it clear that the build version number corresponds to the generated date, and the revision corresponds to the generated time. As long as the time of the two machines is no longer faulty, The automatically generated DLL versions will never be repeated. In the actual project, we must put the version information (the attribute Declaration above) in a separate file. When vs creates a project, an assemblyinfo is generated by default. CS file. This file contains this attribute. Of course, it also contains many other content, such as the product version, internal name, and file version above. You can solve this problem.

Region

[assembly: AssemblyCultureAttribute("en-Us")]

The Assembly culture is identified by the preceding custom attribute. The culture can be used to identify the assembly language. If it is not specified, it is considered language neutral. In order to allow applications to support multiple languages, Microsoft's official recommendation should include content related to language and culture in a separate resource file, multiple different DLL files are provided in different languages. Different languages are identified by regions and loaded by reflection when the main program is called. (Note that this parameter is not directly referenced, in this way, you can easily deploy and release the service ). Because of this, if an Assembly directly references a DLL with a non-neutral culture, a warning "cs1607: assembly generation -- the referenced assembly "××××" is a localized ancillary assembly ".

An assembly with a neutral culture is called a subsidiary assembly. The executable file cannot be a subsidiary assembly. If the identified culture is not empty, an error "error cs0647: issuing" system. reflection. assemblycultureattribute "error --" the executable file cannot be a subsidiary assembly, and the culture should always be blank "". In addition, loading ancillary assembly at runtime is different from language-neutral assembly, which will be further explained in the application configuration later.

Public Key tag

<add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>

The above content is from the web. the last part of the part intercepted in config, publickeytoken = b77a5c561934e089, and the part after the equal sign is the public key identifier, in fact, it is the last eight bytes of ciphertext that are embedded in the public key of the dataset after the SHA-1 hash operation. Before proceeding with Public Key tagging, let's take a look at the process of using the public key/private key pair for signature when the Assembly is generated.

1. Generate a public key private key pair. The size of this public key can be specified.

Sn-k d: \ liuzh. SNK

2. Use Keyfile to specify the key file during generation

CSC/out: D: \ apple. dll/T: Library/Keyfile: D: \ liuzh. snk d: \ apple. CS

When/Keyfile: is used, the compiler will do the following during production:
1. Use the/algid to overwrite each file in the filedefworkflow in the program set. Then use the private key (the private key comes from liuzh. SNK) to encrypt the hash value and obtain the ciphertext.

2. embed the ciphertext in the Public Key (the Public Key also comes from liuzh. SNK) and 1 into the assembly.

Demonstrate this process

 

 

Microsoft ensures that the contents of the public key/private key generated by the Sn will not be the same under any circumstances. That is to say, the public key embedded in the Assembly is unique. when the Assembly is referenced, if the complete public key of the referenced assembly is recorded in the referenced assembly set, the file will be very large (for example, any assembly will contain the mscorlib. DLL reference, because any class inherits from the object ). Displays the public key in the generated assembly.

Because the referenced assembly can only record part of the content after the Public Key hash operation of the referenced assembly, there is a problem that the final Public Key Identifiers of the two assembly may be consistent, however, the probability is very low (less than 1/264), and the uniqueness of the Assembly is differentiated by other content, so this will not cause any problems.

By the way, the Assembly that has signed the public key/private key can prevent tampering with certain programs. during runtime, CLR will use the public key to decrypt the ciphertext encrypted with the private key, compare the decrypted ciphertext with the hash Hash hash of each module in the dataset. If they are inconsistent, you can determine that the ciphertext has been tampered. The reason is that this protection mechanism is very fragile, which is explained later.

Assembly name

By default, the Assembly name is the name of the file specified by the/out switch (without the extension ). When vs is used, this name can be specified in the project property. Because the Assembly name is consistent with the file name during production, what name do you specify in the project property, the name of the last generated DLL.

2 Global Assembly Cache

If an assembly needs to be accessed by multiple applications (such as the class library provided by Microsoft), it must be placed in a known directory, in addition, when detecting a reference to the Assembly, the CLR needs to know the automatic check directory. This known directory is called the Global Assembly Cache (GAC). The Assembly placed in GAC is called the shared Assembly because it can be shared by other applications, it is called a private assembly only in the program running directory. For versions earlier than. Net 3.5, this directory is located in c: \ windows \ Assembly. For. net4.0, it is located in c: \ windows \ Microsoft. NET \ assembly.

Command to view its usage on the command line. It includes common functions such as installation, uninstallation, deletion, Reinstallation, and filtering. Note: Only one strongly-named assembly can be installed in GAC. If it is not strongly-named (no signature has been performed), the system will prompt "An error occurred while adding the assembly to the cache: try to install an assembly without a strong name. "In server2003, this folder is like this.

This directory contains almost all the assembly required by the application during runtime. net Framework, two copies of the Assembly file are installed, one is installed in the compilation directory, and the other is installed in GAC. Therefore, csc.exe does not search for the DLL you reference in the GAC during compilation. Why does the compiler not search for the DLL in the GAC? The specific path must be known during compilation/reference, the GAC directory is not public. One possible alternative is to specify the strong name of the Assembly during compilation, such as system. core, version = 3.5.0.0, culture = neutral, publickeytoken = b77a5c561934e089, but this solution is obviously not convenient to directly deploy two DLL sets.

Deploying an assembly to GAC is a means of registering the Assembly. Although it is not recorded in the registry, it obviously damages one of our basic goals: simple installation, backup, and restoration, move and uninstall. If we do not provide a class library for others' use, we should directly put the DLL under the program running directory.

3 Summary 

Further understanding of assembly-related information can enhance our understanding of the reference methods of various DLL and the configuration principles in project properties ,.. net installation directory to quickly locate and solve problems during program compilation or running.