Текущее состояние System.Net.Http против Microsoft.Net.Http

Я запутался с упаковкой HttpClient. Ранее он был распространен как часть пакета Microsoft.Http.Net NuGet, а System.Net.Http считался устаревшим. Похоже, теперь все наоборот: есть свежий пакет System.Net.Http для всех платформ, а Microsoft.Net.Http не обновлялся через некоторое время, и, по словам людей в команде разработчиков Microsoft, будет устаревшим.

Вопросы:

  • Можем ли мы заменить зависимости на Microsoft.Net.Http пакет NuGet с (новейшим) System.Net.Http?
  • Должна ли прежняя платформа .NET 4.0 использовать Microsoft.Net.Http? Как насчет платформ, отличных от Windows (iOS, Android)? Новый System.Net.Http поддерживает их, но я помню, что с Microsoft.Net.Http мне пришлось дополнительно установить Microsoft.Bcl.Build и Microsoft.Bcl, чтобы работать с кросс-платформенными. System.Net.Http не зависит от них. Можно ли пропускать пакеты Bcl?
  • System.Net.Http не хватает некоторых методов расширения Http, таких как SupportsPreAuthenticate, и попытка вызвать этот метод приводит к ошибкам во время выполнения (отсутствующий метод). Как мы должны справляться с этим?

ОТВЕТЫ

Ответ 1

Это длится долго и продолжает запутываться. Я сам видел такую ​​передачу сообщений, но на данный момент выглядит System.Net.Http - это правильный выбор, по крайней мере для .NET на платформе Windows и не имеет внешних зависимостей.

Для .NET Core я использовал Microsoft.Net.Http, хотя для этого требуется Microsoft.BCL. Если у вас нет проблем, я предлагаю оставить устаревшие системы как есть, тем более, что эти пространства имен, похоже, движутся цели.

Если это не слишком сложно для вас, HttpClient Sample, связанный с System.Net.Http, использует Windows.Web.Http! Эта реализация предназначена для приложений Windows Store.

Возможно, в следующем году все это снова изменится.