System.Net.Http vs Microsoft.Net.Http

Question

I am using ASP.NET Core. I want to use HttpClient but I noticed that there are two NuGet packages being offered. Which one do I use?

It looks like `System.Net.Http` depends on `Microsoft.Net.Http`. But then again, it depends on what you are trying to do with your application. — John Odom, Jun 25 '15 at 14:53

score 70 · Accepted Answer · edited Sep 25 '20 at 07:02

70

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:

<ItemGroup Condition=" '$(TargetFramework)' == 'net461' ">
    <!-- // HttpClient for full .NET -->
    <Reference Include="System.Net.Http" />
</ItemGroup>
<ItemGroup Condition=" '$(TargetFramework)' == 'netstandard2.0' ">
    <!-- // HttpClient for .NET Core -->
    <PackageReference Include="System.Net.Http" Version="4.3.3" />
</ItemGroup>

If you're using project.json

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
    }
  }
}

edited Sep 25 '20 at 07:02

Pang

9,564
146
81
122

answered Jun 25 '15 at 15:04

Henk Mollema

44,194
12
93
104

1

Be aware that they do not have the exact same behaviour. The full .NET version (4.0.0.0) does not do automatic compression, whereas the .NET Core version (4.1.0) does. So if you use the full .NET version you must manually configure the handler to use gzip/deflate compression. Description: https://github.com/dotnet/docs/issues/1054 – Jeppe Andersen Nov 14 '16 at 09:38
35

This answer sums up what a mess this has become with .NET Core, .NET Standard and .NET Framework. – Vincent Mar 13 '17 at 17:18
1

@vincent It's no more of a pain in the ass than back when people used mono etc. Multi platform always has some pain points. – rollsch Dec 13 '17 at 05:32
4

I don't see the "Legacy package, `System.Net.Http` is now included in the `Microsoft.Net.Http` package." language you're referring to in the package description. In fact, the `System.Net.Http` package appears to be most recently updated (by several years) – Dan Esparza Jan 22 '18 at 13:48
2

@DanEsparza if you look at [the link I posted](https://www.nuget.org/packages/System.Net.Http/2.0.20710) you will see the message. I also mentioned that only the *old* packages (the 2.0 ones) are deprecated. The latest 4.x.x packages are indeed the newest and you should use them. – Henk Mollema Jan 22 '18 at 14:29

score 27 · Answer 2 · answered Sep 14 '18 at 14:30

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

https://twitter.com/terrajobst/status/997262020108926976

score 9 · Answer 3 · answered May 05 '16 at 12:48

9

Microsoft.Net.Http requires additional Microsoft.Bcl dependencies.

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.

answered May 05 '16 at 12:48

Youngjae

24,352
18
113
198

11

Seems that MS has changed their minds as this post alludes to...https://stackoverflow.com/questions/39016373/the-current-status-of-system-net-http-vs-microsoft-net-http microsoft.net.http has not been updated since 2015 while system.net.http is just a few month sago (nuget). – smoore4 Oct 30 '17 at 14:05

score 1 · Answer 4 · answered Mar 13 '23 at 18:39

March 2023 - I believe the answer to this has changed, so read the NuGet information carefully, and apply the one you need based on the dependencies of your particular application.

Also, don't just base your choice on which one was the most recently published!

System.Net.Http

Microsoft.Net.Http

System.Net.Http vs Microsoft.Net.Http

4 Answers4

Linked