System.Net.Http vs Microsoft.Net.Http

Używam ASP.NET Core. Chcę użyć, HttpClientale zauważyłem, że oferowane są dwa pakiety NuGet. Którego używam?

• System.Net.Http
• Microsoft.Net.Http

Zależy od wersji. Stare System.Net.Httppakiety (te 2.0 ) są starszymi pakietami, które są przestarzałe na rzecz Microsoft.Http.Netzgodnie z opisem:

Starszy pakiet System.Net.Http jest teraz zawarty w pakiecie „Microsoft.Net.Http”.

Istnieją, aby zapewnić HttpClientw poprzednich wersjach .NET i przenośnych bibliotek klas. W Microsoft.Net.Httptakim przypadku powinieneś użyć .

Ponieważ używasz .NET Core, powinieneś użyć najnowszego System.Net.Httppakietu (np. 4.3.3).

Zaktualizowano dla csproj

Począwszy od .NET Standard 2.0, System.Net.HttpClientpakiet jest już uwzględniony i dostępny, gdy jest przeznaczony netstandard2.0. Jeśli z jakiegoś powodu nadal chcesz odwoływać się do niego zarówno dla pełnego .NET, jak i .NET Core, możesz dodać to do swojego pliku csproj:

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

Jeśli używasz project.json

Jeśli projekt.json jest przeznaczony dla pełnego .NET i .NET Core, musisz dodać System.Net.Httpzestaw do frameworkAssemblieselementu. Na przykład:

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

Dla każdego, kto chciałby uzyskać więcej informacji na ten temat, Immo Landwerth (menedżer programu .NET w firmie Microsoft) napisał na Twitterze :

„HttpClient zaczynał jako pakiet NuGet (poza pasmem) i został również dodany do .NET Framework w wersji 4.5 (w pudełku).

W przypadku .NET Core / .NET Standard początkowo próbowaliśmy modelować platformę .NET jako zestaw pakietów, w których bycie w pakiecie i poza pasmem nie ma już znaczenia. Było to jednak bardziej chaotyczne i bardziej skomplikowane, niż się spodziewaliśmy.

W rezultacie w dużej mierze porzuciliśmy pomysł modelowania platformy .NET jako wykresu NuGet z Core / Standard 2.0.

Ogólna odpowiedź brzmi:

W przypadku .NET Core 2.0 i .NET Standard 2.0 nie trzeba w ogóle odwoływać się do pakietu NuGet SystemNetHttpClient. Może jednak zostać pobrany z zależności 1.x.

To samo dotyczy .NET Framework: w przypadku wersji docelowej 4,5 i nowszej należy zwykle używać wersji w pudełku zamiast pakietu NuGet. Ponownie, możesz skończyć wciągnąć go w zależności od .NET Standard 1.xi PCL, ale kod napisany bezpośrednio na .NET Framework nie powinien go używać.

Dlaczego więc pakiet nadal istnieje / dlaczego nadal go aktualizujemy? Po prostu dlatego, że chcemy, aby istniejący kod działał zależnie od niego. Jednak, jak odkryłeś, nie jest to płynne działanie na .NET Framework.

Planowany model dla starszego pakietu to: jeśli korzystasz z pakietu z .NET Framework 4.5+, .NET Core 2+, .NET Standard 2+, pakiet przekazuje tylko do implementacji dostarczonej przez platformę, zamiast przynosić własną wersję.

Jednak tak się nie dzieje we wszystkich przypadkach: pakiet klienta HTTP (częściowo) zastąpi zawarte w pudełku komponenty w .NET Framework, które zdarzają się działać dla niektórych klientów, a zawodzą dla innych. Dlatego nie możemy teraz łatwo rozwiązać problemu.

Ponadto mamy typowe problemy z wiązaniem w .NET Framework, więc działa to naprawdę dobrze tylko wtedy, gdy dodasz przekierowania powiązań. Yay!

Dlatego jako autor biblioteki zalecam unikanie zależności od tego pakietu i preferowanie wersji dołączonych do oprogramowania .NET Framework 4.5, .NET Core 2.0 i .NET Standard 2.0. ”

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

Microsoft.Net.Httpwymaga dodatkowych Microsoft.Bclzależności.

W tym celu, jeśli jesteś celem tylko .NET Framework lub .NET Core, System.Net.Httpdobrze jest iść. W przeciwnym razie Microsoft.Net.Httpbyłby lepszym wyborem, ponieważ mogłoby to być następne pokolenie.