There are situations sometimes when .NET loads wrong assembly or can't load one at all. Usually we can see TypeLoadException in that case. Assuming we have exception at all.
One of my work colleagues had situation today that gave a real world example for post I was thinking about quite long time. There was a test class in a project and everything worked fine till he made one very small change in one of test fixtures. When he ran NUnit again he noticed that there is still old version of the assembly. Quick look into Reflector gave expected results; assembly was well compiled and contains new method as expected. However, NUnit was still stubborn. There can be many situations like that, when in our opinion all is perfect but isn't and .NET fails with loading assembly or loads incorrect one.
To diagnose that problem we will use Assembly Binding Log. If you will take a look into .NET Framework directory you will see a fusion.dll. This inconspicuous file is responsible for finding locating the correct assembly and, what is more important, can produce a log of that. As a pair for that we have simple tool named fuslogvw.exe that can be found in Visual Studio directory. This small tool is an Assembly Binding Log Viewer and is able to get logs created by fusion.dll, save them on disk and of course display.
The easiest way to run it is to start Visual Studio Command Prompt and type fuslogvw but be careful. In Visual Studio .NET 2003 is older version that works with .NET 1.x while VS 2005 and Orcas have newer version that works with .NET 2.0.
To be able to get log we have to configure fusion to create log files for us. Click on Settings opens small configuration window.
By default log is disabled. We can turn on logging for specific situations such as binding failures or just log everything. Good practice is here to set up log to custom path. If we are dealing with TypeLoadException or similar problems we can just log failures. However is you know, as we knew, the something is wrong but you don't have exception turn on logging for all bindings. Now you can run code/program that causes the problem and click Refresh when it will finish. You should see something like on screen below.
Double click on any log entry will open whole log for that assembly. Information you can find there is sometimes amazing. There is example for loading nunit.framework I made during writing that post.
By analysing that information you should be able to find the problem. In our case it was ... shadow copy made by NUnit. From unknown reason NUnit didn't refresh his copy. And that was the proof:
Ah. Don't forget to turn logging of when you finish.
There is a lot of articles over the Internet about fusion and debugging problems with assembly loading, however this is kind of information that can be repeated over and over. To be honest I'm quite surprised why this is not as popular as I could expect. So if you already know all of that then congratulation but if you don't remember and use that. As my colleague said, "This is life saving tool".
06-28-2007 5:27 PM