System.Net.Http contre Microsoft.Net.Http

J'utilise ASP.NET Core. Je veux utiliser HttpClientmais j'ai remarqué que deux packages NuGet sont proposés. Lequel dois-je utiliser?

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

Dépend de la version. Les anciens System.Net.Httppackages (les 2.0 ) sont des packages hérités qui sont obsolètes au profit de Microsoft.Http.Netselon la description:

Le package hérité, System.Net.Http est maintenant inclus dans le package «Microsoft.Net.Http».

Ils existent pour fournir les HttpClientversions précédentes de .NET et les bibliothèques de classes portables. Vous devriez utiliser Microsoft.Net.Httpdans ce cas.

Puisque vous utilisez .NET Core, vous devez utiliser le dernier System.Net.Httppackage (par exemple 4.3.3).

Mis à jour pour csproj

À partir de .NET Standard 2.0, le System.Net.HttpClientpackage est déjà inclus et disponible lorsque vous ciblez netstandard2.0. Si, pour une raison quelconque, vous souhaitez toujours le référencer pour .NET complet et .NET Core, vous pouvez l'ajouter à votre fichier 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>

Si vous utilisez project.json

Si votre project.json cible à la fois .NET et .NET Core complets, vous devez ajouter l' System.Net.Httpassembly à l' frameworkAssembliesélément. Par exemple:

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

Pour toute personne intéressée par plus d'informations à ce sujet, Immo Landwerth (responsable de programme sur .NET chez Microsoft) a tweeté à ce sujet:

«HttpClient a commencé comme un package NuGet (hors bande) et a également été ajouté au .NET Framework dans 4.5 (en boîte).

Avec .NET Core / .NET Standard, nous avons initialement essayé de modéliser la plate-forme .NET comme un ensemble de packages où le fait d'être en boîte ou hors bande n'avait plus d'importance. Cependant, c'était plus compliqué et plus compliqué que prévu.

En conséquence, nous avons largement abandonné l'idée de modéliser la plate-forme .NET sous forme de graphe NuGet avec Core / Standard 2.0.

La réponse générale est:

Avec .NET Core 2.0 et .NET Standard 2.0, vous ne devriez pas du tout avoir besoin de référencer le package NuGet SystemNetHttpClient. Il pourrait cependant être extrait des dépendances 1.x.

Il en va de même pour .NET Framework: si vous ciblez 4.5 et versions ultérieures, vous devez généralement utiliser la version en boîte au lieu du package NuGet. Encore une fois, vous pourriez finir par l'extraire pour les dépendances .NET Standard 1.x et PCL, mais le code écrit directement sur .NET Framework ne devrait pas l'utiliser.

Alors pourquoi le paquet existe-t-il toujours / pourquoi le mettons-nous toujours à jour? Tout simplement parce que nous voulons faire fonctionner un code existant qui en dépendait. Cependant, comme vous l'avez découvert, la navigation n'est pas fluide sur .NET Framework.

Le modèle prévu pour le package hérité est le suivant: si vous utilisez le package à partir de .NET Framework 4.5+, .NET Core 2+, .NET Standard 2+, le package est uniquement transmis à l'implémentation fournie par la plateforme au lieu d'apporter sa propre version.

Ce n'est cependant pas ce qui se passe dans tous les cas: le package du client HTTP remplacera (partiellement) les composants intégrés sur .NET Framework qui fonctionnent pour certains clients et échouent pour d'autres. Ainsi, nous ne pouvons pas facilement résoudre le problème maintenant.

En plus de cela, nous avons les problèmes de liaison habituels avec le .NET Framework, donc cela ne fonctionne vraiment bien que si vous ajoutez des redirections de liaison. Yay!

Donc, en tant qu'auteur de bibliothèque, ma recommandation est d'éviter de prendre une dépendance sur ce package et de préférer les versions en boîte dans .NET Framework 4.5, .NET Core 2.0 et .NET Standard 2.0. "

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

Microsoft.Net.Httpnécessite des Microsoft.Bcldépendances supplémentaires .

Pour cela, si vous êtes uniquement ciblé .NET Framework ou .NET Core, System.Net.Httpc'est bon. Sinon, ce Microsoft.Net.Httpserait un meilleur choix car il pourrait s'agir de la prochaine génération.