284

I've copied my project to a clean Windows 10 machine with only Visual Studio 2015 Community and SQL Server 2016 Express installed. There are no other framework versions installed apart from those installed with Windows 10 and VS2015 or SQL Server.

When I try to start the WebApi project I get the message:

Could not load file or assembly "System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" or one of its dependencies. The system cannot find the file specified.

The project's packages include:

<package id="Microsoft.AspNet.WebApi" version="5.2.3" targetFramework="net45" />
<package id="Microsoft.AspNet.WebApi.Client" version="5.2.3" targetFramework="net45" />
<package id="Microsoft.AspNet.WebApi.Core" version="5.2.3" targetFramework="net45" />
<package id="Microsoft.AspNet.WebApi.Tracing" version="5.2.3" targetFramework="net45" />
<package id="Microsoft.AspNet.WebApi.WebHost" version="5.2.3" targetFramework="net45" />

After building the project with .NET Framework 4.6.1, System.Net.Http the file is not found in the bin folder.

The file's path points to:

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.6.1\System.Net.Http.dll

The file's path of System.Net.Http.Formatting points to:

C:\Development\MyApp\packages\Microsoft.AspNet.WebApi.Client.5.2.3\lib\net45\System.Net.Http.Formatting.dll

Should the whole project target 4.5.1 or is there another way to reference the right assemblies?

user2280016
  • 1,799
  • 3
  • 13
  • 17
Ivan-Mark Debono
  • 15,500
  • 29
  • 132
  • 263
  • 1
    have you tried to reinstall Web Api from NuGet package ? – Mihai Alexandru-Ionut Jul 16 '16 at 07:18
  • 1
    related : http://stackoverflow.com/questions/19491860/could-not-load-file-or-assembly-system-web-http-4-0-0-after-update-from-2012-to –  Jul 16 '16 at 07:59
  • Tried all suggested answers in that SO question. Nothing works so far. I've also ran `update-package xxx -reinstall` for all nuget packages I'm using. It doesn't work either. – Ivan-Mark Debono Jul 16 '16 at 08:33
  • Related [Inheritance sec rules violated by type: 'System.Net.Http.WebRequestHandler'.](//stackoverflow.com/q/38626316) – Michael Freidgeim Oct 12 '17 at 05:33
  • Just refer this , thank me later https://stackoverflow.com/questions/50536842/avoiding-trustworthy-on-and-permission-set-unsafe-using-system-net-http – Ragul Jul 16 '18 at 10:57

21 Answers21

336

Changing the binding information in my web.config (or app.config) - while a "hack" in my view, allows you to move forward with your project after a NuGet package update whacks your application and gives you the System.Net.Http error.

Set oldVersion="0.0.0.0-4.1.1.0" and newVersion="4.0.0.0" as follows

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.0.0.0" />
</dependentAssembly>
Wai Ha Lee
  • 8,598
  • 83
  • 57
  • 92
tripletdad99
  • 3,441
  • 2
  • 12
  • 6
  • 6
    I deployed to Azure, once, with no issue, then 15 min later, a successive deployment gave me the exact error stated in the O.P. and tweaking the web.config on the server with this precise answer fixed my issue. But, I have no idea why it ever worked the first time. I didn't mess with my dependencies between deployments. – bkwdesign Apr 21 '17 at 17:20
  • 11
    Good job. I can see what happened, I installed a package in a base domain project that I'm pretty sure had System.Net.Http nuget installed (probably of the higher 4.1.x version), and as soon as I did that I got these warnings everywhere. This fixed the problem for the web project, but the advice above of someone to reference the nuget package for that in all of the projects removed all of the warnings. Am I the only one who is concerned about the mix of the old and new .NET though when it comes to references? It makes me afraid to reference typically local dlls as nuget packages (dll hell). – Nicholas Petersen Nov 22 '17 at 22:10
  • 6
    Here is answer from Microsoft as to why this is the correct way: https://github.com/dotnet/corefx/issues/25773 – GL_monk-342435 Sep 18 '18 at 05:48
  • 51
    Removing the binding redirect completely worked for me. – sbkrogers Jan 20 '19 at 19:15
  • 4
    Yes, just remove the lines of system.net.http and system.runtime. Things then become fine. – ZZZ Sep 17 '19 at 01:04
  • 1
    Updated project to .net 4.8 and this still solves the issue. :) (5 yrs old post.. surprised) – Manish Gupta Feb 16 '22 at 11:02
315

Follow the following steps:

  1. Update Visual Studio to the latest version (it matters)

  2. Remove all binding redirects from web.config

  3. Add this to the .csproj file:

    <PropertyGroup>
      <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
      <GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
    </PropertyGroup>
    
  4. Build the project

  5. In the bin folder there should be a (WebAppName).dll.config file

  6. It should have redirects in it, copy these to the web.config

  7. Remove the above snipped from the .csproj file

It should work.

DaggeJ
  • 2,094
  • 1
  • 10
  • 22
Sajeetharan
  • 216,225
  • 63
  • 350
  • 396
  • 2
    Now im getting Could not load file or assembly 'Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) – EK_AllDay Aug 05 '18 at 22:45
  • 4
    You must remember to copy across the binding redirects from the generated file, so first time you will get the above error, but goto the bin folder to get the generated (webappname).dll.config as described above, copy the entire list of redirects into your web.config, then re-compile. This really helped me, make sure you use the nuget consolidation tool to clean up as many references as you can first though. – Chris Schaller Aug 28 '18 at 00:51
  • 8
    Amazing. This actually worked for me. @EK_AllDay You have to copy the AssemblyRedirects back into the original web.config. – David De Sloovere Sep 11 '18 at 07:34
  • 21
    ⭐☝ Legend badge deserved right here! Just a side-note, when I copied the AssemblyRedirects back into web.config, I see that there is **no longer a binding for System.Net.Http**. So we assume that VS is now using the default assembly packaged with the .Net framework, rather than its own version? – EvilDr Dec 11 '19 at 12:55
  • 3
    I spent more than 6 hours fighting the GAC, Reference Assemblies, Conflicting Versions, Version numbers that dont make sense etc.. etc.. and then I found this Legend badge deserved indeed. This was the only thing that fixed it for me. God I hate System.Net.Http and the muppetry behind all the associated problems with it. DLL Hell still exists – julian guppy Mar 25 '20 at 17:39
  • 1
    This answer saved me so many times I even stopped counting. Should be marked as answer IMHO. – Sebastian Budka May 05 '20 at 07:08
  • 1
    Thanks so much for this answer. Fantastic! I don't save many SO posts, but this one is definitely saved. – John Livermore May 07 '20 at 13:39
  • 1
    What a life-saver. I bet this one took some head scratching. What is the purpose of the binding redirects? I just want to understand a little about why this fix works (such that I can remember it). – Scuba Steve Jun 26 '20 at 17:53
  • 12
    Moving project from 4.7.2 to 4.8 and got the error. Followed the steps, and the end result was just not needing the System.Net.Http binding at all in my web.config. – seagulledge Aug 04 '20 at 20:13
  • 1
    I have been strugling with this so many times - and given up. Thank you sire. – Nicky Aug 28 '20 at 13:08
  • I upgraded from 4.5.2 to 4.7.2. I struggled with this issue for more than 3 days. It saved my time thank you. – Umut Catal Sep 07 '20 at 13:40
  • That's a life saver! By the way do not bother to remove all bindingredirects one by one manually, select "Use Regular Expression" option on Find/Replace. Set Find as and leave Replace empty. Then click Replace All. – hhk Oct 20 '20 at 07:25
  • similar issue on .net framework 4.7.2, I solved by following this https://github.com/dotnet/runtime/issues/26131#issuecomment-396753264 – cwhsu Nov 21 '20 at 12:47
  • 2
    Is this different then running this command in the package manager console? https://weblog.west-wind.com/posts/2014/nov/29/updating-assembly-redirects-with-nuget – jnoreiga Apr 16 '21 at 16:23
  • Thanks for the answer. Readers, please do the steps one by one (1 to 7) the issue will be resolved. – ExOrIntro Aug 23 '22 at 10:53
  • I had different problem, but this actually help me trim out unnecessary bindings when migrating a project to different .NET version. – Dimas Putra May 16 '23 at 08:20
  • I have .net 4.6.2. I tried these steps on the project generating similar error but for System.IO. The solution has like 21 projects. When I build the project now getting this error: Found conflicts between different versions of "System.Net.Http" that could not be resolved. There was a conflict between "System.Net.Http, Version=4.1.1.3, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" and "System.Net.Http, Version=4.2.0.0 – Andy N Jul 05 '23 at 22:10
40

In one of my projects there was a nuget packages with higher version of System.Net.Http. and in my startup project there reference to System.Net.Http v 4.0.0 , i just installed System.Net.Http nuget package in my startup project and the problem solved

Ram Y
  • 1,944
  • 17
  • 23
  • 1
    I have three projects in a solution - let's call them ``A``, ``B`` and ``C``. ``A`` is the startup project, and has nothing to do with either ``B`` or ``C``. ``C`` is a test project for ``B``. Running my tests in ``C`` failed, because I didn't have a reference (System.Net.Http) project ``A`` had. – Rasmus Bækgaard Jun 24 '19 at 13:41
26

Change following:

<bindingRedirect oldVersion="0.0.0.0-4.1.1.2" newVersion="4.1.1.2" />

with the following:

<bindingRedirect oldVersion="0.0.0.0-4.1.1.2" newVersion="4.0.0.0" />

in web.config

Muhammad Waqas
  • 511
  • 6
  • 9
  • 2
    Root Cause: https://coderjony.com/blogs/solution-could-not-load-file-or-assembly-systemnethttp-version-4200-culture-neutral-publickeytoken-b03f5f7f11d50a3a-or-one-of-its-dependencies-the-system-cannot-find-the-file-specified/ – Andy Joiner Sep 21 '20 at 21:28
  • This worked for me, my `oldVersion` was `0.0.0.0-4.2.0.0` - but setting the `newVersion` as above worked. – Lazlow Jan 25 '23 at 10:21
17

The above bind-redirect did not work for me so I commented out the reference to System.Net.Http in web.config. Everything seems to work OK without it.

  <system.web>
    <compilation debug="true" targetFramework="4.7.2">
      <assemblies>
        <!--<add assembly="System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=B03F5F7F11D50A3A" />-->
        <add assembly="System.ComponentModel.Composition, Version=4.0.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089" />
      </assemblies>
    </compilation>
    <customErrors mode="Off" />
    <httpRuntime targetFramework="4.7.2" />
  </system.web>
Marcello B.
  • 4,177
  • 11
  • 45
  • 65
Mark
  • 321
  • 2
  • 8
  • 1
    This works in Visual Studio 2017 (15.9.4) and allows you to build with the System.Net.Http (4.3.4) NuGet package instead of a direct reference to the DLL that ships with the .NET 4.7.2 framework release. To use the shipped reference (with no other dependencies introduced) within the IDE do this: 1) Remove web/app.config binding redirects 2) Remove NuGet package for System.Net.Http 3) Open "Add New Reference" and directly link to the new 4.2.0.0 build that ships with .NET 4.7. – EnocNRoll - AnandaGopal Pardue Jan 10 '19 at 22:22
  • 1
    This worked for me in VS2019, migrating an app from 4.6.1 to 4.7.2 – cklimowski Dec 03 '19 at 22:18
  • I had a console app project that was working as a webjob. It was throwing that exception when creating a SendGrid api client. Everything started working after removing the binding redirect from app.config. Thanks for suggesting this, I would have never thought. – kurdemol94 Feb 07 '20 at 11:33
13

If you have multiple projects in your solution, then right-click on the solution icon in Visual Studio and select 'Manage NuGet Packages for Solution', then click on the fourth tab 'Consolidate' to consolidate all your projects to the same version of the DLLs. This will give you a list of referenced assemblies to consolidate. Click on each item in the list, then click install in the tab that appears to the right.

user3248578
  • 905
  • 8
  • 18
  • 4
    Combine this with the answer from @sajeetharan about using the AutoGenerateBindingRedirects, it seems that older versions either of VS or nuget packages may leave incorrect binding statements. A good clean out can help a lot. – Chris Schaller Aug 28 '18 at 00:54
11

This will work in .NET 4.7.2 with Visual Studio 2017 (15.9.4):

  • Remove web/app.config binding redirects
  • Remove NuGet package for System.Net.Http
  • Open "Add New Reference" and directly link to the new 4.2.0.0 build that ships with .NET 4.7.2

![image](https://user-images.githubusercontent.com/38843378/50998531-b5bb3a00-14f5-11e9-92df-6c590c469349.png)

9

You can fix this by upgrading your project to .NET Framework 4.7.2. This was answered by Alex Ghiondea - MSFT. Please go upvote him as he truly deserves it!

This is documented as a known issue in .NET Framework 4.7.1.

As a workaround you can add these targets to your project. They will remove the DesignFacadesToFilter from the list of references passed to SGEN (and add them back once SGEN is done)

<Target Name="RemoveDesignTimeFacadesBeforeSGen" BeforeTargets="GenerateSerializationAssemblies">
  <ItemGroup>
    <DesignFacadesToFilter Include="System.IO.Compression.ZipFile" />
    <_FilterOutFromReferencePath Include="@(_DesignTimeFacadeAssemblies_Names->'%(OriginalIdentity)')" 
        Condition="'@(DesignFacadesToFilter)' == '@(_DesignTimeFacadeAssemblies_Names)' and '%(Identity)' != ''" /> 
    <ReferencePath Remove="@(_FilterOutFromReferencePath)" />
  </ItemGroup>
  <Message Importance="normal" Text="Removing DesignTimeFacades from ReferencePath before running SGen." /> </Target>

<Target Name="ReAddDesignTimeFacadesBeforeSGen" AfterTargets="GenerateSerializationAssemblies">
  <ItemGroup>
    <ReferencePath Include="@(_FilterOutFromReferencePath)" />
  </ItemGroup>
  <Message Importance="normal" Text="Adding back DesignTimeFacades from ReferencePath now that SGen has ran." />
</Target>

Another option (machine wide) is to add the following binding redirect to sgen.exe.config:

<runtime>
  <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
    <dependentAssembly>
      <assemblyIdentity name="System.IO.Compression.ZipFile" publicKeyToken="b77a5c561934e089" culture="neutral" />
      <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0" />
    </dependentAssembly>
  </assemblyBinding>
</runtime> This will only work on machines with .NET Framework 4.7.1. installed. Once .NET Framework 4.7.2 is installed on that machine, this workaround should be removed.
Jan Wytze
  • 3,307
  • 5
  • 31
  • 51
bezbos.
  • 1,551
  • 2
  • 18
  • 33
7
  1. Open Web.config and remove <runtime> including everything inside it

    <**runtime><assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> </runtime>

  2. Save and close Web.config

  3. Open Package Manager Console and run the command

    Add-BindingRedirect

This solved my problem when my team member upgraded from .NET Framework 4.6.1 to .NET Framework 4.8 and VS 2017 to VS 2022

Syed Nasir Abbas
  • 1,722
  • 17
  • 11
  • This resolved the issue when we moved from Visual Studio 2019 to 2022 for a .Net Framework project. @Syed - Thank you for the answer saved us a lot of time. – Johan J v Rensburg Aug 04 '22 at 09:13
  • This is better than the chosen answer because it does it automatically for you. See [this](https://weblog.west-wind.com/posts/2014/nov/29/updating-assembly-redirects-with-nuget) and [this](https://blog.maartenballiauw.be/post/2014/11/27/could-not-load-file-or-assembly-nuget-assembly-redirects.html) article for a bit more info on this solution. – somethingRandom Feb 01 '23 at 12:50
  • Thank you so much bro, from Hyd, India! How could I give 100points bounty for you? – HydPhani Aug 04 '23 at 19:25
6

4.6.1-2 in VS2017 users may experience the unwanted replacement of their version of System.Net.Http by the one VS2017 or Msbuild 15 wants to use.

We deleted this version here:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Net.Http.dll

and here:

C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\lib\System.Net.Http.dll

Then the project builds with the version we have referenced via NuGet.

jaybro
  • 1,363
  • 1
  • 12
  • 23
  • What worked for me was temporarily removing System.Net.Http from "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2", so that when I added the reference in my project to System.Net.Http and selected the 4.0.0 version it actually referenced that one, but this answer actually helped me think of that so thank you :) – Mie ElMansy Aug 13 '20 at 14:00
4

I have same issue and only way how i am able to fix it is add bindingRedirect to app.confing how wrote @tripletdad99.

But if you have solution with more project is really suck update every project by hand (and also sometimes after update some nuget package you need to do it again). And it is reason why i wrote simple powershell script which if all app.configs.

 param(
    [string]$SourceDirectory,
    [string]$Package,
    [string]$OldVersion,
    [string]$NewVersion
)

Write-Host "Start fixing app.config in $sourceDirectory"
Write-Host "$Package set oldVersion to $OldVersion and newVersion $NewVersion"
Write-Host "Search app.config files.."
[array]$files = get-childitem $sourceDirectory -Include app.config App.config -Recurse | select -expand FullName
foreach ($file in $files)
{
    Write-Host $file
    $xml = [xml](Get-Content $file)
    $daNodes = $xml.configuration.runtime.assemblyBinding.dependentAssembly
    foreach($node in $daNodes)
    {
        if($node.assemblyIdentity.name -eq $package)
        {
            $updateNode = $node.bindingRedirect
            $updateNode.oldVersion = $OldVersion
            $updateNode.newVersion =$NewVersion
            Write-Host "Fix"
        }
    }
    $xml.Save($file)
}

Write-Host "Done"

Example how to use:

./scripts/FixAppConfig.ps1 -SourceDirectory "C:\project-folder" -Package "System.Net.Http" -OldVersion "0.0.0.0-4.3.2.0" -NewVersion "4.0.0.0"

Probably it is not perfect and also it will be better if somebody link it to pre-build task.

Jiri Sykora
  • 484
  • 4
  • 10
2

I had this, but, it was because I had added a NuGet package that had updated the binding redirects. Once I removed the package, the redirects were still there. I removed all of them, and then ran update-package -reinstall. This added the correct redirects.

SwampyFox
  • 1,105
  • 9
  • 13
2

Removing dependentAssembly for name="System.Net.Http" from web.config also worked for me. I commented this part from web.config and it worked for me. If all the above solutions didn't worked for you try commenting or removing as show below.

<!--<dependentAssembly>
        <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
        <bindingRedirect oldVersion="0.0.0.0-4.1.1.2" newVersion="4.0.0.0"/>
      </dependentAssembly>-->
Rajon Tanducar
  • 308
  • 4
  • 8
1

Before doing tricks and configuration complexities, try deleting the bin and obj folders, then compile. That fixed same problem

Alan1963
  • 159
  • 1
  • 5
0

Check .net framework version.
My original .net framework is older version.
After I installed .net framework 4.6, this issue is automatically solved.

Frank Myat Thu
  • 4,448
  • 9
  • 67
  • 113
0

For me, I had set my project to run on the latest version of .Net Framework (a change from .Net Framework 4.6.1 to 4.7.2).

Everything worked, no errors and published without issue, and it was only by chance that I came across the System.Net.Http error message, shown in a small, hard-to-notice, but quite important API request over the website I'm working on.

I rolled back to 4.6.1 and everything is fine again.

Stuart Aitken
  • 949
  • 1
  • 13
  • 30
0

The only way that cleanly solved this issue for me (.NET 4.6.1) was to not only add a Nuget reference to System.Net.Http V4.3.4 for the project that actually used System.Net.Http, but also to the startup project (a test project in my case).

(Which is strange, because the correct System.Net.Http.dll existed in the bin directory of the test project and the .config assemblyBingings looked OK, too.)

TvdH
  • 1,088
  • 14
  • 29
0

Was updating an old website using nuget (including .Net update and MVC update).

I deleted the System.Net.HTTP reference in VS2017 (it was to version 2.0.0.0) and re-added the reference, which then showed 4.2.0.0.

I then updated a ton of 'packages' using nuget and got the error message, then noticed something had reset the reference to 2.0.0.0, so I removed and re-added again and it works fine... bizarre.

Paul Zahra
  • 9,522
  • 8
  • 54
  • 76
0

For me, I added the nuget again and the problem was solved

TheMah
  • 378
  • 5
  • 19
0

I had this issue after upgrading the project from .NET Framework 4.6 to .NET Framework 4.8. In the config file I still had the line with the old version

<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1"/>

and the server didn't have .NET Framework 4.8 installed.

After correcting the line above, installing .NET Framework 4.8 on the server and rebooting it, now it works.

josibu
  • 594
  • 1
  • 6
  • 23
0

Make sure the publicKeyToken on this dll is defined and what you expect, for some versions of this dll it is sometimes null

Markus
  • 1,020
  • 14
  • 18