Shared Assemblies and strongly named Assemblies

1. public key token is the last 8 bytes of public key which has been hashed.

 

2.The public key field in AssemblyDef metadata table stores the full public key.

    The public key filed in AssemblyRef metadata table stores the public key token. 

 

3. Whenever you build an assembly, the assembly will have references to other strongly named
     assemblies. This is true because System.Object is defined in MSCorLib.dll, which is strongly
     named. However, it’s likely that an assembly will reference types in other strongly named assemblies
     published either by Microsoft, a third party, or your own organization. In Chapter 2,
     I showed you how to use CSC.exe’s /reference compiler switch to specify the assembly file
     names you want to reference. If the file name is a full path, CSC.exe loads the specified file
     and uses its metadata information to build the assembly. As mentioned in Chapter 2, if you
     specify a file name without a path, CSC.exe attempts to find the assembly by looking in the
     following directories (in order of their presentation here):
       1)Working directory.
       2)The directory that contains the CSC.exe file itself. This directory also contains the CLR
         DLLs.
       3) Any directories specified using the /lib compiler switch.
       4)Any directories specified using the LIB environment variable.
     So if you’re building an assembly that references Microsoft’s System.Drawing.dll, you can
     specify the /reference:System.Drawing.dll switch when invoking CSC.exe. The compiler
     will examine the directories shown earlier and will find the System.Drawing.dll file in the
     directory that contains the CSC.exe file itself, which is the same directory that contains the
     DLLs for the version of the CLR the compiler is tied to. Even though this is the directory
     where the assembly is found at compile time, this isn’t the directory where the assembly will
     be loaded from at runtime.

 

4. <?xml version="1.0"?>
<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 gives a wealth of information to the CLR. Here’s what it says:
n probing element 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.
n First dependentAssembly, assemblyIdentity, and bindingRedirect elements
When attempting to locate version 1.0.0.0 of the culture-neutral JeffTypes assembly
published by the organization that controls the 32ab4ba45e0a69a1 public key token,
locate version 2.0.0.0 of the same assembly instead.
n codeBase element When attempting to locate version 2.0.0.0 of the culture-neutral
JeffTypes assembly published by the organization that controls the 32ab4ba45e0a69a1
public key token, try to find it at the following URL: 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.

 

 

 

 

 

 

n

 

 

Second dependentAssembly, assemblyIdentity, and bindingRedirect

elements

When attempting to locate version 3.0.0.0 through version 3.5.0.0 inclusive of the

culture-neutral TypeLib assembly published by the organization that controls the

1f2e74e897abbcfe public key token, locate version 4.0.0.0 of the same assembly instead.

n

 

 

publisherPolicy element

If the organization that produces the TypeLib 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, the assembly that was originally referenced when the calling assembly

was built. The CLR then looks up the assembly/version in the application’s configuration

file and applies any version number redirections; the CLR is now looking for this assembly/

version.

If the

 

 

publisherPolicy element’s apply attribute is set to yes

—or if the element is omitted

—the CLR examines the GAC for the new assembly/version and applies any version number

redirections that the publisher of the assembly feels is necessary; the CLR is now looking for

this assembly/version. I’ll talk more about publisher policy in the next section. Finally, the CLR

looks up the new assembly/version in the machine’s Machine.config file and applies any

version number redirections there.

At this point, 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.

 

 

 

 

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.
Publisher Policy Control
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抯 command-line switches:
n /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抰 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.
n /version This switch identifies the version of the publisher policy assembly; this
version number has nothing to do with the JeffTypes assembly itself. You see, publisher
policy assemblies can also be versioned. Today, the publisher might create a publisher
policy redirecting version 1.0.0.0 of JeffTypes to version 2.0.0.0. In the future, the publisher
might want to direct version 1.0.0.0 of JeffTypes to version 2.5.0.0. The CLR uses
this version number so that it knows to pick up the latest version of the publisher policy
assembly.
n /keyfile This switch causes AL.exe to sign the publisher policy assembly by using
the publisher抯 public/private key pair. This key pair must also match the key pair used
for all versions of the JeffTypes assembly. After all, this is how the CLR knows that the
same publisher created both the JeffTypes assembly and this publisher policy file.
n /linkresource This switch tells AL.exe that the XML configuration file is to be
considered a separate file of the assembly. The resulting assembly consists of two files,
both of which must be packaged and deployed to the users along with the new version
of the JeffTypes assembly. By the way, you can抰 use AL.exe抯 /embedresource switch to
embed the XML configuration file into the assembly file, making a single file assembly,
because the CLR requires the XML file to be contained in its own separate file.
Once this publisher policy assembly is built, it can be packaged together with the new
JeffTypes.dll assembly file and deployed to users. The publisher policy assembly must be installed
into the GAC. Although the JeffTypes assembly can also be installed into the GAC, it

doesn’t have to be. It could be deployed into an application’s base directory or some other
directory identified by a codeBase URL.

I want to make one last point about publisher policy. Say that a publisher distributes a publisher
policy assembly, and for some reason, the new assembly introduces more bugs than
it fixes. If this happens, the administrator would like to tell the CLR to ignore the publisher
policy assembly. To have the runtime do this, the administrator can edit the application’s
configuration file and add the following publisherPolicy element:
<publisherPolicy apply="no"/>
This element can be placed as a child element of the <assemblyBinding> element in the
application’s configuration file so that it applies to all assemblies, or as a child element of the
<dependantAssembly> element in the application’s configuration file to have it apply to a
specific assembly. When the CLR processes the application’s configuration file, it will see that
the GAC shouldn’t be examined for the publisher policy assembly. So the CLR will continue to
operate using the older version of the assembly. Note, however, that the CLR will still examine
and apply any policy specified in the Machine.config file.