System.Net.Http contre Microsoft.Net.Http


Réponses:


64

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

1
Sachez qu'ils n'ont pas exactement le même comportement. La version .NET complète (4.0.0.0) n'effectue pas de compression automatique, contrairement à la version .NET Core (4.1.0). Donc, si vous utilisez la version complète de .NET, vous devez configurer manuellement le gestionnaire pour utiliser la compression gzip / deflate. Description: github.com/dotnet/docs/issues/1054
Jeppe Andersen

28
Cette réponse résume le désordre que cela est devenu avec .NET Core, .NET Standard et .NET Framework.
Vincent

1
@vincent Ce n'est pas plus une douleur dans le cul que dans le dos quand les gens ont utilisé le mono etc.
lance

4
Je ne vois pas le "package hérité, System.Net.Httpest maintenant inclus dans le Microsoft.Net.Httppackage". langue à laquelle vous faites référence dans la description du package. En fait, le System.Net.Httppackage semble être le plus récemment mis à jour (de plusieurs années)
Dan Esparza

2
@DanEsparza si vous regardez le lien que j'ai posté, vous verrez le message. J'ai également mentionné que seuls les anciens packages (ceux de la version 2.0) sont obsolètes. Les derniers packages 4.xx sont en effet les plus récents et vous devriez les utiliser.
Henk Mollema

19

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


8

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.


8
Il semble que MS a changé d'avis alors que cet article fait allusion à ... stackoverflow.com/questions/39016373/… microsoft.net.http n'a pas été mis à jour depuis 2015 alors que system.net.http n'est que quelques mois de sagou (nuget) .
smoore4
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.