Depends on the version. The old System.Net.Http packages (the 2.0 ones) are legacy packages which are deprecated in favor of Microsoft.Http.Net according to the description:
Legacy package, System.Net.Http is now included in the
'Microsoft.Net.Http' package.
They exist to provide the HttpClient in previous .NET versions and Portable Class libraries. You should use Microsoft.Net.Http in that case.
Since you're using .NET Core, you should use the latest System.Net.Http package (eg. 4.3.3).
Updated for csproj
As of .NET Standard 2.0, the System.Net.HttpClient package is already included and available when you target netstandard2.0. If, for some reason, you still want to reference it for both full .NET and .NET Core, you can add this to your csproj file:
If your project.json targets both full .NET and .NET Core, you have to add the System.Net.Http assembly to the frameworkAssemblies element. For example:
"frameworks": {
"net451": {
"frameworkAssemblies": {
"System.Net.Http": "4.0.0.0" // HttpClient for full .NET
}
},
"netstandard1.3": {
"dependencies": {
"System.Net.Http": "4.1.0", // HttpClient for .NET Core
}
}
}
For that, if you are only targeted .NET Framework or .NET Core, System.Net.Http is good to go. Otherwise, Microsoft.Net.Http would be better choice as it could be the next generation.
For anyone interested in more background to this, Immo Landwerth (Program manager on .NET at Microsoft) tweeted about this:
"HttpClient started out as a NuGet package (out-of-band) and was added to the .NET Framework in 4.5 as well (in-box).
With .NET Core/.NET Standard we originally tried to model the .NET platform as a set of packages where being in-box vs. out-of-band no longer mattered. However, this was messier and more complicated than we anticipated.
As a result, we largely abandoned the idea of modeling the .NET platform as a NuGet graph with Core/Standard 2.0.
The general answer is:
With .NET Core 2.0 and .NET Standard 2.0 you shouldn't need to reference the SystemNetHttpClient NuGet package at all. It might get pulled from 1.x dependencies though.
Same goes for .NET Framework: if you target 4.5 and up, you should generally use the in-box version instead of the NuGet package. Again, you might end up pulling it in for .NET Standard 1.x and PCL dependencies, but code written directly against .NET Framework shouldn't use it.
So why does the package still exist/why do we still update it? Simply because we want to make existing code work that took a dependency on it. However, as you discovered that isn't smooth sailing on .NET Framework.
The intended model for the legacy package is: if you consume the package from .NET Framework 4.5+, .NET Core 2+, .NET Standard 2+ the package only forwards to the platform provided implementation as opposed to bring it's own version.
That's not what actually happens in all cases though: the HTTP Client package will (partially) replace in-box components on .NET Framework which happen to work for some customers and fails for others. Thus, we cannot easily fix the issue now.
On top of that we have the usual binding issues with the .NET Framework so this only really works well if you add binding redirects. Yay!
So, as a library author my recommendation is to avoid taking a dependency on this package and prefer the in-box versions in .NET Framework 4.5, .NET Core 2.0 and .NET Standard 2.0."
