Runtime: System.Net.Http NuGet broken for .NET 4.7.2

[dmarlow]

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.

[davidsh]

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 dotnet/runtime#18280 and dotnet/runtime#20777.

[dmarlow]

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.

[svick]

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

[karelz]

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

[luisabreu]

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.<ExecuteStepImpl>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

[karelz]

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

[aL3891]

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

[joperezr]

@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 <Reference Include="System.Net.Http" />
In case you do and still hit the issue, I would suggest you try out the workaround specified here

[aL3891]

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

[joperezr]

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]

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:

..\packagesSystem.Net.Http.4.3.3\lib\net46System.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

[joperezr]

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 <Reference Include="System.Net.Http" /> and that should fix your issue I believe.

[luisabreu]

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.

[thuannguy]

After upgrading my solution to .NET 4.7.2 in hope that I could finally get rid of System.Net.Http.dll hell, I got the same error:

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.

I used Visual Studio -> Add reference and chose the dll from Framework:

I checked my solution, all projects use

On all dev and test servers, I installed .NET 4.7.2 SDK. Fusion log gave me:

LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Program Files\ProductName\SubProductName\Tenantsnet472\runtime\web.config
LOG: Using host configuration file: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet.config
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config.
LOG: Redirect found in application configuration file: 4.2.0.0 redirected to 4.2.0.0.
LOG: ProcessorArchitecture is locked to MSIL.
LOG: Post-policy reference: System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL
LOG: GAC Lookup was unsuccessful.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/runtime/c22dfe60/788d17b5/System.Net.Http.DLL.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/runtime/c22dfe60/788d17b5/System.Net.Http/System.Net.Http.DLL.
LOG: Attempting download of new URL file:///C:/Program Files/ProductName/SubProductName/Tenants/net472/runtime/bin/System.Net.Http.DLL.
LOG: Attempting download of new URL file:///C:/Program Files/ProductName/SubProductName/Tenants/net472/runtime/bin/System.Net.Http/System.Net.Http.DLL.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/runtime/c22dfe60/788d17b5/System.Net.Http.EXE.
LOG: Attempting download of new URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/runtime/c22dfe60/788d17b5/System.Net.Http/System.Net.Http.EXE.
LOG: Attempting download of new URL file:///C:/Program Files/ProductName/SubProductName/Tenants/net472/runtime/bin/System.Net.Http.EXE.
LOG: Attempting download of new URL file:///C:/Program Files/ProductName/SubProductName/Tenants/net472/runtime/bin/System.Net.Http/System.Net.Http.EXE.
LOG: All probing URLs attempted and failed.

When I set "Copy local" setting of System.Net.Http.dll to true, I got another error:

Cannot load a reference assembly for execution.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.BadImageFormatException: Cannot load a reference assembly for execution.

Can you tell me what I should do now? I have run into dll load issues many times before, but this System.Net.Http.dll hell is the worst ever 😞

[karelz]

@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]

@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?

[davidsh]

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]

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 https://github.com/dotnet/corefx/issues/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?

[davidsh]

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]

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

[nenadvicentic]

@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:

  <ItemGroup>
      <Reference Include="System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
          <HintPath>C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.2\System.Net.Http.dll</HintPath>
          <SpecificVersion>true</SpecificVersion>
      </Reference>
  </ItemGroup>

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:

  <ItemGroup>
    <Reference Include="System.Net.Http" />
  </ItemGroup>

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

[davidsh]

@joperezr @ericstj Can you comment on this?

[ericstj]

@nenadvicentic this sounds like a problem with conflict resolution. The SDK targets should be dropping the package reference in preference of the framework reference. @dsplaisted does VS 15.7.6 have your fix for https://github.com/dotnet/sdk/pull/2250?

[dsplaisted]

@ericstj No, this is fixed in VS 15.8

[jphellemons]

I have read the whole thing and do not understand it. I have a 4.7.2 which 2 .net standard (2.x) projects in the same solution. I have migrated from packages.config to packagereference and I keep getting cannot find System.Runtime, Version=4.2.1.0 So I tried to add the nuget system.runtime which is 4.3.x (newer) but that did not change a thing. I did as told here https://github.com/Microsoft/dotnet/blob/master/releases/net472/KnownIssues/613745%20-%20Single-name%20references%20are%20removed%20by%20the%20SDK%20when%20targeting%204.7.2.md and added <ExcludeAssets>All</ExcludeAssets> that solved my httpclient issue, but did not fix the system.runtime so I tried to do it for that nuget package too. Added <ExcludeAssets>All</ExcludeAssets> there too, but did not change a thing. So I am stuck at the moment. Can someone who understands this better then me help me out plz?
I am running the latest stable 15.7.6 and do not have the diskspace to move to the preview 15.8.x yet. (surface pro 3 limited ssd space...)
Tried to remove the nuget because someone here said that the framework has a fine version build in and no nuget was needed but the error is still the same. Seems by the way that the 4.2.1. runtime is requested by the dll of the .net standard 2.0 lib?

edit somehow this https://github.com/dotnet/core/issues/1568#issuecomment-390271601 solved it. manually removed the obj and bin folder.... I thought that the clean build took care of it.

I also had to add a ref to net standard 2.0 even when I already had the 2.0.3 nuget referenced and the 4.7.x should implement 2.0 so I still have no clue why it's needed
Found it here: https://github.com/dotnet/standard/issues/542#issuecomment-339328208

[joperezr]

@jphellemons glad you found a workaround that fixed the issue. If you ever see the problem again, what really helps us diagnose and fix your issue are msbuild binlogs, so it would be great if you could push one of your build. In order to generate one, you can simply build your project from a developer command line like: msbuild yourProject.csproj /t:rebuild /bl which should generate a msbuild.binlog file.

[joelmdev]

I fought with this for most of yesterday before bumping down the bindingRedirect newVersion to 4.0.0.0 as recommended by @thuannguy and @davidsh. VS 15.8 was released today and given that @dsplaisted had stated that this issue should be fixed in said version I rolled back and went through the process again. While it changed the nature of the problem, it did not fix it. New error is:

Could not load file or assembly 'System.Net.Http' or one of its dependencies. Reference assemblies should not be loaded for execution. They can only be loaded in the Reflection-only loader context.

So after fighting with the issue for most of today as well, I've fallen back to the bindingRedirects once more.

[joperezr]

@joelmdev We would like to understand better the issue that you are hitting, so if you are able to provide a msbuild.binlog that would be appreciated. My above comment describes how to generate one.

[jphellemons]

@joperezr VS 15.8 is released :shipit: , so I upgraded before making this msbuild binlog and I had the fix/workaround yesterday in 15.7.6 so I do not know if this still can help you or someone else but here is it anyway. I appreciate all your time and effort and I hope this binlog can help 👍
msbuild.zip

[joperezr]

@jphellemons thanks for sharing. Your build seems to be green now so that's great! One thing to note from just skimming it, looks like your main project (CsaaSignalR) is using the two different forms of nuget package restore available (legacy packages.config, and PackageReference) or at least did it once. I would remove the following lines:

    <Reference Include="EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
      <HintPath>..\packages\EntityFramework.6.2.0\lib\net45\EntityFramework.dll</HintPath>
    </Reference>
    <Reference Include="EntityFramework.SqlServer, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL">
      <HintPath>..\packages\EntityFramework.6.2.0\lib\net45\EntityFramework.SqlServer.dll</HintPath>
    </Reference>

and replace them with these:

    <PackageReference Include="EntityFramework">
      <Version>6.2.0</Version>
    </PackageReference>

That will ensure that your package closure is correct, and that your project can be built on other computers, since now you rely on having the ..\packages\EntityFramework.6.2.0.... on disk.

[agrothe]

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]

@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.

[ghost]

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

[ghost]

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

[joperezr]

@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.

[dsplaisted]

@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.

[coachrob]

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

[joperezr]

@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.

[briangru]

FYI - I just spent half a day on this problem as well. Note this problem still isn't fixed with VS 2017. I needed to use two workarounds:
1) The one in the .NET Framework 4.7.2 known issues tab.
https://github.com/Microsoft/dotnet/blob/master/releases/net472/KnownIssues/613745%20-%20Single-name%20references%20are%20removed%20by%20the%20SDK%20when%20targeting%204.7.2.md

2) I had to add binding redirects (or at least fix up existing ones) to redirect 4.2.0.0 to 4.0.0.0.

[karelz]

@briangru we do not expect people targeting .NET 4.7.2 to run into any problems.
Can you please file a new issue with steps to reproduce your problem? If you can reproduce problems on 4.7.2, we are very interested in root causing them and addressing them. Thanks!
cc @safern @wtgodbe

[nicholashead]

In most cases, we don't advise people use the separate System.Net.Http NuGet package anymore. See dotnet/runtime#18280 and dotnet/runtime#20777.

@davidsh I recently upgraded my projects to 4.7.2 and ran into this - had to remove the System.Net.Http package and now I'm back up and running - I'm just curious - is there some official guide somewhere to navigate what "System"/"Microsoft" NuGet packages are now deprecated/shouldn't be used/causes problems? For example, I have the System.IO.Compression package installed, and it was last updated 11/15/2016 -- I assume this package shouldn't be used any longer?

[davidsh]

@davidsh I recently upgraded my projects to 4.7.2 and ran into this - had to remove the System.Net.Http package and now I'm back up and running - I'm just curious - is there some official guide somewhere to navigate what "System"/"Microsoft" NuGet packages are now deprecated/shouldn't be used/causes problems? For example, I have the System.IO.Compression package installed, and it was last updated 11/15/2016 -- I assume this package shouldn't be used any longer?

@joperezr Can you comment on this?

[joperezr]

@nicholashead we don't really have a good guide in order to show this info because it is not super trivial as a package might not be all up deprecated, simply just deprecated for one single TFM of all the ones supported in the package. For System.IO.Compression, If you are targetting .NET Framework 4.7.2 then you shouldn't be referencing the package at all as all the Apis live in System.IO.Compression.FileSystem.dll which already comes inbox as part of .NET Framework. I would suggest to try using https://apisof.net/ in order to get more info about where do Apis live for a specific TFM, and to check if they come inbox or if instead you need to add a nuget package reference.