2

I have created a common library at work, and it is installed in the GAC on our test server. I've recently updated it and I want all of our applications to be using the update. I created a publisher policy assembly and installed it in the GAC along with the update, but when a web app loads Leggett.Common, 1.0.0.0, it isn't redirected to Leggett.Common, 1.1.0.0.

I have the common assembly (there are actually five, but lets keep it simple) on a network drive, I created the publisher policy xml file there next to it and then used al.exe to create the publisher policy assembly in the same folder. After that I put the updated assembly in the GAC and then put the publisher policy assembly in the GAC.

The common assembly is 'Leggett.Common.dll', the publisher policy file is '1.1.Leggett.Common.policy', and the publisher policy assembly is 'policy.1.1.Leggett.Common.dll'.

The XML for the publisher policy file looks like the following:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="Leggett.Common"
                                  publicKeyToken="32cd8f1a53a4c744"
                                  culture="neutral" />
                <bindingRedirect oldVersion="1.0.0.0"
                                 newVersion="1.1.0.0"/>
            </dependentAssembly>
        </assemblyBinding>
    </runtime>
</configuration>

What am I doing wrong?

Clarification
I'm testing this on my local dev machine since developers don't have access to the test server.

Max Schmeling
  • 12,363
  • 14
  • 66
  • 109
  • Can you provide us with the XML for the publisher policy? – Kev Oct 08 '08 at 22:40
  • If this is on your local machine can you try the fusion logger, it's actually available for all version of .NET, you just have to install the .NET SDK for whatever version of .NET you're using. – Kev Oct 08 '08 at 23:12
  • ...I know..stupid stuff....you have definitely got the publicKeyToken and version number correct? i.e. Your AssemblyVersion attribute for the new assembly is definitely 1.1.0.0 and the public key token is identical (in the GAC)? – Kev Oct 08 '08 at 23:20
  • This is what it shows: http://www.nomorepasting.com/getpaste.php?pasteid=20926 – Max Schmeling Oct 08 '08 at 23:24
  • Max - I have a very early start tomorrow and it's 01:40, I hope you don't mind if I carry on this tomorrow? – Kev Oct 09 '08 at 00:37
  • Absolutely. I appreciate your help. I'll check back when I get into work in the morning. – Max Schmeling Oct 09 '08 at 03:34
  • Max - I've added some more thoughts to my answer. – Kev Oct 09 '08 at 15:43
  • Hi Max - dunno if you're still having issues with this. I've updated my answer to something I noticed today about publisher policies. – Kev Nov 19 '08 at 16:29

2 Answers2

2

Ok...at a stab...

1 - have you tried using the Assembly Binding Log Viewer (Fuslogvw.exe) to see what assembly binding is taking place?

You can find it in:

C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\FUSLOGVW.exe (with VS2008 installed).

2 - "I have the common assembly (there are actually five, but lets keep it simple) on a network drive," - Are both assemblies resident on the network drive?

Update: Ok...if the new assembly is on a network drive there are probably some trust issues. Can you deploy the new assemblies to a local drive on the server then re-install to the GAC?

Update2: I know..stupid stuff....you have definitely got the publicKeyToken and version number correct? i.e. Your AssemblyVersion attribute for the new assembly is definitely 1.1.0.0 and the public key token is identical (in the GAC)?

Have you tried removing the culture attribue?

Update3: Hi Max....Can you paste the exact publisher policy file you used? Also...remember that if you are redirecting from a 1.0 to a higher versioned assembly, the publisher policy name must be named using the major.minor version of the assembly you're redirecting from. So in your case the publisher policy should be named 'policy.1.0.Leggett.Common.dll'. I notice you've named it 'policy.1.1.Leggett.Common.dll' which may be the reason it's not working.

And finally you must make sure you sign the publisher policy with the same key as used by the 1.0 and 1.1 assemblies.

I built a couple of DLL's and dropped them in the GAC then used a console app in VS to test and it does work :)

Update4: Hi Max, something I never thought about. When you created the publisher policy file, did you specify the platform? Try building it with:

al /link:1.1.Leggett.Common.policy /out:policy.1.0.Leggett.Common.dll /keyfile: /version:1.0.0.0

Leave out the /platform switch and explicitly specify the version number.

Cheers
Kev

Kev
  • 118,037
  • 53
  • 300
  • 385
  • We don't have VS2008 at work. I know that it's not getting the new version though because I used this: Response.Write(typeof(ApplicationSecurityContext).Assembly.FullName); No they aren't both on the network drive. Just the latest is. – Max Schmeling Oct 08 '08 at 23:02
  • Yes it's all identical. I haven't tried removing the culture attribute. Where should I remove it from? The reference? – Max Schmeling Oct 08 '08 at 23:28
  • OH. That makes sense but I didn't think about it. I did use the major.minor of the new one instead of the old one for the name. I'll change that and see if I can get it to work. – Max Schmeling Oct 09 '08 at 18:25
  • Still nothing. It's driving me crazy... here's a screenshot: http://picasaweb.google.com/schmeling88/Public#5255267654653332066 – Max Schmeling Oct 09 '08 at 21:23
  • I am a bit stumped...are you certain that the version numbers are correctly set in the AssemblyVersion attributes on both the old and new DLL i.e. 1.0.0.0 in v1 and 1.1.0.0 in v2 of Leggett.Common.dll'? – Kev Oct 10 '08 at 17:56
  • I'm certain the attributes are correct. I have been unable to work on this today due to some fires I've had to put out, but if I can't get this figured out over the weekend I'll probably take you up on that offer. I really appreciate your willingness to help. – Max Schmeling Oct 10 '08 at 20:12
  • If you look a little over half way down on this link you'll see where it says I'm supposed to specify /platform:msil http://msdn.microsoft.com/en-us/library/dz32563a.aspx But when I do, I get the following error: ALINK: error AL1012: 'msil' is not a valid setting for option 'platform' – Max Schmeling Oct 12 '08 at 23:27
  • It looks like anycpu = MSIL... but it still doesn't work if I use that... this is really getting ridiculous. – Max Schmeling Oct 12 '08 at 23:46
2

You're identifying the assembly correctly, but for anyone else who's reading, reference the assembly by its root in the assemblyIdentity element without the file extension (e.g., "Fubar" and not "Fubar.dll").

Microsoft's documentation neglects to mention that... #$%#!(!@!

  • Not only that, but the assemblyIdentity name can be totally different than the dll filename. – N73k Apr 11 '19 at 01:58