40

I am confused with packaging of HttpClient. Earlier it was distributed as a part of Microsoft.Http.Net NuGet package while System.Net.Http was considered legacy. Looks like now it's the opposite: there is a fresh System.Net.Http package for all platforms and Microsoft.Net.Http has not been updated in a while and according to folks at Microsoft development team is going to be deprecated.

Questions then:

  • Can we replace dependencies on Microsoft.Net.Http NuGet package with (the newest) System.Net.Http?
  • Should legacy .NET 4.0 platform still use Microsoft.Net.Http? What about non-Windows platforms (iOS, Android)? The new System.Net.Http supports them, but I remember with Microsoft.Net.Http I had to install additionally Microsoft.Bcl.Build and Microsoft.Bcl in order to get cross-platform stuff to work. System.Net.Http doesn't depend on them. Can Bcl packages be skipped?
  • System.Net.Http lacks some Http extension methods, like SupportsPreAuthenticate, and an attempt to call these method results in runtime errors (missing method). How should we deal with this?
Maria Ines Parnisari
  • 16,584
  • 9
  • 85
  • 130
Vagif Abilov
  • 9,835
  • 8
  • 55
  • 100
  • 1
    Possible duplicate of [System.Net.Http vs Microsoft.Net.Http](http://stackoverflow.com/questions/31053243/system-net-http-vs-microsoft-net-http) – DonO Feb 01 '17 at 20:24
  • 1
    Just to give a possible reason for the change: Network stack features differ a little bit between Windows platform and other OSes. I had troubles using a .NET application written for Windows in Mono environment for example. The change might indicate that finally it will be possible to be really platform independent, this could be why they move things to the System namespace. Look for references to this Http package from .NET Core, that might answer your question. – flohack Feb 09 '17 at 10:00
  • Looking at the packages downloaded from Microsoft.Net.Http nuget the only implementations of HttpClient are for net40, portable-net40+sl4+win8+wp71+wpa81, sl4-windowsphone71. For remaining platforms there are no implementations so I guess the System-one is picked? – raV720 Jun 11 '18 at 08:00

1 Answers1

13

This has been for a long time and continues to be confusing. I have seen such messaging myself but as of right now, it appears System.Net.Http is the correct choice, at least for .NET on the Windows platform and has no external dependencies.

For .NET Core, I have used Microsoft.Net.Http although it does require Microsoft.BCL. Unless you are experiencing problems, I suggest leaving legacy systems as-is, especially since these namespaces seem to be moving targets.

If that isn't confusing enough for you, the HttpClient Sample linked from System.Net.Http uses Windows.Web.Http! That implementation is for Windows Store apps.

Perhaps next year this will all change again.

Chris Idzerda
  • 328
  • 4
  • 11
  • 8
    OMG .. can't we get a canonical answer from someone with authority ? :( – Hendy Irawan Aug 24 '17 at 17:56
  • I'm using .NET6 . Could you please elaborately tell me the exactly what steps you took to make Microsoft.Net.Http package to get installed in a .NET6 -based solution? In Visual STudio 2022, I get the warning "Package 'Microsoft.Net.Http 2.2.29' was restored using '.NETFramework,Version=v4.6.1, .NETFramework,Version=v4.6.2, .NETFramework,Version=v4.7, .NETFramework,Version=v4.7.1, .NETFramework,Version=v4.7.2, .NETFramework,Version=v4.8, .NETFramework,Version=v4.8.1' instead of the project target framework 'net6.0'. This package may not be fully compatible with your project." – crazyTech Apr 20 '23 at 22:20