Shared Assemblies and Strongly Named Assemblies in Visual Studio .NET

Generator QR-Code in Visual Studio .NET Shared Assemblies and Strongly Named Assemblies

3

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 .

In the scenario described in the previous section, the publisher of an assembly simply sent a new version of the assembly to the administrator, who installed the assembly and manually edited the application s or machine s XML configuration files . In general, when a publisher fixes a bug in an assembly, the publisher would like an easy way to package and distribute the new assembly to all of the users . But the publisher also needs a way to tell each user s CLR to use the new assembly version instead of the old assembly version . Sure, each user could modify his or her application s or machine s XML configuration file, but this is terribly inconvenient and error prone . What the publisher needs is a way to create policy information that is installed on the user s computer when the new assembly is installed . In this section, I ll show how an assembly s publisher can create this policy information . Let s say that you re a publisher of an assembly and that you ve just created a new version of your assembly that fixes some bugs . When you package your new assembly to send out to all of your users, you should also create an XML configuration file . This configuration file looks just like the configuration files we ve been talking about . Here s an example file (called JeffTypes .config) for the JeffTypes .dll assembly:

<configuration> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <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> </assemblyBinding> </runtime> </configuration>

Of course, publishers can set policies only for the assemblies that they themselves create . In addition, the elements shown here are the only elements that can be specified in a publisher policy configuration file; you can t specify the probing or publisherPolicy elements, for example .

This configuration file tells the CLR to load version 2 .0 .0 .0 of the JeffTypes assembly whenever version 1 .0 .0 .0 of the assembly is referenced . Now you, the publisher, can create an assembly that contains this publisher policy configuration file . You create the publisher policy assembly by running AL .exe as follows:

AL.exe /out:Policy.1.0.JeffTypes.dll /version:1.0.0.0 /keyfile:MyCompany.snk /linkresource:JeffTypes.config

Let me explain the meaning of AL .exe s command-line switches:

/out This switch tells AL .exe to create a new PE file, called Policy .1 .0 .JeffTypes .dll,

which contains nothing but a manifest . The name of this assembly is very important . The first part of the name, Policy, tells the CLR that this assembly contains publisher policy information . The second and third parts of the name, 1.0, tell the CLR that this publisher policy assembly is for any version of the JeffTypes assembly that has a major and minor version of 1 .0 . Publisher policies apply to the major and minor version numbers of an assembly only; you can t create a publisher policy that is specific to individual builds or revisions of an assembly . The fourth part of the name, JeffTypes, indicates the name of the assembly that this publisher policy corresponds to . The fifth and last part of the name, dll, is simply the extension given to the resulting assembly file .