# System.Net.Http NuGet broken for .NET 4.7.2 #29622

Closed
opened this Issue May 9, 2018 · 38 comments

Projects
None yet

### dmarlow commented May 9, 2018

 Hopefully this is the right place. If not, please let me know and I'll create this elsewhere. I created a net .NET 4.7.2 class library project and tried to reference the System.Net.Http 4.3.3 NuGet package and the entire System.Net.Http namespace is missing. I can't reference HttpClient. I'm using PackageReference though I think packages.config is also broken. As soon as I change the library to .NET 4.7.1, it all works as expected.

Member

### davidsh commented May 10, 2018

 I created a net .NET 4.7.2 class library project and tried to reference the System.Net.Http 4.3.3 NuGet package Why did you want to reference "System.Net.Http 4.3.3 NuGet package? If you're building a .NET Framework 4.7.2 class library, then you could just add a normal Framework reference to System.Net.Http. In most cases, we don't advise people use the separate System.Net.Http NuGet package anymore. See #11100 and #17522.
Author

### dmarlow commented May 10, 2018

 It's been a while (over a year) and I'm wondering why I referenced it myself. We actually reference NETStandard.Library 1.6 in our .NET 4.6.2 projects and it's been working fine. Maybe it was related to wanting to reference ValueTuple or some other dependency that targeted some NETStandard reference. Is there guidance somewhere that talks about this? I feel like this is all tribal knowledge filled with trial/error for most people.
Contributor

### svick commented May 11, 2018

 What you're describing sounds a lot like this known issue.
Member

### karelz commented May 12, 2018

 Thanks @svick for finding the dupe. Closing - see workaround in the link issue. If it is different issue, we can reopen and investigate.

### luisabreu commented Jun 9, 2018

 Hello guys. Just to confirm that package.config is broken. In my case, I have a solution with several assemblies compiled against 4.7.1 (plain old full net assemblies which use Nuget packages through the package.config). One of these assemblies uses MS Graph in order to query an existing Azure AD (I'm only mentioning this here because adding the MS Graph nuget ref will automatically bring the System.Net.Http + other nuget packages). These helper assemblies are consumed by an ASP.NET MVC 5 web app. All the packages have been updated to the latest stable releases and everything is working out well if the web site is compiled against version 4.7.1. However, if I update the .NET version used by the web site, all hell breaks loose! Whenever I change the .net version to 4.7.2, the web app does compile, but I end up getting a runtime error complaining about a missing System.Net.Http reference (in this case, it's generated by insights, but removing it ends up generating a similar error by the ms graph library): [FileNotFoundException: 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.] Microsoft.AspNet.TelemetryCorrelation.ActivityExtensions.Extract(Activity activity, NameValueCollection requestHeaders) +0 Microsoft.AspNet.TelemetryCorrelation.ActivityHelper.CreateRootActivity(HttpContext context) +234 Microsoft.AspNet.TelemetryCorrelation.TelemetryCorrelationHttpModule.Application_BeginRequest(Object sender, EventArgs e) +130 System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +223 System.Web.<>c__DisplayClass285_0.b__0() +37 System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step) +155 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +91 So, can anyone help? Thanks Luis
Member

### karelz commented Jun 11, 2018

 Did you check the known issue? If this is a new, please file separate issue. cc @joperezr

### aL3891 commented Jun 12, 2018

 Had this exact issue today but the work around did not work for me, I had to move back to 471
Member

### joperezr commented Jun 12, 2018

 @luisabreu can you confirm you have a platform reference to System.Net.Http as well once you retarget to 4.7.2? By that I mean that you have a line in your project like  In case you do and still hit the issue, I would suggest you try out the workaround specified here

### aL3891 commented Jun 12, 2018

 Yes, and I did try the work around, but I still had the error
Member

### joperezr commented Jun 12, 2018

 If you could provide a msbuild.binlog I would be happy to look at it and figure out what is going on. To get one, simply build from a developer command prompt like: msbuild yourProject.csproj /t:rebuild /bl /v:m

### luisabreu commented Jun 12, 2018 • edited

 Hello @joperezr. In my case, the csproj has the refs to the System.Net.Http assembly with a hintpath that points to the packages folder: ..\packages\System.Net.Http.4.3.3\lib\net46\System.Net.Http.dll After migrating to .NET 4.7.2, the reference is still there. I'm also attaching the binlog file as you've requested (in this case, the solution has several projects and I've migrated the web app to the 4.7.2; the other projects are still using 4.7.1, but that shouldn't be a problem...) msbuild.zip
Member

### joperezr commented Jun 12, 2018

 Hey @luisabreu so as I suspected you don't really have a reference to the platform version of System.Net.Http, and instead are referencing one comming from a nuget package. To fix your issue, you should be able to just add to your project a simple  and that should fix your issue I believe.

### luisabreu commented Jun 17, 2018

 Hello again. Sorry for the late reply, but I was sick and was really in no condition to follow up on this thread. Regarding your suggestion, I've tried doing that and it fixes the problem. I've taken a second look at the code and I've noticed that the web site didn't have a dependency on MS' Graph nuget package and that's probably why it wasn't working...now that I can see why it's not working, I'm unsure on why it was working with .NET 4.7.1... Anyways, what matters is that the problem is solved. Thanks again.

Closed

Member

### karelz commented Jul 19, 2018

 @thuannguy same answer as before - please check existing solutions (looks like you already did), then file a new issue with clear steps (ideally minimal isolated repro - in your case, is upgrade necessary? Will it repro with HelloWorld app?). cc @AlexGhiondea as @joperezr is OOF.

### thuannguy commented Jul 19, 2018

 @karelz yep, I checked all mentioned solutions here. Most other solutions I found on the internet are for previous .NET version that use the Nuget package. Meanwhile, it was stated that using Framework reference from .NET 4.7.2 is the right way from now on so I'm trying to stick with that. I will try with a minimal isolated repro this weekend if I still have time for this 😃. By the way, when I used "gacutil /s" to list dlls in GAC, I found these: System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL System.Net.Http.Rtc, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL System.Net.Http.WebRequest, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL And using Explorer showed me: The Explorer version looks right, but I'm confused by the version 4.0.0.0 from GAC. Could you please shed some light on this?
Member

### davidsh commented Jul 19, 2018

 The Explorer version looks right, but I'm confused by the version 4.0.0.0 from GAC. Could you please shed some light on this? The "4.0.0.0" is the Assembly version. This is not the same thing as the "File" version you see in the properties dialog. The Assembly version for almost all .NET Framework dll's is "4.0.0.0". So, that is nothing to worry about.

### thuannguy commented Jul 21, 2018

 I managed to create a sample here: https://github.com/thuannguy/ReproduceIssues/tree/master/DemoLoadSystemNetHttp Either there is something unusual or I was confused by so many different versions and issues wrt System.Net.Http 😢 because: When I put in a binding redirect to 4.2.0.0, I got that issue. When I removed the redirect binding, it worked. When I changed the redirect binding to 4.0.0.0 (you can see that in web.config of the sample), it worked. Someone mentioned about the same "backward" redirect here #22781 but because I'm using .NET 4.7.2, I thought I should redirect to 4.2.0.0 instead. Can you tell me what the correct way to do now? Or do I need to open a new issue?
Member

### davidsh commented Jul 21, 2018 • edited

 Since you're targeting .NET 4.7.2 and I assume using the latest Visual Studio 2017 Update 15.7.x, then either of these two are fine: When I removed the redirect binding, it worked. When I changed the redirect binding to 4.0.0.0 (you can see that in web.config of the sample), it worked. When I put in a binding redirect to 4.2.0.0, I got that issue. You shouldn't try to force redirect to 4.2.0.0. In general, using the latest .NET and Visual Studio tools means you shouldn't have to worry about the binding redirects. It should just 'work' without intervention when you build your app.

### thuannguy commented Jul 22, 2018

 @davidsh thank you for clearing up my confusion 😄 happy weekend.

Closed

### nenadvicentic commented Aug 7, 2018

 @davidsh I have issue with lastest Visual Studio (15.7.6) and .NET Framework 4.7.2. I had to put following in my ASP.NET Core (v2.1.2) MVC website *.csproj file, to force project to start correctly:  C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.Net.Http.dll true  My website and my additional dll project are both targeting net472, not using packages.config and both have reference to Framework System.Net.Http dll, which should be version 4.2.0.0:   However, in my Website, reference is constantly downgraded, to 4.1.1.0 and path set to: C:\Program Files\dotnet\sdk\NuGetFallbackFolder\system.net.http\4.3.0\ref\net46\System.Net.Http.dll. If I don't use my workaround I'm getting following compilation error: Error CS1705 Assembly 'MyDLL' with identity 'MyDLL, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' uses 'System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' which has a higher version than referenced assembly 'System.Net.Http' with identity 'System.Net.Http, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' MyWebsite My assumption is that this happens because some of the nuget packages in Website define dependencies for >= .NET 4.6 and has nothing specified for .NET 4.7

### agrothe commented Aug 16, 2018

 Had the same issue with the System.Net.Http namespace missing when upgrading from 4.7.1 to 4.7.2. I didn't have a reference to a nuget package though. Tried a bunch of other workarounds via links in this thread and other searching. Resolved it based on a previous reply in this thread: Closed Solution Delete all bin/obj folders in my solution projects (just doing this on webproject didn't work, had to be all projects with a reference to the namespace) Notepad++ "find in files" for System.Net.Http and removed all references Commented out any code referencing namespace Project then built/ran fine Re-added from assemblies Back in business

### jphellemons commented Aug 17, 2018 • edited by karelz

 @joperezr thank you for the suggestion. Changed it manually now in the .csproj I still think that this looks odd: I have messed too much with the csproj and moving frameworks and moving packagemanagement and nugets and redirect bindings in web.config etc... It would be better to start over fresh but I heard on the .net community standup that they are working on new templates and I am looking forward to it. Because I am lost with all the js/css packagemanagers. grunt, gulp, npm, nodejs, minify, uglyfy, compress, bundling, pakman, webpack, webcompiler etc. I still have these messages during build: 1> No way to resolve conflict between "System.Net.Http, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" and "System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". Choosing "System.Net.Http, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" arbitrarily. 1> Consider app.config remapping of assembly "System.Data.Common, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "4.1.2.0" [C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Data.Common.dll] to Version "4.2.0.0" [C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.Data.Common.dll] to solve conflict and get rid of warning. 1> Consider app.config remapping of assembly "System.Diagnostics.StackTrace, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "4.0.4.0" [C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Diagnostics.StackTrace.dll] to Version "4.1.0.0" [C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.Diagnostics.StackTrace.dll] to solve conflict and get rid of warning. 1> Consider app.config remapping of assembly "System.Diagnostics.Tracing, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "4.1.2.0" [C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\System.Diagnostics.Tracing.dll] to Version "4.2.0.0" [C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.Diagnostics.Tracing.dll] to solve conflict and get rid of warning. 1> Consider app.config remapping of assembly "System.Globalization.Extensions, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "4.0.3.0" [C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Globalization.Extensions.dll] to Version "4.1.0.0" [C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.Globalization.Extensions.dll] to solve conflict and get rid of warning. 1> Consider app.config remapping of assembly "System.IO.Compression, Culture=neutral, PublicKeyToken=b77a5c561934e089" from Version "4.0.0.0" [C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\System.IO.Compression.dll] to Version "4.2.0.0" [C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.IO.Compression.dll] to solve conflict and get rid of warning. 1> Consider app.config remapping of assembly "System.Net.Http, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "4.1.1.0" [] to Version "4.2.0.0" [C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.Net.Http.dll] to solve conflict and get rid of warning. 1> Consider app.config remapping of assembly "System.Net.Sockets, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "4.1.2.0" [C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Net.Sockets.dll] to Version "4.2.0.0" [C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.Net.Sockets.dll] to solve conflict and get rid of warning. 1> Consider app.config remapping of assembly "System.Runtime.Serialization.Primitives, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "4.1.3.0" [C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Runtime.Serialization.Primitives.dll] to Version "4.2.0.0" [C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.Runtime.Serialization.Primitives.dll] to solve conflict and get rid of warning. 1> Consider app.config remapping of assembly "System.Security.Cryptography.Algorithms, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "4.2.2.0" [C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Security.Cryptography.Algorithms.dll] to Version "4.3.0.0" [C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.Security.Cryptography.Algorithms.dll] to solve conflict and get rid of warning. 1> Consider app.config remapping of assembly "System.Security.SecureString, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "4.0.2.0" [C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Security.SecureString.dll] to Version "4.1.0.0" [C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.Security.SecureString.dll] to solve conflict and get rid of warning. 1> Consider app.config remapping of assembly "System.Threading.Overlapped, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "4.0.3.0" [C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Threading.Overlapped.dll] to Version "4.1.0.0" [C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.Threading.Overlapped.dll] to solve conflict and get rid of warning. 1> Consider app.config remapping of assembly "System.Xml.XPath.XDocument, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" from Version "4.0.3.0" [C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Xml.XPath.XDocument.dll] to Version "4.1.0.0" [C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.Xml.XPath.XDocument.dll] to solve conflict and get rid of warning. 

### UM001 commented Aug 25, 2018 • edited

 I have this same shit as well. Is there somebody of Microsoft willing to have a look at my dev box themselves and resolve it? It is a wast of precious time. I have version 4.6.2 framework and VS2017 15.8 version and system.http.net I have everything in version control and was able to undo all my changes. Wasted 5 hours of work. It starts again with a warning like which you make update packages... Severity Code Description Project File Line Suppression State Warning Some NuGet packages were installed using a target framework different from the current target framework and may need to be reinstalled. Visit http://docs.nuget.org/docs/workflows/reinstalling-packages for more information. Packages affected: System.Diagnostics.Tracing, System.IO, System.Linq.Dynamic.Core, System.Reflection, System.Runtime, System.Runtime.Extensions, System.Runtime.InteropServices, System.Security.Cryptography.Algorithms

### UM001 commented Aug 25, 2018

 I need this because of CRM 9.0 version upgrade not allowing TLS1.x An error occurred while making the HTTP request to https://xx.crm4.dynamics.com//xrmservices/2011/organization.svc/web?SdkClientVersion=8.2. This could be due to the fact that the server certificate is not configured properly with HTTP.SYS in the HTTPS case. This could also be caused by a mismatch of the security binding between the client and the server. <--- The underlying connection was closed: An unexpected error occurred on a send. <--- Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. <--- An existing connection was forcibly closed by the remote host
Member

### joperezr commented Aug 27, 2018

 @UM001 if you can provide a msbuild binlog I can take a look to see what is going on. In order to produce one, run from a developer command prompt the following: msbuild yourSolution.sln /t:rebuild /bl which should produce a msbuild.binlog file.
Member

### dsplaisted commented Aug 28, 2018

 @UM001 Were you trying to retarget your app to .NET 4.7.1, as recommended in this documentation? If so, you should probably be able to just uninstall the System.Net.Http NuGet package.

Closed

Closed

Closed

### coachrob commented Nov 19, 2018

 This is kind of an old thread, but I'm having similar issues. I've got a binlog if you'd be available to have a look. @joperezr

Open

Open

Closed

Open

Closed

Open

Open

Open

Closed

Open

Open

Open

Closed

Closed

Closed

Open

Closed

Open

Member

### joperezr commented Nov 26, 2018

 @coachrob yeah I'm happy to take a look. In order to prevent this issue to keep growing, could you log a new issue and attach your binlog there? If it turns out to be the same problem then we can dupe it back to this one.

Closed