Scott Hanselman

Gotcha in .NET Framework handling of Versions and Publisher Policies

December 06, 2005 Comment on this post [3] Posted in Bugs
Sponsored By

PubpolicyweirdAs a publisher of libraries, one might find the need to force a redirect to a specific assembly version in order to fix a bug without requiring a recompile of the application consuming your library. Typically this is done by the publisher using Publisher Policy Files.

Peter Thomas, a wise man in the world of such things and fortunately a Corillian employee noticed this:

While debugging a rebinding problem I stumbled upon an interesting behavioral quirk with how Fusion decides which policy file to use.  I had found information on Richard Grimes' Fusion Workshop that stated that if you had multiple policy files for an assembly, the policy file with the latest version would be used.  This doesn’t appear to be completely true.  I found that it uses the policy file with the latest version when the version is sorted alphabetically.

In my case, I had a policy file with a version of 3.1.0.43 and another with the version 20.0.0.0 (for testing).  I had expected 20.0.0.0 to be loaded but I could see via the Fusion logs and ProcessExplorer that the 3.1.0.43 policy file was always being used instead.  I added a new policy file (all these files used the same rebinding info) with the version 4.0.0.0 and that one stated to get used.  Noticing that the ones that worked were single digit versions I created 10.0.0.0 to see if it would fail to be used as well and sure enough, it wasn't loaded.  Finally I created 9.0.0.0 and it did work.  As I looked at the GAC it dawned on me that it loaded the version that was alphabetically last.

This struck me as so bizzare that at first I didn't believe him. However, it's a little-known bug and will possibly be fixed in the Longhorn timeframe. Until then, if you're using .NET 1.x and publisher policy you'll want to avoid double-digit version numbers. For .NET 2.0 we're told:

For .NET 2.0, you won’t run into this issue due to the policy cache. There's a pretty good description of the policy cache here:  http://blogs.msdn.com/junfeng/archive/2005/05/24/421459.aspx.  It's a side effect of the policy cache, the code with the calculation error is avoided due to the policy cache.

Kudos to Peter for chasing it down.

(and No, I'm not back to work, I'm just reporting the news, so phooey on you for thinking it.)

Now playing: Luther Vandross - Hit It Again (featuring Queen Latifah)

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
December 06, 2005 22:36
Fantastic bit of info, pops! Thanks for taking the time to share.
December 07, 2005 0:08
Scott- Thank you so much for posting this. I ran into this problem a while back, and didn't have time to troubleshoot and came up with a workaround that wasn't optimal. I couldn't find an explanation in searching. Not knowing why has been bugging me ever since. -Carol
December 08, 2005 12:34
Scotty

Slightly related, I came across a number of confused customers with version numbers.... So now I start all versions at 11
See http://www.ssw.com.au/ssw/Standards/Rules/RulestoBetterCode.aspx#SetupFileName

Your thoughts?

Adam
www.ssw.com.au

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.