CHAPTER 14 BUILDING AND CONFIGURING CLASS LIBRARIES
Now run the SharedCarLibClient.exe program by double-clicking the executable from Windows
Explorer. You should see the message that version 2.0.0.0 has loaded.
Multiple elements can appear within a client’s configuration file. Although
there’s no need for this example, assume that the manifest of SharedCarLibClient.exe also references
version 2.5.0.0 of an assembly named MathLibrary. If you wanted to redirect to version 3.0.0.0 of
MathLibrary (in addition to version 2.0.0.0 of CarLibrary), the SharedCarLibClient.exe.config file would
look like the following:
Note It is possible to specify a range of old version numbers via the oldVersion attribute; for example,
informs the CLR to use version
2.0.0.0 for any older version within the range of 1.0.0.0 to 1.2.0.0.
Understanding Publisher Policy Assemblies
The next configuration issue we’ll examine is the role of publisher policy assemblies. As you’ve just seen,
*.config files can be constructed to bind to a specific version of a shared assembly, thereby bypassing
the version recorded in the client manifest. While this is all well and good, imagine you’re an
administrator who now needs to reconfigure all client applications on a given machine to rebind to
version 2.0.0.0 of the CarLibrary.dll assembly. Given the strict naming convention of a configuration
file, you would need to duplicate the same XML content in numerous locations (assuming you are, in
fact, aware of the locations of the executables using CarLibrary!). Clearly this would be a maintenance
nightmare.
Publisher policy allows the publisher of a given assembly (you, your department, your company, or
what have you) to ship a binary version of a *.config file that is installed into the GAC along with the
548