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 DWORD

- Type of DWORD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\ForceLog - Type DWORD

- Type DWORD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\LogFailures - Type DWORD

- Type DWORD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\LogResourceBinds - Type DWORD

- Type DWORD HKEY_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:

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.0 and 4.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.