Найдено конфликты между System.Net.Http

Ответ 1

Вы можете принудительно установить версию, которую вы устанавливаете, так что вы можете выровнять оба проекта или найти сообщение в окне вывода, которое будет сообщать вам, что неправильно или что ваши зависимости. Поскольку в официальной ссылке нет версии 4.2, я бы сделал это (решение в целом)

Install-Package System.Net.Http -Version 4.1.1

Или для обоих проектов

Get-Project ProjectName | Install-Package System.Net.Http -Version 4.1.1

Или, еще лучше (используя последнюю версию)

Install-Package System.Net.Http -Version 4.3.3

РЕДАКТИРОВАТЬ

Видимо, вы не первый, кто испытал это. Как насчет ответа здесь? В основном вы можете выровнять этот раздел конфигурационного файла обоих проектов:

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.1.2" newVersion="4.2.0.0" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>

Возможно, вам придется адаптировать значение токена. На всякий случай, вы можете вставить файл конфигурации для обоих проектов =

Ответ 2

Изменение: это происходит только при использовании.NET Framework. В среде.NET Core/Standard самая последняя версия сборки System.Net.Http как представляется, всегда 4.1.2.0 - нет версии 4.2.0.0.

Проблема, связанная с System.Net.Http, является способом, более сложным, тогда ответы здесь, похоже, подразумевают...

1. Да, есть пакет System.Net.Http NuGet, но нет, он не будет устанавливать последнюю версию той же сборки (она содержит версию 4.1.1.2 сборки System.Net.Http, а не 4.2.0.0).
2. Последняя Microsoft Visual Studio (или Microsoft Visual Studio Build Tools) предоставляет версию 4.2.0.0, но это не значит, что ваш.csproj всегда будет использовать ее...
3. По какой-то причине (чего я еще не смог понять) единственным гарантированным способом использования 4.2.0.0 является ссылка на определенные пакеты NuGet, которые его используют, например, System.Buffers (версия 4.5.0 работала для меня).

TL; DR:

Добавьте System.Buffers 4.5. 0+ Ссылка NuGet на ваш проект, если вы хотите убедиться, что он использует сборку System.Net.Http 4.2.0.0.

Рекомендации:

• https://github.com/dotnet/corefx/issues/17522
• https://github.com/dotnet/corefx/issues/22781
• https://github.com/dotnet/corefx/issues/25773

Ответ 3

Пройдя через все решения, представленные здесь, и ссылки, приведенные в этом ответе, я наконец решил это полностью. Это то, что я считаю, что любой, кто сталкивается с этой проблемой, должен сделать:

1. Обновите все пакеты NuGet до последней версии.
2. Перенесите NuGet из packages.config в PackageReference в соответствии с инструкциями здесь. По сути, для каждого проекта в вашем решении: в обозревателе решений щелкните правой кнопкой мыши узел References или файл packages.config и выберите Migrate packages.config в PackageReference.... Проекты веб-сайтов ASP.NET должны оставаться с использованием packages.config.
3. Удалите все ссылки на System.Net.Http, которые не управляются NuGet (для проектов, использующих PackageReference, вы должны увидеть символ NuGet рядом со ссылкой в Solution Explorer). Замените удаленные ссылки System.Net.Http соответствующим пакетом NuGet, если вы уверены, что вашему проекту требуется System.Net.Http (попробуйте сначала System.Net.Http его без него). Для проектов, использующих package.config, будьте особенно внимательны, чтобы убедиться, что ссылки на System.Net.Http требуются и что они также используют NuGet. Это может помочь удалить и повторно добавить System.Net.Http через NuGet в любом случае (для всех проектов, ссылающихся на него), даже если на него уже ссылались с помощью NuGet. Я обнаружил, что шаг 2 может привести к некоторому разъединению где-то.
4. Обновите до .NET Framework 4.7.2 по причинам, описанным здесь. Это часть VS 2019. В противном случае загрузите его отсюда или используйте установщик Visual Studio для VS 2017.
5. Удалите все привязки сборки из всех файлов app.config и Web.config, затем постройте свое решение. Привязки app.config больше не требуются. Привязки Web.config будут повторно добавлены на следующем шаге, но их удаление в первую очередь гарантирует, что в ваших привязках не будет устаревших версий.
6. Теперь вы можете получить некоторые другие конфликты на этом этапе. Для проектов вашего веб-сайта ASP.NET добавьте перенаправления привязки в ваш Web.config, которые вы получаете в предупреждениях. Для других приложений .NET Framework для ссылок, для которых вы получаете предупреждения, добавьте соответствующие пакеты NuGet в проекты, в которые вы получаете предупреждения, даже если проект компилируется без добавления ссылки. Это вынуждает проект использовать версию NuGet, а не локальную версию .NET Framework, на которую может ссылаться другой пакет. Это связано с переходом между .NET Framework и .NET Standard, на что ссылается упомянутый выше ответ. После сборки вам может понадобиться повторить этот шаг для дальнейших ссылок.

Если позже вы обнаружите, что вы получаете исключения во время выполнения (даже во время модульного тестирования) из-за явных несоответствий после добавления ссылки куда-либо, удалите все перенаправления привязки из соответствующего проекта веб-сайта, а затем добавьте предложенные в предупреждении как за шаг 6.

Я потратил много времени, пытаясь решить эту проблему методично, поэтому я считаю, что описанные выше шаги позволят полностью решить проблемы большинства людей, хотя для нестандартных случаев может потребоваться некоторое боковое мышление. Дайте мне знать, если это работает (или не работает) для вас.

Ответ 4

Это имеет тенденцию происходить, когда у вас есть ссылка на инфраструктуру System.Net.Http, но для одной из ваших ссылок на пакет требуется пакет NuGet System.Net.Http.

Посмотрите, есть ли у вас ссылка на эту сборку, удалите ее и установите пакет NuGet

Ответ 5

Существует новое решение для этого, которое работает с 9 октября 2018 года.

1. Вам нужно будет обновить все ваши ссылки на System.Net.Http до последней версии 4.3.4.
2. Вы должны установить пакет в свое решение .Net Framework, которое вызывает конфликт, даже если для него явно не требуется пакет.

3. Если ваш проект имеет новую структуру проекта, отредактируйте ее и убедитесь, что она содержит следующую ссылку на пакет:

   <PackageReference Include="System.Net.Http" Version="4.3.4" />
   

4. Найдите ваше решение и удалите все существующие перенаправления привязки для System.Net.Http, они будут выглядеть следующим образом

   <dependentAssembly>
     <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
     <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />
   </dependentAssembly>
   

5. Перестройте, предупреждение теперь должно исчезнуть, и ваш код должен работать и нормально работать

Ответ 6

6 шагов, которые Neo опубликовал выше, помогли мне решить проблемы с пакетом ASP.NET! Спасибо, Нео! Я занимался этим более недели.

Я просто хочу поделиться своими личными заметками из моего опыта внедрения Neo в посте выше.

У меня был проект ASP.NET Web API, нацеленный на .Net Framework 4.6.1

Вот что я сделал:

• Обновление до .Net Framework 4.7.2
• Обновите все пакеты NuGet до последней версии.
• (опционально, может также выполнить "update-package -reinstall", чтобы убедиться, что все пакеты связаны с 4.7.2)
• Консолидировать пакеты
• Я не мигрировал из packages.config в PackageRefence, потому что вы не можете в ASP.NET
• Удалил ссылки из System.Net.Http и других, которые в этом нуждались, и добавил их как пакеты NuGet.
• Удалены все привязки сборки из web.config и app.config (в библиотеках .Core,.Tests,.IntegrationTests)
• Добавлены перенаправления привязки для наших собственных пакетов NuGet, которые имели номера версий, оканчивающиеся на текст (nnnn-beta), но удаляли текст и имели только номера (nnnn)
• Добавил это во все файлы .csproj:
  • MSBuild и <AutoUnifyAssemblyReferences/>
  • https://github.com/Azure/azure-webjobs-sdk/issues/1598

<PropertyGroup>
  <AutoUnifyAssemblyReferences>true</AutoUnifyAssemblyReferences>
</PropertyGroup>

• Убедитесь, что пакеты во всех файлах packages.config имеют одинаковые версии во всех проектах решения.
  • Убедитесь, что версии в файле web.config одинаковы
  • Убедитесь, что версии совпадают в файле .csproj, если применимо
• Используйте Microsoft.Net.Compilers 3.1.1 (обновите все файлы .csproj в решении, включая .Tests и .IntegrationTests)
• Для API защиты данных (DPAPI), использующего Redis:
  • Установите Microsoft.AspNetCore.DataProtection.StackExchangeRedis 2.2.5
  • StackExchange.Redis 2.0.601
  • Обновите System.Numerics.Vectors до 4.4.0 (примечание: в 4.5.0 есть ошибка, препятствующая подключению к серверу)