This post originated from an RSS feed registered with .NET Buzz
by Scott Hanselman.
Original Post: Be aware of your DLLs and who's loading them - know about assembly binding redirects
Feed Title: Scott Hanselman's ComputerZen.com
Feed URL: http://radio-weblogs.com/0106747/rss.xml
Feed Description: Scott Hanselman's ComputerZen.com is a .NET/WebServices/XML Weblog. I offer details of obscurities (internals of ASP.NET, WebServices, XML, etc) and best practices from real world scenarios.
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:
Binding before it happens: ILDASM or Reflector will
tell you what your assembly wants (what it was compiled against)
Binding as it happens: Fusion (the Assembly
Binding Log Viewer) will show you all assembly binds if you set
the HKLM\Software\Microsoft\Fusion\ForceLog registry value to 1
Binding after it happens: Process
Explorer will tell you what DLL (assembly) is loaded in memory and from where
it came.
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: