Creating publisher policies for DLLs

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

MT - 05 Feb 2004 13:48 GMT

We have a .NET dll that we are deploying to our customers using a deployment
project in VS .NET 2003. There is a lot of information about creating
publisher policies on the web, but we have not been successful in creating
one. Here's what the ultimate goal is:
When the DLL is deployed to a customer's system, every application using
this dll must point to the new version. This has to be an automated process
using the deployment project.
This is what we have already done:
1. Created a file called app.config with the following text:
<configuration>
<runtime>
<assemblyBinding>
<dependentAssembly>
<assemblyIdentity name="name of assembly"
publicKeyToken="public key token"
culture="en-us"/>
<bindingRedirect
oldVersion="1.0.0.0-65535.35535.65535.65535"
newVersion="2.0.1.0"/>
<codeBase version="2.0.0.0"
href="http://www.foo.com/bar.dll"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>

We copied this from a howto on gotdotnet.com

2. We signed the dll with our key and created a policy file.
3. We then deployed this dll to the customer's GAC.

However, the customer's application that used an old version of the dll did
not automatically redirect to the new version.

Is there something we are missing?
Does the name of the config file have to be something specific (like
myassembly.dll.config)?
Has anybody ever gotten this to work?

Any help would be appreciated,

Thanks,
MT

Reply to this Message

Bret Mulvey - 13 Feb 2004 18:41 GMT

> We have a .NET dll that we are deploying to our customers using a deployment
> project in VS .NET 2003. There is a lot of information about creating
[quoted text clipped - 39 lines]
> Thanks,
> MT

The publisher policy dll in the GAC has to have a specific name
(policy.majorNumber.minorNumber.mainAssemblyName.dll) and you need to be
careful how you add the publisher policy file to the GAC. I've had success
only when the .config file is in the same subdirectory as the .dll when you
add the .dll to the GAC.

If the .config file isn't present when you drag and drop the .dll via the UI
you'll see an error, but I've seen automated tools install a publisher
policy file into the GAC without the .config file being present and then
seeing the behavior you describe.

Reply to this Message

Aditya Dhar - 20 Feb 2004 01:51 GMT

The publisher policy config file you mentioned below is incorrect. You can
use a publisher policy to just redirect for the same
majorversion.minorversion of the assembly foo.dll.
e.g. The change from the publisher policy config file you mentioned below
would be that for the bindredirect statement, you would put something like:
<bindingRedirect oldVersion="1.0.0.0-1.0.65535.65535" newVersion="2.0.1.0"/>
instead of:
<bindingRedirect oldVersion="1.0.0.0-65535.65535.65535.65535"
newVersion="2.0.1.0"/>

Basically, publisher policy is a way of redirection just for bug
fixes/security fixes/service packs (for which the build- & revision-version
numbers can change but the major and minor versions don't).

From what I gather your scenario is that you want to redirect "all"
previously-shipped versions of the dll to the same dll using publisher
policy. This is dangerous as I will describe later. To achieve this, you
will have to create separate publisher policy assemblies for each
majorversion.minorversion combination of dlls that you have shipped
earlier, as follows:

1. Create a publisher policy config file, foo.config for one set of
majorversion.minorversion of foo.dll that you have shipped (similar to the
one you mention, but with the change described above)

2. Create an assembly containing the publisher policy config file. For this
you have to run the tool AL.exe as follows:
AL.exe /out:policy.majorversion.minorversion.foo.dll /version:1.0.0.0
/key:YourCompany.keys /linkresources:foo.config

This creates a publisher policy file corresponding to the majorversion and
minorversion of foo.dll. The first part of the name, "policy", tells the
CLR that this assembly contains publisher policy information. The policy
assembly itself also has a version that you specify with the /version
switch. The CLR picks up the publisher policy file with the latest version.
The /key switch is used to strongly sign the assembly. The /linkresources
switch tells AL.exe that the XML config file is to be considered a separate
file of the assembly.

3. Once this publisher policy assembly is built, you can package it
together with your new foo.dll assembly file and deploy it to the user. The
publisher policy assembly MUST be installed in the GAC.

4. Repeat the above three steps for the other major.minor version
combinations that you may have shipped.

Finally, the number of publisher policy assemblies you will end up with is
equal to the number of different major.minor version number combinations
shipped of the assembly that the publisher policies are for.

That said, if a new version of the new assembly isn't compatible with the
old versions that you are redirecting, you shouldn't create a publisher
policy assembly. If you are redirecting versions, you should test the new
version of the assembly for backward compatibility. Publisher policy is
generally used when making bug fixes to existing assemblies. However, if
you're adding new features to your assembly, you should consider the new
assembly to have no relationship to a previous version and you shouldn't
ship a publisher policy assembly. This is the reason for discouraging
wholesale redirection across major-minor version numbers using publisher
policy.
Also note that we discourage backward redirection of version numbers (e.g.
redirection of version 3.2.0.0 to 2.0.0.0).

--------------------

| From: "Bret Mulvey" <bretm@online.microsoft.com>
| Newsgroups:

microsoft.public.dotnet.framework.setup,microsoft.public.dotnet.framework.cl
r,microsoft.public.dotnet.framework,microsoft.public.dotnet.framework.sdk,mi
crosoft.public.dotnet.languages.vc,microsoft.public.dotnet.languages.vb

| References: <eN4zU6#6DHA.2404@TK2MSFTNGP11.phx.gbl>
| Subject: Re: Creating publisher policies for DLLs
[quoted text clipped - 8 lines]
| Message-ID: <402d1a3c$1@news.microsoft.com>
| X-Trace: news.microsoft.com 1076697660 157.56.39.15 (13 Feb 2004 10:41:00

-0800)

| X-Original-Trace: 13 Feb 2004 10:41:00 -0800,

osmium.redmond.corp.microsoft.com

| Path:

cpmsftngxa07.phx.gbl!cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!newsfeed00.su
l.t-online.de!t-online.de!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!ne
ws-out1.nntp.be!propagator4-cogent.newsfeed.com!propagator2-sterling!news-in
-sterling.newsfeeds.com!sea-feed.news.verio.net!news.microsoft.com!not-for-m
ail

| Xref: cpmsftngxa07.phx.gbl microsoft.public.dotnet.framework.clr:9569

microsoft.public.dotnet.framework:65120
microsoft.public.dotnet.framework.sdk:8701
microsoft.public.dotnet.languages.vc:33274
microsoft.public.dotnet.languages.vb:181315
microsoft.public.dotnet.framework.setup:7145

| X-Tomcat-NG: microsoft.public.dotnet.framework.clr
|
[quoted text clipped - 55 lines]
| policy file into the GAC without the .config file being present and then
| seeing the behavior you describe.

Reply to this Message

Rate this thread:

Creating publisher policies for DLLs

Free Magazines