Fusion binding log and fuslogvw.exe
Suzanne blogs again! This time, she is helping you on diagnose MissingMethodException.
Of course, whatever she tries to help you, she can't live without fusion log.
So what exactly is fusion log?
Remember what fusion's role is in assembly binding? Fusion is responsible for finding the actual bits, and handing it over to loader. Because the fusion probing rule is vastly different from normal LoadLibrary rule, fusion includes some logging information to help diagnostic assembly binding failures. For every major event, fusion will log a message. Those events include app.config lookup, policy resolution, GAC lookup, every location fusion probes, and more.
By default, the log is kept in memory, and is included in FileNotFoundException (If you read FileNotFoundException's document, you will find it has a member called “FusionLog“, surprise!). If you ask, fusion will dump the log into an HTML file, and later can be viewed using fuslogvw.exe, assembly binding log viewer shipped as an SDK tool.
As we shipped in 1.0 and 1.1, there are three things affecting how fusion dumps the log. They are all reg keys under HKLM\Software\Microsoft\Fusion.
1. REG_DWORD LogFailures:
If LogFailures is set to 1, fusion will dump the log to disk if the assembly binding did not succeed.
2. REG_DWORD ForceLog:
If ForceLog is set to 1, fusion will dump all logs to disk, regardless the assembly binding succeeded or not.
3. REG_SZ LogPath:
By default fusion dumps the logs to your IE cache. But if LogPath is set, fusion will dump the logs to the path specified. The LogPath has to be an existing folder to make it effective.
Fuslogvw.exe is covered by MSDN. I don't want to copy the document here. But I'll point out some common pitfall when people use this tool.
1. Fuslogvw reads the log settings once, and never reads the settings again. So if you changed the settings (especially LogPath), you have to close it, and re-run it to pick up the change.
2. There are three radio buttons in fuslogvw.exe. Default coresponds to IE cache. ASP.NET is useless. Custom means the LogPath. If you set LogPath, you have to click the custom button to see the actual logs. If you did not set LogPath, you have to click the default button to see the logs.
3. If you want to see logs for services running under a different credential than yours, you have to set LogPath, run the services, then run fuslogvw.exe, and select the custom button to see their logs. The reason is by default the logs are stored in their IE cache which you can't see. You have to set the LogPath so everyone will log to the same place.
Fuslogvw.exe gets a little bit improvement in the next version of .Net framework. But then I am not a UI guy. I only spent half a day reading Charles Petzold's “Programming Windows” before I set improve fuslogvw.exe. When you get change, play around with the new fuslogvw.exe, and send me feedback if possible.
