Publisher Policy Control

In the scenario described in the previous section, the publisher of an assembly simply sent a new ver- sion of the assembly to the administrator, who installed the assembly and manually edited the appli- cation’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 con- figuration 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 configura- tion files we’ve been talking about. Here’s an example file (called SomeClassLibrary.config) for the SomeClassLibrary.dll assembly.

<configuration>

<runtime>

<assemblyBinding xmlns="urn:schemas­microsoft­com:asm.v1">

<dependentAssembly>

<assemblyIdentity name="SomeClassLibrary" 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/SomeClassLibrary.dll"/>

</dependentAssembly>

</assemblyBinding>

</runtime>

</configuration>

Of course, publishers can set policies only for the assemblies that they themselves create. In ad- dition, 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 SomeClassLibrary assembly whenever version 1.0.0.0 of the assembly is referenced. Now you, the publisher, can create an assem- bly 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.SomeClassLibrary.dll

/version:1.0.0.0

/keyfile:MyCompany.snk

/linkresource:SomeClassLibrary.config

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

■ /outThis switch tells AL.exe to create a new PE file, called Policy.1.0.SomeClassLibrary.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 SomeClassLibrary 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, SomeClassLibrary, 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.

■ /versionThis switch identifies the version of the publisher policy assembly; this version number has nothing to do with the SomeClassLibrary 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 SomeClassLibrary to version 2.0.0.0. In the future, the pub- lisher might want to direct version 1.0.0.0 of SomeClassLibrary 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.

■ /keyfileThis switch causes AL.exe to sign the publisher policy assembly by using the publisher’s public/private key pair. This key pair must also match the key pair used for all ver- sions of the SomeClassLibrary assembly. After all, this is how the CLR knows that the same publisher created both the SomeClassLibrary assembly and this publisher policy file.

■ /linkresourceThis 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 SomeClass­ Library assembly. By the way, you can’t use AL.exe’s /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.

After this publisher policy assembly is built, it can be packaged together with the new Some- ClassLibrary.dll assembly file and deployed to users. The publisher policy assembly must be installed into the GAC. Although the SomeClassLibrary 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 follow- ing 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

<dependentAssembly> element in the application’s configuration file to have it apply to a spe- cific 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 us- ing the older version of the assembly. Note, however, that the CLR will still examine and apply any policy specified in the Machine.config file.

PART I I

Designing Types

CHAPTER 4................................Type Fundamentals............ 91

CHAPTER 5............Primitive, Reference, and Value Types............ 111

CHAPTER 6..........................Type and Member Basics151

CHAPTER 7...............................Constants and Fields............ 175

CHAPTER 8.............................................Methods............ 181

CHAPTER 9.........................................Parameters............ 209

CHAPTER 10.........................................Properties............ 227

CHAPTER 11.............................................Events............ 249

CHAPTER 12...........................................Generics............ 265

CHAPTER 13..........................................Interfaces............ 295

C HA P T E R 4

Type Fundamentals

In this chapter:

All Types Are Derived fromSystem.Object....................................... 91

Casting Between Types........................................................................... 93

Namespaces and Assemblies................................................................... 97

How Things Relate at Run Time............................................................. 101

In this chapter, I will introduce information that is fundamental to working with types and the common language runtime (CLR). In particular, I’ll discuss the minimum set of behaviors that you can expect every type to have. I’ll also describe type safety, namespaces, assemblies, and the various ways you can cast objects from one type to another. Finally, I’ll conclude this chapter with an explanation of how types, objects, thread stacks, and the managed heap all relate to one another at run time.

Date: 2016-03-03; view: 764