99.999% of the time the framework loads assemblies seamlessly and transparently. The other 0.001% of the time is so painful that it more than makes up for the rest. One of the more common troublemakers is the Newtonsoft.Json.dll. There are still Microsoft assemblies (System.Net.Http.Formatting! Yup, I called you out!) that reference years-old versions of the Newtonsoft assembly. Any other time you can’t get msbuild to perform indirect reference chaining to save your life, but it does love to look several references back and grab an older version of Newtonsoft. How does that work? Why does it do that?
This topic has been covered ad nauseum on many other forums, so I’ll just present a list of references I’ve used.
How the Runtime Locates Assemblies on MSDN.
Redirecting Assembly Versions on MSDN.
Assembly Binding Log Viewer on MSDN. Also known as the Fusion Log Viewer. This is your best reference for learning exactly what happened when the framework tried to load your assembly. The viewer is already installed on your machine if you have Visual Studio installed. Open the developer command prompt with Admin permissions and type “fuslogvw”. A lot of the older blogs talk about making changes directly to your registry. Don’t do that. Use the utility.
If everything is working properly, including a configured binding redirect, you’ll see something like the image below.
The framework wanted version 6.0, but found a redirect in the config file that told it to use 9.0 instead.
Recently I had an issue that turned out to be malformed XML in the config file. This manifested as the fusion log showing me that the framework was apparently ignoring the configured redirect. It can’t do that, so I dug into the XML and discovered the malformation. The fusion log was invaluable for troubleshooting that issue.
Scott Hanselman has some good tips here.
The MSBuild output is always a wealth of information if you dig through it. In Visual Studio, type “verb” in your Quick Launch to bring up the Build and Run section in the Options dialog. Change “MSBuild project build output verbosity” to Detailed. Rebuild your solution and you’ll get plenty of information that will (hopefully) provide some clues as to the path being followed to get to the assembly.
Things to watch out for:
- Assembly binding redirect configurations.
- Use the log viewer to be sure the framework is using the config file you think it should be using.
s to remember:
- It’s not magic. It’s not random. The framework follows a very specific set of steps to determine which assembly to load. Understanding that process will make you seem like a dark wizard to the muggles.