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 184.108.40.206 and another with the version 220.127.116.11 (for testing). I had expected 18.104.22.168 to be loaded but I could see via the Fusion logs and ProcessExplorer that the 22.214.171.124 policy file was always being used instead. I added a new policy file (all these files used the same rebinding info) with the version 126.96.36.199 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 188.8.131.52 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)