System.Net.Http contro Microsoft.Net.Http


Risposte:


64

Dipende dalla versione. I vecchi System.Net.Httppacchetti ( quelli 2.0 ) sono pacchetti legacy che sono deprecati a favore di Microsoft.Http.Netsecondo la descrizione:

Pacchetto legacy, System.Net.Http è ora incluso nel pacchetto "Microsoft.Net.Http".

Esistono per fornire le HttpClientversioni precedenti di .NET e le librerie di classi portatili. Dovresti usare Microsoft.Net.Httpin quel caso.

Dato che stai usando .NET Core, dovresti usare il System.Net.Httppacchetto più recente (es. 4.3.3).

Aggiornato per csproj

A partire da .NET Standard 2.0, il System.Net.HttpClientpacchetto è già incluso e disponibile quando scegli come target netstandard2.0. Se, per qualche motivo, desideri comunque farvi riferimento sia per .NET completo che per .NET Core, puoi aggiungerlo al tuo file 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>

Se stai usando project.json

Se il tuo project.json è destinato sia a .NET completo che a .NET Core, devi aggiungere l' System.Net.Httpassembly frameworkAssembliesall'elemento. Per esempio:

"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
Sii consapevole del fatto che non hanno lo stesso identico comportamento. La versione .NET completa (4.0.0.0) non esegue la compressione automatica, mentre la versione .NET Core (4.1.0) lo fa. Quindi, se si utilizza la versione .NET completa, è necessario configurare manualmente il gestore per utilizzare la compressione gzip / deflate. Descrizione: github.com/dotnet/docs/issues/1054
Jeppe Andersen

28
Questa risposta riassume che pasticcio è diventato con .NET Core, .NET Standard e .NET Framework.
Vincent

1
@vincent Non è più un rompicoglioni che indietro quando le persone usavano mono, ecc.
rotola il

4
Non vedo il "Pacchetto precedente, System.Net.Httpora è incluso nel Microsoft.Net.Httppacchetto." lingua a cui ti riferisci nella descrizione del pacchetto. In effetti, il System.Net.Httppacchetto sembra essere aggiornato più di recente (da diversi anni)
Dan Esparza

2
@DanEsparza se guardi il link che ho postato vedrai il messaggio. Ho anche detto che solo i vecchi pacchetti (quelli 2.0) sono deprecati. Gli ultimi pacchetti 4.xx sono effettivamente i più recenti e dovresti usarli.
Henk Mollema

19

Per chiunque sia interessato a ulteriori informazioni su questo argomento , Immo Landwerth (Program manager su .NET presso Microsoft) ha twittato su questo:

"HttpClient è iniziato come un pacchetto NuGet (fuori banda) ed è stato aggiunto anche a .NET Framework nella versione 4.5 (incluso nella confezione).

Con .NET Core / .NET Standard abbiamo originariamente provato a modellare la piattaforma .NET come un insieme di pacchetti in cui non era più importante essere in-box o fuori banda. Tuttavia, questo è stato più disordinato e più complicato di quanto ci aspettassimo.

Di conseguenza, abbiamo in gran parte abbandonato l'idea di modellare la piattaforma .NET come un grafico NuGet con Core / Standard 2.0.

La risposta generale è:

Con .NET Core 2.0 e .NET Standard 2.0 non dovrebbe essere necessario fare riferimento al pacchetto NuGet SystemNetHttpClient. Tuttavia, potrebbe essere estratto dalle dipendenze 1.x.

Lo stesso vale per .NET Framework: se scegli come destinazione 4.5 e versioni successive, in genere dovresti usare la versione inclusa nella confezione anziché il pacchetto NuGet. Di nuovo, potresti finire per estrarlo per le dipendenze di .NET Standard 1.xe PCL, ma il codice scritto direttamente su .NET Framework non dovrebbe usarlo.

Allora perché il pacchetto esiste ancora / perché lo aggiorniamo ancora? Semplicemente perché vogliamo far funzionare il codice esistente che ha una dipendenza da esso. Tuttavia, come hai scoperto, non è facile navigare su .NET Framework.

Il modello previsto per il pacchetto legacy è: se si utilizza il pacchetto da .NET Framework 4.5+, .NET Core 2+, .NET Standard 2+ il pacchetto inoltra solo all'implementazione fornita dalla piattaforma invece di portare la propria versione.

Tuttavia, non è ciò che accade in tutti i casi: il pacchetto client HTTP sostituirà (parzialmente) i componenti in dotazione su .NET Framework che funzionano per alcuni clienti e falliscono per altri. Pertanto, non possiamo risolvere facilmente il problema ora.

Inoltre, abbiamo i soliti problemi di associazione con .NET Framework, quindi funziona davvero bene solo se si aggiungono reindirizzamenti di associazione. Sìì!

Pertanto, in qualità di autore di librerie, il mio consiglio è di evitare di prendere una dipendenza da questo pacchetto e di preferire le versioni in-box in .NET Framework 4.5, .NET Core 2.0 e .NET Standard 2.0. "

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


8

Microsoft.Net.Httprichiede Microsoft.Bcldipendenze aggiuntive .

Per questo, se sei mirato solo a .NET Framework o .NET Core, System.Net.Httpè bene andare. Altrimenti, Microsoft.Net.Httpsarebbe una scelta migliore in quanto potrebbe essere la prossima generazione.


8
Sembra che MS abbia cambiato idea in quanto questo post allude a ... stackoverflow.com/questions/39016373/… microsoft.net.http non è stato aggiornato dal 2015 mentre system.net.http è solo pochi mesi sago (nuget) .
smoore4
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.