Every one of us, software developers, experienced situations where the .Net Framework could not locate an assembly and ended up facing the TypeLoadException. These failures usually happen due to an assembly deployed to the wrong location or a mismatch in version numbers or cultures. A quick way to check what went wrong is to open the module window (Visual Studio) during debugging but that may be sometimes impossible or inconvenient because:

• We may not have Visual Studio installed. 
• We installed the product in the customer site and we don’t have the code available.
• It is some third party assemblies which causes the problems.

Luckily, there is an assembly binding log viewer which displays information that helps us diagnose why the .NET Framework can not locate an assembly at run time. This tool is called Fuslogvw (short for Fusion Log Viewer) and can be launched from the Visual Studio Command Prompt. Go to Start->Microsoft Visual Studio 2005/2008->Visual Studio tools->Visual Studio Command prompt and type fuslogvw. This is what you get:

Here is how to use it:

• Press “Settings” (in the main window).
• Choose “Log bind failures to disk”.
• Check the “Enable custom log path”.
• Enter a custom log path, notice that it should be an existing folder and press OK.
• Run the application that crashes to reproduce the binding failure.
• After the failure happens press “Refresh.” One or more lines should appear in the list view.
• Identify the relevant line and either double-click it or press “View Log”.
• A window with a detailed log of what caused the binding failure appears. Read it carefully to understand the problem.

Although this tool is already installed with the .NET Framework, many developers don’t know about it, so I hope that this post will help spread the word about fuslogvw because it may become very helpful sometimes.