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 - это всего лишь несколько месяцев sago (nuget) .
smoore4
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.