Have you ever deployed your pages to SharePoint to have some binary files refusing to load and throwing the following exception?

Figure 1. File Not Found exception not specifying the failing assembly.

File Not Found.   at System.Reflection.Assembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, Assembly locationHint, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection)

Sometimes, it’s effortless to resolve this error by simply adding <%@Register> directives to reference some assemblies in your page markup, other times you will not be able to figure out what went wrong, it really could be lengthy and tiresome because the exception message never specifies the assembly that is failing to load. Luckily, Microsoft .Net Framework SDK comes with a very handy tool named “Assembly Binding Log Viewer” which can assist you diagnosing this issue.

The “Assembly Binding Log Viewer” keeps track of all assembly binding attempts that happen on your system. Although this tool ships with the .NET Framework, it’s really less known, this blog post will help you to get started with the Assembly Binding Log Viewer and understanding how you can use it to resolve this kind of exceptions.

a. Create a custom page and add the following Register directive at the top of the page :

<%@ Register Tagprefix=”UnderstandingSharePointJournal” Namespace=”USPJ.BonusIssue.SharePoint.Troubleshooting” Assembly=”USPJ.BonusIssue, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c” %>

b. Go to Start >Microsoft Visual Studio 2005/2008 >Visual Studio tools->Visual Studio Command prompt and type fuslogvw. You will get a window similar to the one below.

Figure 2. Assembly Binding Log Viewer Window.

c. Click on the settings menu to bring up the settings for fuslogvw.exe. You have the choice to log all the binds that are happening or you can instruct the tool to only log the failures. It’s also very useful to capture those entries into your file system so that you can refer to them later on.
Note: One strange bug with Fuslogvw.exe is that unless you specify a custom logging directory, the logging won’t work…

Figure 3. fuslogvw.exe Settings dialog box.

d. Run IISRESET from the command prompt.

e. Navigate to your page from your web browser to reproduce the issue.

f. Click the Refresh button in the window.

Figure 4. fuslogvw.exe monitoring all the bind failures.

g. Now you can search for the failures and find out which assembly is causing the page to crash. In our case, the .NET framework wasn’t able to locate the assembly USPJ.BonusIssue at runtime. You can double-click any of the entries in the main window to see exactly how and what the .NET runtime was doing to look for the assemblies your page referenced.

Figure 5. More information about the failure by double clicking the entry.