New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
System.Net.Http NuGet broken for .NET 4.7.2 #26131
Comments
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 #18280 and #20777. |
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. |
What you're describing sounds a lot like this known issue. |
Thanks @svick for finding the dupe. Closing - see workaround in the link issue. |
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.] So, can anyone help? Thanks Luis |
Did you check the known issue? If this is a new, please file separate issue. |
Had this exact issue today but the work around did not work for me, I had to move back to 471 |
@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 |
Yes, and I did try the work around, but I still had the error |
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: |
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.dllAfter 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...) |
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 |
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 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?). |
@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 😃.
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. |
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:
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. |
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:
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. |
@davidsh thank you for clearing up my confusion 😄 happy weekend. |
@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
My website and my additional dll project are both targeting
However, in my Website, reference is constantly downgraded, to If I don't use my workaround I'm getting following compilation error:
My assumption is that this happens because some of the nuget packages in Website define dependencies for |
@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 dotnet/sdk#2250? |
@ericstj No, this is fixed in VS 15.8 |
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 edit somehow this dotnet/core#1568 (comment) 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 |
@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: |
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:
So after fighting with the issue for most of today as well, I've fallen back to the bindingRedirects once more. |
@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. |
@joperezr VS 15.8 is released , 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 👍 |
@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 <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 |
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:
|
@joperezr thank you for the suggestion. Changed it manually now in the .csproj I still have these messages during build:
|
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 |
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 |
@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: |
@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. |
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 |
@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. |
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:
|
@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 |
@joperezr Can you comment on this? |
@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. |
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 referenceHttpClient
. 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.The text was updated successfully, but these errors were encountered: