When it rains it pours. Twice today folks came looking when unexpected behaviors occured after an SDK upgrade.
If you're using a versioning scheme, always ask yourself, what version of my assembly has been loaded into this AppDomain? It's even more important to be aware (and not to Program By Coincidence) when using the GAC.
Digging into the problem showed that the wrong version was being loaded - an older version from the GAC due to an incorrect bindingRedirect.
A few tools to be aware of and WHAT they tell you about Assembly Binding:
In this case, a little command line showed me:
C:\>gacutil /l | find /i "Corillian" | more <snip>Corillian.Thingie.Whatzit, Version=18.104.22.168, Culture=neutral, PublicKeyToken=xxCorillian.Thingie.Whatzit, Version=22.214.171.124, Culture=neutral, PublicKeyToken=xx
Ah! There's an older version in the GAC, probably supporting another Web on this box. Our ASP.NET site was compiled against this (says Reflector) and we confirm the wrong one was loaded with Process Explorer. But, we need a bug fix from the new version and can't recompile, so, in our Web.config we added:
<runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Corillian.Thingie.Whatzit" publicKeyToken="xx" culture="neutral" /> <bindingRedirect oldVersion="126.96.36.199" newVersion="188.8.131.52" /> </dependentAssembly> </assemblyBinding></runtime>
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. I am a failed stand-up comic, a cornrower, and a book author.
Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.