System.Net.Http проти Microsoft.Net.Http


86

Я використовую ASP.NET Core. Я хочу використовувати, HttpClientале я помітив, що пропонуються два пакети NuGet. Який я використовую?


Схоже, це System.Net.Httpзалежить від Microsoft.Net.Http. Але знову ж таки, це залежить від того, що ви намагаєтесь зробити із вашим додатком.
Джон Одом,

Відповіді:


64

Залежить від версії. Старі System.Net.Httpпакети (пакети 2.0 ) є застарілими пакетами, які припинено на користь Microsoft.Http.Netвідповідно до опису:

Старий пакет System.Net.Http тепер включений до пакета Microsoft.Net.Http.

Вони існують для забезпечення HttpClientпопередніх версій .NET та портативних бібліотек класів. Ви повинні використовувати Microsoft.Net.Httpв цьому випадку.

Оскільки ви використовуєте .NET Core, вам слід використовувати найновіший System.Net.Httpпакет (наприклад, 4.3.3).

Оновлено для csproj

Станом на .NET Standard 2.0 System.Net.HttpClientпакет вже включений і доступний, коли ви націлюєтесь netstandard2.0. Якщо з якихось причин ви все ще хочете посилатися на нього як для повного .NET, так і для .NET Core, ви можете додати це до свого файлу 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>

Якщо ви використовуєте project.json

Якщо ваш project.json націлений як на повний .NET, так і на .NET Core, вам слід додати System.Net.Httpзбірку до frameworkAssembliesелемента. Наприклад:

"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
Майте на увазі, що вони не мають абсолютно однакової поведінки. Повна версія .NET (4.0.0.0) не виконує автоматичного стиснення, тоді як версія .NET Core (4.1.0) робить це. Отже, якщо ви використовуєте повну версію .NET, вам потрібно вручну налаштувати обробник для використання стиснення gzip / deflate. Опис: github.com/dotnet/docs/issues/1054
Андерсен

28
Ця відповідь підсумовує, в якій хаосі це сталося з .NET Core, .NET Standard та .NET Framework.
Вінсент

1
@vincent Це не біль у дупі, аніж спина, коли люди використовували моно та ін. Мультиплатформа завжди має деякі болі.
котиться

4
Я не бачу "Спадковий пакет, System.Net.Httpтепер включений у Microsoft.Net.Httpпакет". мовою, на яку ви посилаєтесь в описі пакета. Насправді, System.Net.Httpпакет здається останнім часом оновленим (на кілька років)
Ден Еспарза,

2
@DanEsparza, якщо ти подивишся посилання, яке я розмістив, ти побачиш повідомлення. Я також згадав, що застаріли лише старі пакунки (пакети 2.0). Останні пакети 4.xx справді є найновішими, і ви повинні ними користуватися.
Хенк Моллема

19

Для всіх, кого цікавить більше передісторія цього, Іммо Ландверт (менеджер програм у .NET в Microsoft) написав про це твіт :

"HttpClient розпочався як пакет NuGet (поза діапазоном) і був доданий до .NET Framework також у 4.5 (в коробці).

За допомогою .NET Core / .NET Standard ми спочатку спробували змоделювати платформу .NET як набір пакетів, де переживання в коробці та поза діапазоном більше не мало значення. Однак це було грязніше і складніше, ніж ми передбачали.

Як результат, ми в основному відмовилися від ідеї моделювання платформи .NET як графіку NuGet з Core / Standard 2.0.

Загальна відповідь:

У .NET Core 2.0 та .NET Standard 2.0 вам не потрібно взагалі посилатися на пакет SystemNetHttpClient NuGet. Однак це може бути витягнуто із залежностей 1.x.

Те саме стосується .NET Framework: якщо ви націлюєтеся на 4.5 і вище, вам, як правило, слід використовувати внутрішню версію замість пакета NuGet. Знову ж таки, ви можете в кінцевому підсумку застосувати його для залежностей .NET Standard 1.x та PCL, але код, написаний безпосередньо проти .NET Framework, не повинен його використовувати.

То чому пакет все ще існує / чому ми все ще оновлюємо його? Просто тому, що ми хочемо змусити існуючий код працювати так, щоб він залежав від нього. Однак, як ви виявили, це не плавне плавання на .NET Framework.

Призначена модель для застарілого пакету: якщо ви використовуєте пакет із .NET Framework 4.5+, .NET Core 2+, .NET Standard 2+, пакет перенаправляється лише на платформу, що реалізується, на відміну від власної версії.

Однак насправді це трапляється не у всіх випадках: пакет клієнтських HTTP (частково) замінить вбудовані компоненти .NET Framework, які працюють для одних клієнтів, а для інших - не. Таким чином, ми не можемо легко вирішити проблему зараз.

Крім того, у нас є звичайні проблеми з прив'язуванням .NET Framework, тому це дійсно працює добре, якщо ви додаєте перенаправлення на прив'язку. Ага!

Тому, як автор бібліотеки, я рекомендую уникати залежності від цього пакету та віддавати перевагу версіям, що входять у .NET Framework 4.5, .NET Core 2.0 та .NET Standard 2.0 ".

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


8

Microsoft.Net.Httpвимагає додаткових Microsoft.Bclзалежностей.

Для цього, якщо ви націлені лише на .NET Framework або .NET Core, System.Net.Httpдобре піти. Інакше Microsoft.Net.Httpбуде кращим вибором, оскільки це може бути наступне покоління.


8
Здається, що MS передумали, оскільки ця публікація натякає на ... stackoverflow.com/questions/39016373/… microsoft.net.http не оновлювався з 2015 року, тоді як system.net.http - це лише кілька місяців тому (nuget) .
smoore4
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.