# Binding Redirects

DevFeed: [Binding Redirects](<https://devfeed.tech/articles/binding-redirects-21596.md>)

Original publisher: [Read original article](<https://nickcraver.com/blog/2020/02/11/binding-redirects/>)

Published: 2020-02-11T00:00:00Z

Content type: tutorial

Language: en

Sources: [Nick Craver](<https://devfeed.tech/sources/nick-craver.md>)

Topics: [.NET](<https://devfeed.tech/topics/net.md>), [net core](<https://devfeed.tech/topics/net-core.md>), [.NET Framework](<https://devfeed.tech/topics/net-framework.md>), [migration](<https://devfeed.tech/topics/migration.md>), [NuGet](<https://devfeed.tech/topics/nuget.md>), [Visual Studio](<https://devfeed.tech/topics/visual-studio.md>)

Tags: [blog](<https://devfeed.tech/tags/blog.md>), [compatibility](<https://devfeed.tech/tags/compatibility.md>), [dependencies](<https://devfeed.tech/tags/dependencies.md>), [framework](<https://devfeed.tech/tags/framework.md>), [migration](<https://devfeed.tech/tags/migration.md>), [net](<https://devfeed.tech/tags/net.md>), [net-core](<https://devfeed.tech/tags/net-core.md>), [net-framework](<https://devfeed.tech/tags/net-framework.md>), [nuget](<https://devfeed.tech/tags/nuget.md>), [visual-studio](<https://devfeed.tech/tags/visual-studio.md>)

## AI overview

This tutorial explains how .NET Framework assembly version conflicts produce load errors and build warnings. It recommends migrating to .NET Core as the long-term approach and describes binding redirects as the main fix for applications that remain on .NET Framework.

## Source excerpt

This isn't part of the series on Stack Overflow's architecture, but is a topic that has bitten us many times. Hopefully, some of this information helps you sort out issues you hit. You're probably here because of an error like this: Could not load file or assembly 'System.<...>, Version=4.x.x.x, Culture=neutral, PublicKeyToken=<...>' or one of its dependencies. The system cannot find the file specified. And you likely saw a build warning like this: warning MSB3277: Found conflicts between different versions of "System.<...>" that could not be resolved. Whelp, you're not alone. We're thinking about starting a survivors group. The most common troublemakers here are: System.Memory (NuGet link) System.Net.Http (NuGet link) System.Numerics.Vectors (NuGet link) System.Runtime.CompilerServices.Unsafe (NuGet link) System.ValueTuple (NuGet link) If you just want out of this fresh version of DLL Hell you've found yourself in... The best fix The best fix is "go to .NET Core". Since .NET Framework (e.g. 4.5, 4.8, etc.) has a heavy backward compatibility burden, meaning that the assembly loader itself is basically made of unstable plutonium with a hair trigger coated in flesh eating bacteria behind a gate made of unobtanium above a moat of napalm filled with those jellyfish that kill you...that won't ever really be fixed. However, .NET Core's simplified assembly loading means it just works. I'm not saying a migration to .NET Core is trivial, that depends on your situation, but it is generally the best long-term play. We're almost done porting Stack Overflow to .NET Core, and this kind of pain is one of the things we're very much looking forward to not fighting ever again. The fix if you're using .NET Framework The fix for .NET Framework is "binding redirects". When you are trying to load an assembly (and if it's strongly named, like the ones in the framework and many libs are), it'll try to load the specific version you specified. Unless it's told to load another (likely newer) version. T