c# - dotnet - System.Net.Http vs Microsoft.Net.Http

restclient c#

Question

Estoy usando ASP.NET Core. Quiero usar HttpClient pero noté que se ofrecen dos paquetes NuGet. ¿Cuál uso?

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

Answer 1

Depende de la versión. Los viejos paquetes de System.Net.Http (los 2.0 ) son paquetes heredados que están en desuso a favor de Microsoft.Net.Http según la descripción:

Paquete heredado, System.Net.Http ahora está incluido en el paquete ''Microsoft.Net.Http''.

Existen para proporcionar el HttpClient en versiones anteriores de .NET y bibliotecas de clases portátiles. Debería usar Microsoft.Net.Http en ese caso.

Como está utilizando .NET Core, debe usar el último paquete System.Net.Http (por ejemplo, 4.3.3).

Actualizado para csproj

A partir de .NET Standard 2.0, el paquete System.Net.HttpClient ya está incluido y disponible cuando apunta a netstandard2.0 . Si por alguna razón aún desea hacer referencia a él tanto para .NET completo como para .NET Core, puede agregar esto a su archivo 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 estás usando project.json

Si su project.json está dirigido a .NET y .NET Core completos, debe agregar el ensamblado System.Net.Http al elemento frameworkAssemblies . Por ejemplo:

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

Answer 2

Para cualquier persona interesada en obtener más información sobre esto, Immo Landwerth (gerente de programa en .NET en Microsoft) tweeted sobre esto:

"HttpClient comenzó como un paquete NuGet (fuera de banda) y también se agregó a .NET Framework en 4.5 (en caja).

Con .NET Core / .NET Standard originalmente intentamos modelar la plataforma .NET como un conjunto de paquetes donde ya no importaba estar dentro de la caja versus fuera de banda. Sin embargo, esto fue más desordenado y más complicado de lo que anticipamos.

Como resultado, abandonamos en gran medida la idea de modelar la plataforma .NET como un gráfico NuGet con Core / Standard 2.0.

La respuesta general es:

Con .NET Core 2.0 y .NET Standard 2.0, no debería necesitar hacer referencia al paquete SystemNetHttpClient NuGet. Sin embargo, podría ser extraído de las dependencias 1.x.

Lo mismo ocurre con .NET Framework: si apunta a 4.5 y versiones superiores, generalmente debería usar la versión en caja en lugar del paquete NuGet. Nuevamente, puede terminar tirando de él para .NET Standard 1.xy dependencias PCL, pero el código escrito directamente en .NET Framework no debería usarlo.

Entonces, ¿por qué todavía existe el paquete / por qué todavía lo actualizamos? Simplemente porque queremos hacer que el código existente funcione y dependa de él. Sin embargo, como descubrió, no es fácil navegar en .NET Framework.

El modelo previsto para el paquete heredado es: si consume el paquete de .NET Framework 4.5+, .NET Core 2+, .NET Standard 2+, el paquete solo reenvía a la implementación proporcionada por la plataforma en lugar de traer su propia versión.

Sin embargo, eso no es lo que realmente sucede en todos los casos: el paquete del Cliente HTTP reemplazará (parcialmente) los componentes de la caja en .NET Framework que funcionan para algunos clientes y fallan para otros. Por lo tanto, no podemos solucionar fácilmente el problema ahora.

Además de eso, tenemos los problemas de enlace habituales con .NET Framework, por lo que esto realmente funciona bien si agrega redireccionamientos de enlace. ¡Hurra!

Por lo tanto, como autor de la biblioteca, mi recomendación es evitar depender de este paquete y preferir las versiones incluidas en .NET Framework 4.5, .NET Core 2.0 y .NET Standard 2.0 ".

tweeted

Answer 3

Microsoft.Net.Http requiere dependencias adicionales de Microsoft.Bcl .

Para eso, si solo está dirigido a .NET Framework o .NET Core, System.Net.Http está listo. De lo contrario, Microsoft.Net.Http sería una mejor opción, ya que podría ser la próxima generación.