[C # advanced series] 03 configuration file management and Assembly reference version redirection,

[C # advanced series] 03 configuration file management and Assembly reference version redirection,

First, click the title that is irrelevant:

CLR supports two types of Assembly: Weak naming assembly and strong naming assembly.

The difference between the two is that the strongly-named Assembly uses the publisher's public key and private key for signature. Since an assembly is uniquely identified, CLR can apply known security policies when an application is bound to a strongly-named assembly.

The Assembly can be deployed in two ways.: Private or global. Weak naming Assembly can only be deployed in private mode.

Chapter 3 of CLR via C # describes private deployment and global deployment, weak naming assembly, and strong naming assembly.

But to be honest, these things are not used normally, so I will not write them here.

There is also an explanation of how CLR parses type references, which is also simple. I also mentioned a few points earlier, so I will not talk about it anymore.

Now let's take a look at the useful knowledge points in this chapter, that is, the title content:

Configuration File Management

The so-called configuration file is the file that manages the. config Suffix in our program.

<?xml version="1.0" encoding="utf-8" ?><configuration>  <runtime>    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">      <probing privatePath="AuxFiles;bin\subdir"/>      <dependentAssembly>        <assemblyIdentity name="JeffTypes" publicKeyToken="32ab4ba45e0a69a1" culture="neutral"/>        <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>        <codeBase version="2.0.0.0" href="http://www.wintellect.com/JeffTypes.dll"/>      </dependentAssembly>      <dependentAssembly>        <assemblyIdentity name="TypeLib" publicKeyToken="1f2e74e897abbcfe" culture="neutral"/>        <bindingRedirect oldVersion="3.0.0.0-3.5.0.0" newVersion="4.0.0.0"/>        <publisherPolicy apply="no"/>      </dependentAssembly>    </assemblyBinding>  </runtime></configuration>

This XML file provides rich information for CLR. Including:

• Probing ElementCheck the AuxFiles and bin \ subdir subdirectories in the application base directory when you look for a weak naming assembly. For a strongly-named assembly, CLR checks the URL specified by the GAC or codeBase element. The CLR checks strongly-named assembly in the private path of the application only when no codeBase element is specified.
• FirstDependentAssembly, assemlyIdentity, and bindingRedirect ElementsFind version 1.0.0.0 of the language-neutral JeffTypes Assembly published by the organization that controls the public key to mark 32ab4ba45e0a69a1, and then locate version 2.0.0.0 of the same assembly.
• CodeBase ElementWhen you find version 2.0.0.0 of the JeffTypes assembly that is released by an organization that controls the public key to mark 32ab4ba45e0a69a1 and has a neutral language, try to find it at the following URL: http://www.wintellect.com/jefftypes.dll. Although not specifically stated in Chapter 2nd, the codeBase element can also be used for weak naming assembly. In this case, the version number of the Assembly is ignored, and the version number should not be written in the XML codeBase element. In addition, the URL defined by codeBase must reference a sub-directory under the application base directory.
• 2ndDependentAssembly, assemblyIdentity, and bindingRedirect ElementsSearch for versions 3.0.0.0 to 3.5.0.0 (including 3.0.0.0 and 3.5.0.0) of the language-neutral TypeLib Assembly published by the organization that controls the public key to mark 1f2e74e897abbcfe ), locate version 4.0.0.0 of the same assembly.
• If the publisherPolicy element is deployed in the organization that generates the TypeLib assembly, the CLR should ignore this file.

The above code and description are exactly the same as those in the book.

When compiling a method, the CLR determines which types and members it references, searches for the AssemblyRef metadata reference table in the referenced assembly, judges which sets the Assembly references, and then checks the configuration file, redirects the specified version number. (That is, the operations performed by the dependentAssembly, assemlyIdentity, and bindingRedirect elements ).

The CLR knows the version of the assembly to be loaded at this time and loads it to the GAC (you can understand it as a shared Assembly folder on our respective computers ). If the configuration file for the last redirection operation contains both codeBase, check the codeBase element and the CLR loads the Assembly from the specified URL. Otherwise, it will be searched in the application root directory, if it cannot be found, it will be located in the root directory and found in the AuxFiles and bin \ subdir subdirectories specified by the configuration file probing. First, the dll file will be searched. If the dll file cannot be found, the suffix will be changed to exe, and then search by rule.

If you delete the bindingRedirect element in the configuration file, the application will be restored.