In the section “Simple Administrative Control (Configuration)” in Chapter 2, I gave a brief introduction to how an administrator can affect the way the CLR searches and binds to assemblies. In that section, I demonstrated how a referenced assembly’s files can be moved
to a subdirectory of the application’s base directory and how the CLR uses the application’s XML configuration file to locate the moved files.
Having discussed only the probing element’s privatePath attribute in Chapter 2, I’m going to discuss the other XML configuration file elements in this section. Following is an XML configuration file:
<?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="FredTypes"
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 gives a wealth of information to the CLR. Here’s what it says:
§ probingelement Look in the application base directory’s AuxFiles and bin\subdir subdirectories when trying to find a weakly named assembly. For strongly named assemblies, the CLR looks in the GAC or in the URL specified by the codeBase
element. The CLR looks in the application’s private paths for a strongly named assembly only if no codeBase element is specified.
§ First dependentAssembly, assemblyIdentity, and bindingRedirect elements When attempting to locate version 1.0.0.0 of the neutral culture JeffTypes
assembly published by the organization that controls the 32ab4ba45e0a69a1 public key token, locate version 2.0.0.0 of the same assembly instead.
§ codeBase element When attempting to locate version 2.0.0.0 of the neutral culture JeffTypes assembly published by the organization that controls the
32ab4ba45e0a69a1 public key token, try to find it at the following URL:
http://www.Wintellect.com/JeffTypes.dll. Although I didn’t mention it in Chapter 2, a
codeBase element can also be used with weakly named assemblies. In this case, the assembly’s version number is ignored and should be omitted from the XML’s codeBase
element. Also, the codeBase URL must refer to a directory under the application’s base directory.
§ Second dependentAssembly, assemblyIdentity, and bindingRedirect elements When attempting to locate version 3.0.0.0 through version 3.5.0.0 inclusive of the neutral culture FredTypes assembly published by the organization that controls the 1f2e74e897abbcfe public key token, locate version 4.0.0.0 of the same assembly instead.
§ publisherPolicy element If the organization that produces the FredTypes assembly has deployed a publisher policy file (described in the next section), the CLR should ignore this file.
When compiling a method, the CLR determines the types and members being referenced. Using this information, the runtime determines—by looking in the referencing assembly’s AssemblyRef table—what assembly was originally referenced when the calling assembly was built. The CLR then looks up the assembly in the application’s configuration file and applies any version number redirections.
If the publisherPolicy element’s apply attribute is set to yes—or if the element is omitted—the CLR examines the GAC and applies any version number redirections that the publisher of the assembly feels is necessary. I’ll talk more about publisher policy in the next section.
The CLR then looks up the assembly in the machine’s Machine.config file and applies any version number redirections there. Finally, the CLR knows the version of the assembly that it should load, and it attempts to load the assembly from the GAC. If the assembly isn’t in the GAC and if there is no codeBase element, the CLR probes for the assembly as I described in Chapter 2. If the configuration file that performs the last redirection also contains a
codeBase element, the CLR attempts to load the assembly from the codeBase element’s specified URL.
Using these configuration files, an administrator can really control what assembly the CLR decides to load. If an application is experiencing a bug, the administrator can contact the publisher of the errant assembly. The publisher can send the administrator a new assembly that the administrator can install. By default, the CLR won’t load this new assembly since the already built assemblies don’t reference the new version. However, the administrator can modify the application’s XML configuration file to instruct the CLR to load the new assembly.
If the administrator wants all applications on the machine to pick up the new assembly, the administrator can modify the machine’s Machine.config file instead and the CLR will load the new assembly whenever an application refers to the old assembly.
If the new assembly doesn’t fix the original bug, the administrator can delete the binding redirection lines from the configuration file and the application will behave as it did before. It’s important to note that the system allows the use of an assembly that doesn’t exactly match the assembly version recorded in the metadata. This extra flexibility is very handy. Later in this chapter, I’ll go into more detail about how an administrator can easily repair an application.
The .NET Framework Configuration Tool
If you don’t like manually editing XML text files—and who does?—you can use the .NET Framework Configuration tool, which ships with the .NET Framework. Open Control Panel, select Administrative Tools, and then select the Microsoft .NET Framework Configuration tool. While in the tool, you can select Configure An Assembly, which causes an assembly’s Properties dialog box to pop up. From within this dialog box, you can set all of the XML configuration information. Figures 3-7, 3-8, and 3-9 show different pages of an assembly’s properties dialog box.