Before the GAC of. Net appeared, there was a problem with DLL hell. This is because the shared DLL was handled in a way that was implemented by using the registry. When we install a program A, the program contains a shared DLL, then the DLL will be written to the registry, but note that there is no version information written, just tell you where there is a DLL called XX can be used. When installing another program B, also contains the shared DLL, but is a more recent version, the system will find that the DLL has been registered, it will use this DLL to overwrite the original DLL, but because there is no version of the registry in the logo, So the system still thinks this is a DLL. But now has updated the Dll,a program may appear to use this DLL when incompatible phenomenon, but at this time if you reload a program, and then swap the shared DLL back, then the B program may appear incompatible phenomenon. This is the DLL hell problem.This problem is caused by the problem that the same DLL cannot have multiple versions at the same time.
DLL Hell refers to a series of problems that arise when multiple applications attempt to share a common component, such as a Dynamic Connection library (DLL) or a Component Object Model (COM) class. In the most typical case, an application will install a new version of the shared component that is not backwards compatible with the existing version on the machine. Although the application you just installed is working correctly, the application that originally relied on the previous version of the shared component may no longer work.
Then the GAC appeared to solve the problem. In the GAC, there are several different versions of the same DLL that can exist at the same time. If multiple programs use this DLL, then the program can go to the GAC to find the appropriate version of the DLL. But in the GAC, for example, the same Data.dll, even if there are multiple versions of the file, But the file name should be all Data.dll, and in different directories total, its version information is not reflected in the file name appears, but in the DLL's header information stored. Each program will have an assembly manifest, which exists in the. manifest file with the same name as the program, which lists all the dependencies it needs, and the dependencies listed here are not simply distinguished by the file name, but by something called a "strong filename".
<?xml version= ' 1.0 ' encoding= ' UTF-8 ' standalone= ' yes '?> <assembly xmlns= ' urn:schemas-microsoft-com: Asm.v1 ' manifestversion= ' 1.0 ' > <dependency> <dependentAssembly> <assemblyidentity type= ' Win32 ' Name= ' Microsoft.VC80.CRT ' version= ' 8.0.50608.0 ' processorarchitecture= '
We found that this is a file in XML format, where <dependency> This section indicates that it relies on a library named Microsoft.VC80.CRT. But we found that there are other things in the,<assemblyidentity> attribute, namely type system, version number, processorarchitecture platform environment, PublicKeyToken public key (commonly used to mark a company), add them together became a "strong file name", with this "strong file name", we can distinguish between different versions, different platforms, in short, with this strong file name, There can be several different versions of the same library in the system that coexist without conflicts.
In fact, PublicKeyToken is the simple form of public key, we can take PublicKeyToken as PublicKey. Here is a description of the existence of PublicKeyToken. PublicKeyToken's role is to determine the DLL to be loaded must be the original DLL, in fact, this aspect also played a security guard. For example, some programs, someone wrote a DLL with the same name to cover your original DLL, the program if you do not distinguish the use of this DLL, there may be security issues. So what is publickeytoken to ensure this uniqueness?
Encryption algorithms are involved here. The developer of the original DLL will encrypt the DLL when it is developed, and the encryption method used is the public key method. The public key and the private key are both present and uniquely corresponding. For the same piece of content, after encrypting with the private key, only the public key can be decrypted. If you encrypt something with a different private key, you can't get anything out of it with this public key.DLL developers have their own private key, and this private key other people do not know, is confidential, in the DLL when the development of the private key encryption, and the public key information written to the program. When this program is developed and run on a computer, the system will find out which DLL is used in the program's program list, and to see the version of the DLL, and to use PublicKeyToken to ensure the original nature of the DLL. So what is the process to ensure the original nature of this DLL? For example, there is a person on your computer, after you install the program, to the installation directory of your program, with a same name, with the same namespace and class DLL replaced your original DLL, how the system can be found?when the program is running, it will take a look at the program's program list to see which DLL is used, and how much is the public key of the DLL. (I think this list is easy to tamper with, and if it can be tampered with, then there is no security in the program.) At least I think so. Then go to the GAC or the program directory to find the DLL. There is some information in this DLL's header file, which is the contents of the DLL and the encrypted string. The program uses the public key to decrypt the string, and if the decrypted content is consistent with what is recorded in the DLL, it proves that the DLL is original and has not been tampered with.
Let's consider several situations that may be tampered with
Someone just modified the contents of the DLL, and did not modify the encrypted value, it is easy to be discovered by the program, because the decrypted value and DLL content is inconsistent, the program will prompt the exception.
Some people not only modify the contents of the DLL, but also want to modify the encrypted value, but you know, at this time the user is not the original developer's private key, if he arbitrarily with a private key encryption, then in the program decryption is, with that public key is not to decrypt anything, because the public key private key is corresponding. at this point, the program will prompt for an exception. This article is a detailed explanation of the process of encrypting the public key for the DLL.
Sometimes you will see some <runtime>bindingredirect content in the Web. config file under the Runtime tab, which involves PublicKey. The role here is to map different versions of the file to a specific version, that is, a DLL listed in the program list is 2.0 version, but the program at run time in the GAC to find only 1.0 version, then tell the program does not prompt the exception, as long as the 1.0 version as the 2.0 version can be.
<assemblybinding xmlns= "Urn:schemas-microsoft-com:asm.v1" > <dependentAssembly> < assemblyidentity name= "SYSTEM.WEB.MVC" publickeytoken= "31bf3856ad364e35"/> <bindingredirect oldVersion= "1.0.0.0" newversion= "2.0.0.0"/> </dependentAssembly> </assemblyBinding> </ Runtime>
Summary: PublicKeyToken or publickey is not just for security, it is also used to differentiate between different versions of the same DLL. In fact, in the general development of our use of not much, at least from my own shallow experience, the contact is not much, is basically transparent.
