Introduction

The error Could not load file or assembly 'System.Net.Http, Version=4.2.0.0' is a common .NET assembly binding issue caused by version mismatches between the System.Net.Http NuGet package and the version shipped with the .NET runtime. The NuGet package (version 4.3.x) references assembly version 4.1.1.x, while .NET Framework 4.7.1+ ships assembly version 4.2.0.0. This mismatch causes FileNotFoundException or FileLoadException at runtime. The fix is to add a binding redirect in your app.config or web.config, or remove the NuGet package and rely on the framework-provided assembly.

The Error

1System.IO.FileLoadException: Could not load file or assembly
2'System.Net.Http, Version=4.2.0.0, Culture=neutral,
3PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies.
4The located assembly's manifest definition does not match
5the assembly reference.

This typically appears when:

• Your project targets .NET Framework 4.6.1+ and references the System.Net.Http NuGet package
• A dependency (like Microsoft.AspNet.WebApi.Client) requires System.Net.Http 4.2.0.0
• The NuGet package provides version 4.1.1.x but the runtime expects 4.2.0.0

Why This Happens

Microsoft ships System.Net.Http in two places with different version numbers:

When a NuGet dependency requests System.Net.Http 4.2.0.0 but the NuGet package only provides 4.1.1.2, the assembly loader cannot find the exact version and throws an exception.

Fix 1: Add a Binding Redirect (Most Common)

Add or update the binding redirect in app.config or web.config:

1<configuration>
2  <runtime>
3    <assemblyBinding xmlns="urn:schemas-v1:asm.v1">
4      <dependentAssembly>
5        <assemblyIdentity name="System.Net.Http"
6                          publicKeyToken="b03f5f7f11d50a3a"
7                          culture="neutral" />
8        <bindingRedirect oldVersion="0.0.0.0-4.2.0.0"
9                         newVersion="4.2.0.0" />
10      </dependentAssembly>
11    </assemblyBinding>
12  </runtime>
13</configuration>

This tells the CLR to redirect any request for System.Net.Http versions 0.0.0.0 through 4.2.0.0 to the version actually available at runtime.

Fix 2: Remove the NuGet Package

If you are targeting .NET Framework 4.7.1 or later, the framework already includes System.Net.Http. Remove the NuGet package to avoid the conflict:

1# Package Manager Console
2Uninstall-Package System.Net.Http
3
4# Or .NET CLI
5dotnet remove package System.Net.Http

Then clean and rebuild:

dotnet clean
dotnet build

After removal, the project uses the framework-provided assembly (4.2.0.0), which matches what dependencies expect.

Fix 3: Auto-Generate Binding Redirects

Enable automatic binding redirect generation in your .csproj:

1<PropertyGroup>
2  <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
3  <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
4</PropertyGroup>

The build process examines all referenced assemblies and generates the correct redirects in the output config file. This handles System.Net.Http and any other version mismatches automatically.

Fix 4: Consolidate NuGet Package Versions

When multiple projects in a solution reference different versions of System.Net.Http:

# Check which projects reference which versions
dotnet list package --include-transitive | grep System.Net.Http

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

Fix 5: Copy Local and Specific Version

If binding redirects do not work, force the correct assembly to be copied to the output:

1<Reference Include="System.Net.Http">
2  <HintPath>..\packages\System.Net.Http.4.3.4\lib\net46\System.Net.Http.dll</HintPath>
3  <Private>true</Private>
4  <SpecificVersion>false</SpecificVersion>
5</Reference>

Setting Private to true (Copy Local = Yes) ensures the NuGet version is in the output directory. Setting SpecificVersion to false allows any version to satisfy the reference.

.NET Core / .NET 5+ Projects

This issue primarily affects .NET Framework projects. .NET Core and .NET 5+ handle assembly versioning differently:

1<!-- SDK-style project — no binding redirects needed -->
2<Project Sdk="Microsoft.NET.Sdk">
3  <PropertyGroup>
4    <TargetFramework>net8.0</TargetFramework>
5  </PropertyGroup>
6  <!-- System.Net.Http is built into the SDK — do not add the NuGet package -->
7</Project>

If you are migrating from .NET Framework to .NET 5+, remove any explicit System.Net.Http NuGet references. The namespace is available by default.

Diagnosing the Issue

1# Find which assemblies reference System.Net.Http
2# Use Fusion Log Viewer (fuslogvw.exe) for detailed binding diagnostics
3
4# Or check assembly versions in your output directory
5powershell -Command "[System.Reflection.AssemblyName]::GetAssemblyName('bin\Debug\System.Net.Http.dll').Version"

1// Print loaded assembly version at runtime
2var assembly = typeof(System.Net.Http.HttpClient).Assembly;
3Console.WriteLine(assembly.FullName);
4// System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

Common Pitfalls

• Binding redirect newVersion mismatch: The newVersion in the binding redirect must match the version that is actually present on disk or in the GAC. Check the actual assembly version in your bin/ folder, not the NuGet package version.
• Multiple config files: Web projects use web.config, console/desktop apps use app.config. ASP.NET projects may also have transforms (web.Release.config) that override redirects. Verify the correct config file is being modified.
• NuGet restore overwrites redirects: Running Update-Package -reinstall or switching NuGet package versions can regenerate binding redirects. If you manually edited redirects, they may be overwritten. Enable AutoGenerateBindingRedirects to avoid this.
• GAC interference: If System.Net.Http is installed in the Global Assembly Cache with a different version, the CLR loads the GAC version instead of the local copy. Use gacutil /l System.Net.Http to check.
• Multi-targeting confusion: Projects targeting both net461 and netstandard2.0 may resolve different versions of System.Net.Http for each target. Test both targets independently and ensure binding redirects exist for the .NET Framework target.

Summary

• The error is caused by assembly version mismatches between the NuGet System.Net.Http package and the .NET Framework built-in version
• Add a binding redirect in app.config/web.config to resolve version conflicts
• For .NET Framework 4.7.1+, removing the NuGet package and using the built-in assembly is often the cleanest fix
• Enable AutoGenerateBindingRedirects in your .csproj for automatic resolution
• .NET Core / .NET 5+ projects do not have this issue — System.Net.Http is part of the SDK
• Use Fusion Log Viewer or runtime reflection to diagnose which version is actually loaded