Assembly binding redirect does not work

assembly binding

binding redirect

.NET framework

configuration issues

troubleshooting

Assembly binding redirect does not work

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Start Practicing Learn More

Introduction

When an assembly binding redirect in app.config or web.config does not work, the most common causes are: the redirect is in the wrong config file, the publicKeyToken is missing or wrong, the newVersion does not match the actual assembly on disk, or AutoGenerateBindingRedirects is overwriting your manual redirect. Diagnosing requires the Fusion Log Viewer (fuslogvw.exe) to see exactly what the CLR is loading and why it rejects the binding.

A Correct Binding Redirect

xml

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

Every part matters: name, publicKeyToken, culture, oldVersion range, and newVersion must all be correct.

Cause 1: Wrong Config File

1Project type          Config file read by CLR
2─────────────────────────────────────────────
3Console app           bin/Debug/MyApp.exe.config  (copied from app.config)
4Web app (IIS)         web.config
5Class library         Does NOT have its own config — uses the host app's config
6Unit test             The test runner's config, not the library's

xml

1<!-- Common mistake: putting redirect in a class library project -->
2<!-- ClassLibrary/app.config — THIS IS IGNORED -->
3<configuration>
4  <runtime>
5    <assemblyBinding xmlns="urn:schemas-v1:asm.v1">
6      <dependentAssembly>
7        <!-- This redirect is never read by the CLR -->
8      </dependentAssembly>
9    </assemblyBinding>
10  </runtime>
11</configuration>
12
13<!-- Fix: put the redirect in the EXECUTABLE project's config -->
14<!-- MyApp/app.config — THIS IS READ -->

The CLR reads the config of the entry-point assembly (the .exe or web app), not library projects.

Cause 2: Wrong publicKeyToken

bash

1# Find the correct public key token
2sn -T Newtonsoft.Json.dll
3# Microsoft (R) .NET Framework Strong Name Utility
4# Public key token is 30ad4fe6b2a6aeed
5
6# Or use PowerShell
7[System.Reflection.AssemblyName]::GetAssemblyName("bin\Debug\Newtonsoft.Json.dll").GetPublicKeyToken() |
8  ForEach-Object { $_.ToString("x2") } | Join-String
9# 30ad4fe6b2a6aeed

If publicKeyToken is wrong or missing, the redirect silently does nothing. The token must match the assembly's strong name exactly.

Cause 3: newVersion Does Not Match the DLL

bash

# Check the ACTUAL assembly version in your bin folder
[System.Reflection.AssemblyName]::GetAssemblyName("bin\Debug\Newtonsoft.Json.dll").Version
# 13.0.0.0

xml

1<!-- WRONG: newVersion does not match the DLL -->
2<bindingRedirect oldVersion="0.0.0.0-13.0.0.0" newVersion="12.0.0.0" />
3<!-- The CLR finds 13.0.0.0 on disk but the redirect says to load 12.0.0.0 -->
4<!-- Result: FileLoadException -->
5
6<!-- RIGHT: newVersion matches the assembly on disk -->
7<bindingRedirect oldVersion="0.0.0.0-13.0.0.0" newVersion="13.0.0.0" />

Note: the NuGet package version (e.g., 13.0.3) is NOT the assembly version (13.0.0.0). Always check the actual assembly version.

Cause 4: AutoGenerateBindingRedirects Overwrites

xml

1<!-- .csproj -->
2<PropertyGroup>
3  <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
4</PropertyGroup>

When enabled, MSBuild generates binding redirects during build, potentially overwriting your manual edits in the output config. Check bin/Debug/MyApp.exe.config — it may differ from your source app.config.

bash

# Compare source config with output config
diff app.config bin/Debug/MyApp.exe.config

Fix: either rely entirely on auto-generation (recommended) or disable it and manage redirects manually.

Cause 5: Missing xmlns Attribute

xml

1<!-- WRONG: missing xmlns on assemblyBinding -->
2<runtime>
3  <assemblyBinding>
4    <dependentAssembly>
5      <!-- Silently ignored! -->
6    </dependentAssembly>
7  </assemblyBinding>
8</runtime>
9
10<!-- RIGHT: xmlns is required -->
11<runtime>
12  <assemblyBinding xmlns="urn:schemas-v1:asm.v1">
13    <dependentAssembly>
14      <!-- Now the CLR reads this -->
15    </dependentAssembly>
16  </assemblyBinding>
17</runtime>

The xmlns="urn:schemas-v1:asm.v1" attribute is mandatory. Without it, the entire assemblyBinding section is silently ignored.

Diagnosing with Fusion Log

bash

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
4reg add "HKLM\SOFTWARE\Microsoft\Fusion" /v LogFailures /t REG_DWORD /d 1 /f
5
6# Run your application, then open the log viewer
7fuslogvw.exe
8
9# Disable logging when done (it slows down all .NET apps)
10reg delete "HKLM\SOFTWARE\Microsoft\Fusion" /v ForceLog /f

The Fusion log shows:

Which version was requested
Which config file was read
Whether a binding redirect was applied
Which path the assembly was loaded from (or why it failed)

Cause 6: GAC Assembly Takes Priority

bash

1# Check if the assembly is in the GAC
2gacutil /l Newtonsoft.Json
3
4# The GAC version may not match your binding redirect target
5# Remove from GAC if not needed
6gacutil /u Newtonsoft.Json

The CLR checks the GAC before local paths. A GAC-installed assembly ignores binding redirects from app.config.

Checklist for Debugging

11. Is the redirect in the CORRECT config file? (exe project, not library)
22. Does the xmlns attribute exist? ("urn:schemas-v1:asm.v1")
33. Is publicKeyToken correct? (check with sn -T)
44. Does newVersion match the assembly in bin/? (check with PowerShell)
55. Is AutoGenerateBindingRedirects overwriting your changes?
66. Is the assembly in the GAC? (check with gacutil /l)
77. Does the Fusion log show the redirect being applied?

Common Pitfalls

Editing the wrong config file: For web apps, edit web.config. For console apps, edit app.config (not MyApp.exe.config in the bin folder — that gets overwritten on build). For test projects, edit the test project's app.config.
Missing xmlns on assemblyBinding: Without xmlns="urn:schemas-v1:asm.v1", the entire binding section is silently ignored. This is the most frustrating issue because there is no error — the redirect simply does not apply.
Confusing NuGet version with assembly version: NuGet package Newtonsoft.Json 13.0.3 has assembly version 13.0.0.0. The binding redirect uses assembly versions, not package versions.
Multiple assemblyBinding elements: Having two <assemblyBinding> elements in the same config causes the second to be ignored. Merge all <dependentAssembly> entries under a single <assemblyBinding> element.
Config transforms removing redirects: web.Release.config transforms may use xdt:Transform="Remove" on binding elements. The development config works but the published config does not. Check the transformed output.

Summary

Binding redirects must be in the entry-point project's config (exe or web app, not class library)
The xmlns="urn:schemas-v1:asm.v1" attribute is required — without it, redirects are silently ignored
newVersion must match the assembly version on disk, not the NuGet package version
Use sn -T assembly.dll to find the correct publicKeyToken
Enable Fusion logging (fuslogvw.exe) to see exactly why a binding fails
Use AutoGenerateBindingRedirects to let MSBuild handle redirects automatically