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

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

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

Зависит от версии. Старые 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
    }
  }
}

Для всех, кто интересуется более подробной информацией об этом, Иммо Ландверт (менеджер программ по .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

Microsoft.Net.Httpтребует дополнительных Microsoft.Bclзависимостей.

Для этого, если вы нацелены только на .NET Framework или .NET Core, System.Net.Httpэто хорошо. В противном случае это Microsoft.Net.Httpбыл бы лучший выбор, поскольку это могло быть следующее поколение.