Sometimes you are really puzzled as to what is happening when you start a .NET application. Sometimes it insists on loading a different assembly than the one you want it to; even you just copied the new assembly to the bin-folder of your application? Does this sound familiar?
I today had that exact experience. My system kept loading a different assembly than the one I wanted it to; even I in fact did copy the right (new) assembly to the bin folder of the application.
So how do you troubleshoot this scenario? You simply can’t get your head around what is happening? Here there is only 1 way of moving forward: Fusion Log Viewer
The process of starting/loading an exe-file in .NET, begins with the task of merging the exe-file together with dependent assemblies (.dll) into one coherent whole. This is in .NET known as “fusion” (to merge together different artifacts into one). Here lies the key to the whole scenario – the Fusion process.
The fusion process can be made evident to you by using the tool Fusion Log Viewer:
It is found here:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools\x64\FUSLOGVW.exe
How to do:
1) Open this application and set these values:
2) Launch your application (exe) of interest
3) Observe how entries are inserted into the Fusion Log Viewer
4) Double click one of the entries to observe details.
In my case, I got this information:
As evident from the assembly loading log above, the dependent assembly actually being loaded was coming from the GAC (Omada.Common.License.dll), explaining why I did not see my new assembly (Omada.Common.License.dll) which is placed next to my exe-file.
The probing process goes like this:
1) Look in the GAC
2) Look in the folder of the exe-file
3) Look in any subfolder (first level) of the folder holding the exe-file
4) Give up!
Hope it helps you in your debugging…
Update: You need to start this FusionLogViewer with Administrative Rights. Otherwise it is just blank.