问题
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.HttpNuGet 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 newSystem.Net.Httpsupports them, but I remember withMicrosoft.Net.HttpI had to install additionallyMicrosoft.Bcl.BuildandMicrosoft.Bclin order to get cross-platform stuff to work.System.Net.Httpdoesn't depend on them. Can Bcl packages be skipped? System.Net.Httplacks some Http extension methods, likeSupportsPreAuthenticate, and an attempt to call these method results in runtime errors (missing method). How should we deal with this?
回答1:
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.
来源：https://stackoverflow.com/questions/39016373/the-current-status-of-system-net-http-vs-microsoft-net-http