Introduction

The error HRESULT 0x80131040 ("The located assembly's manifest definition does not match the assembly reference") occurs when the .NET CLR finds an assembly on disk but its version, culture, or public key token does not match what was requested at compile time. This is a FileLoadException — the file exists but is the wrong version. The most common fix is adding a binding redirect in your app.config or web.config to map the requested version to the version actually present.

The Error

1System.IO.FileLoadException: Could not load file or assembly
2'Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'
3or one of its dependencies. The located assembly's manifest definition
4does not match the assembly reference. (Exception from HRESULT: 0x80131040)

This means the CLR found Newtonsoft.Json.dll but its embedded version number does not match 12.0.0.0. Perhaps version 13.0.0.0 is on disk while the code was compiled against 12.0.0.0.

Why This Happens

Version Mismatch Scenarios

1Project A references Newtonsoft.Json 12.0.0.0
2Project B references Newtonsoft.Json 13.0.0.0
3Both projects are in the same solution
4→ Only one version ends up in the bin/ folder
5→ One project gets the wrong version at runtime

Common triggers:

• NuGet package version conflicts — different projects reference different versions of the same package
• Transitive dependencies — Package X depends on Newtonsoft.Json 12.x, Package Y depends on 13.x
• GAC interference — an old version in the Global Assembly Cache overrides the local copy
• Strong naming — strong-named assemblies require exact version matches unless redirected

Fix 1: Add Binding Redirect

1<!-- app.config or web.config -->
2<configuration>
3  <runtime>
4    <assemblyBinding xmlns="urn:schemas-v1:asm.v1">
5      <dependentAssembly>
6        <assemblyIdentity name="Newtonsoft.Json"
7                          publicKeyToken="30ad4fe6b2a6aeed"
8                          culture="neutral" />
9        <bindingRedirect oldVersion="0.0.0.0-13.0.0.0"
10                         newVersion="13.0.0.0" />
11      </dependentAssembly>
12    </assemblyBinding>
13  </runtime>
14</configuration>

This tells the CLR: "Any request for Newtonsoft.Json versions 0.0.0.0 through 13.0.0.0, load version 13.0.0.0 instead." The newVersion must match the assembly version actually in your bin/ folder.

Fix 2: Enable Auto-Generated Binding Redirects

1<!-- In your .csproj file -->
2<PropertyGroup>
3  <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
4  <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
5</PropertyGroup>

MSBuild analyzes all referenced assemblies and generates the correct redirects automatically in the output config file. This is the recommended approach for .NET Framework 4.5.1+ projects.

Fix 3: Consolidate NuGet Versions

1# Find which packages reference conflicting versions
2dotnet list package --include-transitive
3
4# Update all projects to the same version
5dotnet add package Newtonsoft.Json --version 13.0.3

In Visual Studio: right-click the solution, select Manage NuGet Packages for Solution, go to Consolidate, and align all projects to the same package version.

Fix 4: Clean and Rebuild

1# Old DLLs in bin/ can cause stale version conflicts
2dotnet clean
3dotnet restore
4dotnet build
5
6# Or in Visual Studio: Build → Clean Solution, then Build → Rebuild Solution

Sometimes the bin/ folder contains a leftover DLL from a previous package version. Cleaning removes all build artifacts and forces a fresh copy.

Fix 5: Check the GAC

1# List assemblies in the GAC matching a name
2gacutil /l Newtonsoft.Json
3
4# If an old version is registered, remove it
5gacutil /u "Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed"

The GAC takes priority over local assemblies. If an old version is registered globally, the CLR loads it instead of the version in your bin/ folder.

Diagnosing with Fusion Log

Enable the Assembly Binding Log Viewer to see exactly what the CLR is doing:

1# Enable Fusion logging (run as admin)
2reg add "HKLM\SOFTWARE\Microsoft\Fusion" /v ForceLog /t REG_DWORD /d 1 /f
3reg add "HKLM\SOFTWARE\Microsoft\Fusion" /v LogPath /t REG_SZ /d "C:\FusionLog\" /f
4
5# View logs
6fuslogvw.exe

1// Or catch the exception and inspect details
2try
3{
4    var assembly = Assembly.Load("Newtonsoft.Json");
5}
6catch (FileLoadException ex)
7{
8    Console.WriteLine(ex.FusionLog);  // Detailed binding log
9}

The Fusion log shows every step the CLR takes: which paths it probes, what version it finds, and why the binding failed.

Finding the Actual Assembly Version

1// Check what version is in your bin/ folder
2var asm = typeof(Newtonsoft.Json.JsonConvert).Assembly;
3Console.WriteLine(asm.FullName);
4// Newtonsoft.Json, Version=13.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed

# PowerShell — inspect a DLL file
[System.Reflection.AssemblyName]::GetAssemblyName("bin\Debug\Newtonsoft.Json.dll").Version
# 13.0.0.0

The newVersion in your binding redirect must match this actual version.

.NET Core / .NET 5+ Projects

This error is much less common in .NET Core and .NET 5+ because they use a different assembly loading model that is more lenient about versioning:

1<!-- SDK-style project — binding redirects are not used -->
2<Project Sdk="Microsoft.NET.Sdk">
3  <PropertyGroup>
4    <TargetFramework>net8.0</TargetFramework>
5  </PropertyGroup>
6</Project>

If you still encounter it in .NET Core, it is usually because a NuGet package bundles the wrong DLL version. Update the package or file an issue with the package maintainer.

Common Pitfalls

• Wrong newVersion in redirect: The newVersion must match the assembly version in your bin/ folder, not the NuGet package version. Assembly version 13.0.0.0 may come from NuGet package 13.0.3. Check with AssemblyName.GetAssemblyName().
• Missing publicKeyToken: If you omit publicKeyToken in the assemblyIdentity, the redirect is ignored for strong-named assemblies. Get the token from the error message or use sn -T assembly.dll.
• Config file not deployed: The app.config is copied to <assembly>.exe.config on build. If you edit the config manually in the output folder, it gets overwritten on the next build. Always edit the source app.config.
• Multiple config transforms: Web projects may have web.Debug.config and web.Release.config transforms that add or remove binding redirects depending on the build configuration. Check the transformed output, not just the base config.
• NuGet restore restores old versions: If packages.lock.json or packages.config references an old version, dotnet restore brings back the old DLL. Delete the lock file and restore again, or update the package reference first.

Summary

• HRESULT 0x80131040 means the CLR found an assembly but its version does not match the requested version
• Add a binding redirect in app.config/web.config to map old versions to the version on disk
• Enable AutoGenerateBindingRedirects in your .csproj for automatic resolution
• Consolidate NuGet package versions across all projects in your solution
• Use Fusion Log Viewer (fuslogvw.exe) to diagnose exactly which version the CLR is finding
• This error is rare in .NET Core/.NET 5+ due to a more flexible assembly loading model