In most cases .NET manages to solve the DLL hell problem pretty well, but sometimes it all falls apart, and when it does in best case scenario we see something like this:
Could not load file or assembly 'XXXX, Version=X.Y.Z.W, Culture=neutral, PublicKeyToken=eb42632606e9261f' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
The much worst case is this:
The method 'XXXX' was not found on the interface/type 'YYYY, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null'.
This post is an analysis of why this happens and how to diagnose it:
As the old saying goes:
There is a log for that.
In this case, it only needs to be turned on:
Enable assembly binding logging (Fusion log)
Assembly binding is turned on using those registry settings:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog- Type of DWORDHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\ForceLog- Type DWORDHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\LogFailures- Type DWORDHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\LogResourceBinds- Type DWORDHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\LogPath- Type String
To enable logging the first four should be set to 1 and the last to a existing directory path (it should also end with an \).
It can be done manually with the use of regedit.exe, but since it can be automated, here are the scripts:
Disable Fusion Log Enable Fusion Log
CHECK THE FILES CONTENT BEFORE RUNNING! (they are just text files) DON’T RUN THIS OR ANY OTHER SCRIPT WITHOUT CHECKING. MODIFYING REGISTRY REQUIRES ADMINISTRATOR PERMISSIONS, SO A LOT OF HARM CAN BE DONE WHEN RUNNING A SCRIPT FORM A NOT TRUSTED SOURCE.
After enabling assembly binding logging, there are two ways to continue:
Analyse assembly binding logs with Fuslogvw
Windows has a build-in tool called Fuslogvw.exe. It should be located in several places, but the pattern is: C:\Program Files (x86)\Microsoft SDKs\Windows\<<SDK_VERSION>>\bin\NETFX <<RUNTIME_VERSION>> Tools\. Any version will do since the tool is available from .NET version 1.1, and the version numbers between 4.6.2 and 4.0 differ only in minor version. The tool is simple, so I won’t describe how it works. I personally prefer the other way:
Reading assembly binding log files (Fusion Log)
This is my preferred way to diagnose. After dealing with many Microsoft loggs, I think the assembly binding ones are the best ones. The files are named using a pattern like this:
[assembly name], Version=[assembly version], Culture=[culture], PublicKeyToken=[public token]
so for NLog we will have:
NLog, Version=4.0.0.0, Culture=neutral, PublicKeyToken=5120e14c03d0593c
The best way to understand how .NET runtime loads assemblies let’s look at the logs.
The operation completed successfully.
First an easy one - the one that succeeded.
*** Assembly Binder Log Entry (25.02.2017 @ 13:44:54) ***
The operation was successful.
Bind result: hr = 0x0. The operation completed successfully.</a>
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable d:\src\FusionLogTest\FusionLogRunner\bin\Debug\FusionLogRunner.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: DisplayName = NLog, Version=3.2.1.0, Culture=neutral, PublicKeyToken=5120e14c03d0593c
(Fully-specified)
LOG: Appbase = file:///d:/src/FusionLog/FusionLogRunner/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = FusionLogRunner.exe
Calling assembly : FusionLogLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
=== LOG: This bind starts in default load context.
LOG: Using application configuration file: d:\src\private\FusionLog\FusionLogRunner\bin\Debug\FusionLogRunner.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Redirect found in application configuration file: 3.2.1.0 redirected to 4.0.0.0.
LOG: Post-policy reference: NLog, Version=4.0.0.0, Culture=neutral, PublicKeyToken=5120e14c03d0593c
LOG: Binding succeeds. Returns assembly from d:\src\private\FusionLog\FusionLogRunner\bin\Debug\NLog.dll.
LOG: Assembly is loaded in default load context.
The operation failed.
Now for something harder, but more interesting. A failed log file. Also for NLog.
*** Assembly Binder Log Entry (25.02.2017 @ 14:46:28) ***
The operation failed.
Bind result: hr = 0x80131040. No description available.
Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Running under executable d:\src\FusionLogTest\FusionLogRunner\bin\Debug\FusionLogRunner.exe
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: DisplayName = NLog, Version=4.0.0.0, Culture=neutral, PublicKeyToken=5120e14c03d0593c
(Fully-specified)
LOG: Appbase = file:///d:/src/FusionLog/FusionLogRunner/bin/Debug/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = FusionLogRunner.exe
Calling assembly : FusionLogLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: d:\src\private\FusionLog\FusionLogRunner\bin\Debug\FusionLogRunner.exe.Config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Redirect found in application configuration file: 3.2.1.0 redirected to 4.0.0.0.
LOG: Post-policy reference: NLog, Version=4.0.0.0, Culture=neutral, PublicKeyToken=5120e14c03d0593c
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///d:/src/FusionLog/FusionLogRunner/bin/Debug/NLog.DLL.
LOG: Assembly download was successful. Attempting setup of file: d:\src\FusionLog\FusionLogRunner\bin\Debug\NLog.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: NLog, Version=3.2.1.0, Culture=neutral, PublicKeyToken=5120e14c03d0593c
WRN: Comparing the assembly name resulted in the mismatch: Major Version
ERR: The assembly reference did not match the assembly definition found.
ERR: Run-from-source setup phase failed with hr = 0x80131040.
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
How to fix “Could not load file or assembly”?
There can be many cases why the assembly fails to load, but 99% of them can be simplified to two solutions presented bellow:
Update the reference
If one of the projects in Your solution has a different version of the assembly this assembly may be copied with it down to the folder of the executable assembly often overwritten the version You would assume it should have. This is the reason why it is a good practice to have all references pointing to a single version of a given assembly. The easiest way to make sure that this is the case is by using Package Manager from Visual Studio (right click on the solution):
And then: 
Then update, build, test, commit and push.
Things may not always be that as easy, because we can’t control references that external libraries, like NuGet packages, have. This is when the second solution comes in:
Add assembly binding redirect
Look at the succeded log file, and the entry about a found redirect. The runtime can be instructed to use another version of the assembly than the one that was called. This is called binding redirect and can be defined in the config file of the main assembly (adding this in the config file of a library won’t matter for the runtime). In case of a Windows application, it’s the app.config file, and in a case of an ASP app the config file structure (web.configs and down) is being searched.
An example:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="NLog" publicKeyToken="5120e14c03d0593c" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
This entry is saying that all assemblies matching all the rules:
- named
NLog - having a public key token with value
5120e14c03d0593c - culture equal to
neutral - having version between
0.0.0.0and4.0.0.0
Should be redirected to a assemble with version 4.0.0.0.
Troubleshooting FusionLog
I don’t see the logs from my application
The application has to be restarted after enabling the log. When talking about IIS application the whole IIS process has to be restarted.
I don’t see the folder
You have to create the folder manually
The application runs slower
The logging adds some overhead, but not enough for it to be seen with a bare eye. Maybe You are doing a lot of dynamic assembly loading?
Something is eating up my disc space
Disable the log. When enabled it creates a lot of small files. The result is that they are taking up more disc space than they actual size.
The logs are still being created despite disabling the logging
Restart the application process.
Why is it called fusion log?
I suspect because fusion is the process of combining two atoms into one.