Gotcha in .NET Framework handling of Versions and Publisher Policies
As 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.
About Newsletter
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.