Ошибка NU1605 Обнаружено понижение пакета

Question

В моем консольном приложении netcoreapp2.0 возникают следующие ошибки зависимости NU1605:

NU1605  Detected package downgrade: System.Diagnostics.Debug from 4.3.0 to 4.0.11. Reference the package directly from the project to select a different version. 
 MyProject -> Colorful.Console 1.2.6 -> System.IO.FileSystem 4.0.1 -> runtime.win.System.IO.FileSystem 4.3.0 -> System.Diagnostics.Debug (>= 4.3.0) 
 MyProject -> System.Diagnostics.Debug (>= 4.0.11)

NU1605  Detected package downgrade: System.Runtime.Extensions from 4.3.0 to 4.1.0. Reference the package directly from the project to select a different version. 
 MyProject -> Colorful.Console 1.2.6 -> System.IO.FileSystem 4.0.1 -> runtime.win.System.IO.FileSystem 4.3.0 -> System.Runtime.Extensions (>= 4.3.0) 
 MyProject -> Colorful.Console 1.2.6 -> System.Runtime.Extensions (>= 4.1.0)    MyProject

NU1605  Detected package downgrade: System.Runtime.Handles from 4.3.0 to 4.0.1. Reference the package directly from the project to select a different version. 
 MyProject -> Colorful.Console 1.2.6 -> System.IO.FileSystem 4.0.1 -> runtime.win.System.IO.FileSystem 4.3.0 -> System.Runtime.Handles (>= 4.3.0) 
 MyProject -> Colorful.Console 1.2.6 -> System.IO.FileSystem 4.0.1 -> System.Runtime.Handles (>= 4.0.1)

NU1605  Detected package downgrade: System.Runtime.InteropServices from 4.3.0 to 4.1.0. Reference the package directly from the project to select a different version. 
 MyProject -> Colorful.Console 1.2.6 -> System.Console 4.0.0 -> runtime.win.System.Console 4.3.0 -> System.Runtime.InteropServices (>= 4.3.0) 
 MyProject -> Colorful.Console 1.2.6 -> System.Runtime.InteropServices (>= 4.1.0)

Я пытался ссылаться на эти версии пакетов в csproj, но это не решает проблему. Смотрите csproj:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.0</TargetFramework>
    <RuntimeIdentifier>win10-x64</RuntimeIdentifier>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Colorful.Console" Version="1.2.6" />
    <PackageReference Include="CommandLineParser" Version="2.2.1" />
    <PackageReference Include="DotSpinners" Version="1.2.0" />
    <PackageReference Include="System.Diagnostics.Debug" Version="4.0.11" />
    <PackageReference Include="System.Runtime.Extensions" Version="4.1.0" />
    <PackageReference Include="System.Runtime.Handles" Version="4.0.1" />
    <PackageReference Include="System.Runtime.InteropServices" Version="4.1.0" />
  </ItemGroup>
</Project>

И они, кажется, восстановить нормально

Проект также ссылается на Microsoft.NETCore.App 2.0 SDK.

При выполнении восстановления dotnet из CLI я также получаю следующую ошибку, которая, я не уверен, связана с:

C:\Program Files\dotnet\sdk\2.1.200\NuGet.targets(114,5): error : Failed to retrieve information about 'System.Runtime.Serialization.Formatters' from remote source 'https://mycompany.pkgs.visualstudio.com/_packaging/myid/nuget/v3/flat2/system.runtime.serialization.formatters/index.json'. [C:\MyProject\MyProject.sln]
C:\Program Files\dotnet\sdk\2.1.200\NuGet.targets(114,5): error : Response status code does not indicate success: 401 (Unauthorized). [C:\MyProject\MyProject.sln]

Я понятия не имею, почему он пытается получить информацию о System.Runtime.Serialization.Formatters из репозитория пакетов нашей частной компании.

NuGet.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
    <add key="mycompany" value="https://mycompany.pkgs.visualstudio.com/_packaging/Stable/nuget/v3/index.json" />
  </packageSources>
  <packageSourceCredentials>
     <mycompany>
       <add key="Username" value="vsts" />
       <add key="ClearTextPassword" value="xxx" />
     </mycompany>
   </packageSourceCredentials>
  <disabledPackageSources>
    <add key="Microsoft and .NET" value="true" />
  </disabledPackageSources>
  <packageRestore>
    <add key="enabled" value="True" />
    <add key="automatic" value="True" />
  </packageRestore>
  <bindingRedirects>
    <add key="skip" value="False" />
  </bindingRedirects>
  <packageManagement>
    <add key="format" value="0" />
    <add key="disabled" value="False" />
  </packageManagement>
</configuration>

У меня также есть следующее предупреждение NU1603, если это что-то значит:

NU1603  MyProject depends on System.Runtime.Handles (>= 4.1.0) but System.Runtime.Handles 4.1.0 was not found. An approximate best match of System.Runtime.Handles 4.3.0 was resolved.

Answer 1

У меня была аналогичная проблема с консольным приложением.netcoreapp2.2.

Проект строился успешно. Однако публикация не удалась из-за нескольких ошибок NU1605.

Проблема возникла в log4net версии 2.0.8. На него ссылались в проекте.netstandard2.0 со следующими зависимостями:

Они вызывали понижение версии пакетов в проектах, ссылающихся на log4net. И при публикации эти предупреждения рассматриваются как ошибки...

Чтобы решить проблему, я добавил правильные версии этих библиотек через Nuget.

Наконец, публикация удалась.

PS Когда я впервые добавил пакеты с новейшей версией библиотек, в списке зависимостей отображался желтый предупреждающий знак, как будто пакеты не подходили для этого проекта. После выгрузки проекта и загрузки обратно предупреждающий знак пропал! (Я использую Visual Studio 2019)

Надеюсь, это поможет!

Answer 2

Ошибка NU1605 Обнаружено понижение пакета

Для ошибки NU1605:

Ты можешь использовать <NoWarn>NU1605</NoWarn> очистить WarningsAsErrors в вашем проекте.

Это потому что netcoreapp2.0 проекты имеют <WarningsAsErrors>NU1605</WarningsAsErrors> по умолчанию. Проверьте это из Properties->Build-> Обрабатывать предупреждение как ошибки:

Добавить как следующее:

<PackageReference Include="Colorful.Console" Version="1.2.6">
      <NoWarn>NU1605</NoWarn>
</PackageReference>

Посмотрите сообщение в блоге здесь: интеграция MSBuild с предупреждениями и ошибками NuGet и неожиданными предупреждениями о версии пакета.

Для ошибки NU1603:

Предупреждение происходит потому, что System.Runtime.Handles (> = 4.1.0) не существует в ленте. Обычно это ошибка создания пакета, поскольку пакет зависит от того, чего не существует.

Вы также можете использовать <NoWarn>NU1603</NoWarn> чтобы решить эту проблему:

<PackageReference>
      <NoWarn>NU1603</NoWarn>
</PackageReference>

Примечание: вы заметите, что у вашего проекта есть другое предупреждение, обратите внимание на эмблему желтого треугольника на PackageReference DotSpinners по ссылке. Это потому, что пакет DotSpinners является проектом.NET Framework, не совместимым с вашим проектом.NET Core.

Надеюсь это поможет.

Answer 3

Все вышеперечисленное не помогло мне с моим проектом.NET Core 3.1.

Ошибка NU1605 появлялась снова и снова после полной перекомпиляции. Все ссылки на номер версии в файле csproj верны.

Что наконец помогло, так это удаление папки obj!

После этого перекомпиляция прошла без проблем.

Answer 4

Была такая же проблема (NU1605) с .Net core 3.1 а также log4Net:

error NU1605: Detected package downgrade: System.Net.NameResolution from 4.3.0 to 4.0.0.

Я добавил ссылку Nuget на System.Net.NameResolution и установил версию 4.3.0, затем закрыл Visual Studio и снова открыл Решение.

Answer 5

Я столкнулся с NU1605 с .NET 5 при попытке обновить пакет Nuget.

Решение примера 2 в этой статье у меня отлично сработало.

Короче, мне оставалось только добавить

      <PackageReference Include="Microsoft.NETCore.Targets" Version="5.0.0" PrivateAssets="all" />

в ItemGroup проекта, который был целью обновления (в VS соответствующий .csproj появился, когда я дважды щелкнул сообщение об ошибке «Обнаружен переход на более раннюю версию пакета»).

Answer 6

Убедитесь, что вы используете одну и ту же версию для сборки и публикации, вы можете исправить это, добавив 2.1.9 в файл.csproj в PropertyGroup, это должно соответствовать вашей текущей версии настроек. Пример:

  <PropertyGroup>
      <OutputType>Exe</OutputType>
      <TargetFramework>netcoreapp2.1</TargetFramework>    
      <RuntimeFrameworkVersion>2.1.9</RuntimeFrameworkVersion> 
  </PropertyGroup>

Ошибка, которую я получил: NETSDK1061: проект был восстановлен с использованием Microsoft.NETCore.App версии 2.1.9, но с текущими настройками вместо него будет использоваться версия 2.1.0.

Answer 7

Что-то, с чем я столкнулся, что вызывает эту ошибку, - это наличие нескольких ссылок на один и тот же пакет в одном или нескольких файлах.csproj. В нашем случае это ссылки на локальные зависимости в нашем собственном репозитории nuget.

Это невидимо для разработчика в Visual Studio, поэтому вам нужно открыть файл.csproj в отдельном редакторе.

Для моей команды, я думаю, что причина кроется в большом количестве оттока как в зависимой библиотеке, так и в решении, которое использует эту зависимость. По какой-то причине слияние git возьмет обе версии из файла.csproj, не вызывая конфликта. В нескольких файлах проекта я нашел 3 версии одной и той же зависимости.

Answer 8

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

Как уже говорилось, обычным подозреваемым в ошибке в.Net Core 3.1 является некоторая сборка, зависящая от библиотеки, требующей System.* или же Microsoft.* сборка.

Когда сборка запускается, все может быть в порядке, потому что при разрешении сборок используются только ссылки на проекты.
Когда выполняется сборка "Опубликовать" с выбранной средой выполнения, разрешение сборок не соответствует алгоритму, используемому Nuget при восстановлении, поэтому появляется предупреждение.

Из этой ситуации следует мое решение: когда мы выполняем сборку с целевой средой выполнения, мы хотим принудительно выбрать правильную версию среды выполнения.

В файле.csproj я добавил следующее:

<!-- adjust runtime and package version accordingly -->
<ItemGroup Condition="'$(RuntimeIdentifier)' == 'win-x64' ">
  <PackageReference Include="Microsoft.NETCore.Targets" Version="3.1.0" />
</ItemGroup>

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

Answer 9

У меня была эта проблема с проектом.Net Core 2.2 с использованием библиотеки DLL.Net Standard 2.0 в том же решении. Когда я добавил несколько пакетов SeriLog в приложение.Net Core, у меня были сообщения об ошибках для стандартной DLL. Я отказался от изменений, затем добавил пакеты SeriLog один за другим, очищая и перестраивая между каждым добавлением. На этот раз ошибки не было...

Answer 10

Я не уверен, лучший ли это вариант или способ решить эту проблему, но у меня была такая же проблема:

Предупреждение NuGet NU1605 (переход на более раннюю версию пакета)

Мой процесс устранения заключался в том, чтобы убедиться, что мой проект: 1. Сохранен 2. Построить решение (ctrl shift b) (только ошибка NU1605) 3. Щелкните правой кнопкой мыши папку проекта, выберите "Управление пакетами NuGet". 4. Нажмите "Обновления", я лично обновил все пакеты. 5. (Шаг 2 снова).

Это все, что мне нужно было сделать. Надеюсь, это был тот же результат.

Answer 11

Почему-то dotnet restore выводит предупреждения о зависимости только от RuntimeIdentifier: win10-x64. portable время выполнения работает нормально.

Answer 12

Пакет NuGet GraphQL, на который я ссылался, имел зависимость от Newtonsoft.Json(>= 10.0.3). Единственным решением было следующее:

• Удалите пакет NuGet GraphQL.
• Установите последний пакет NewtonSoft.Json v12.0.3
• Вернитесь и переустановите пакет NuGet GraphQL.

Answer 13

может быть кто-то добавил новый проект с новой версией, и может быть какой-то проект со старой версией. обновление всех проектов до одной и той же версии решит проблему.

Answer 14

У меня была аналогичная проблема, когда в моем проекте была ссылка на пакет следующим образом:

Ссылки на пакеты:

• Пакет А
• Пакет B
  • Пакет А

Итак, поскольку проект B эталонный пакет A, я просто удалил пакет A из основного списка пакетов и остался с пакетом B, ссылающимся на пакет A. Я перестроил решение, и проблема исчезла.

Answer 15

Я столкнулся с этой ошибкой, и просто обновив необходимые пакеты, ваша проблема будет решена.

Вы можете обновить пакеты с помощью пакетов NuGet и консоли диспетчера пакетов.

Answer 16

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

Согласно документации Microsoft: «Когда граф пакетов для приложения содержит разные версии одного и того же пакета, NuGet выбирает пакет, ближайший к приложению в графе, и игнорирует все остальные. Такое поведение позволяет приложению переопределять любую конкретную версию пакета в график зависимости». поэтому это приводит к понижению версии пакета. Таким образом, это правило применяется с предупреждением для предупреждения пользователя.

Это скриншот менеджера NugetPacKage моего кода. Как видно на картинке, версии Serilog.Sink.Console Библиотеки и проекта Trading отличаются. Я просто удалил старый и поставил новый. возможно, удаление более нового также сработает.

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

Answer 17

Пройдя все советы выше и взяв ссылку из принятого ответа от @Mert, у меня сработало удаление конкретного пакета, который вызывал несоответствие .

Внутри папки пакета Visual Studio очень услужливо помечает пакет, вызывающий проблему, желтым предупреждающим знаком.

Я удалил пакет и использовал NuGet для установки соответствующей версии пакета.

Answer 18

Я столкнулся с аналогичной проблемой (NU1605) при публикации, но понял, что это среда выполнения linux-x64. Поэтому я удалил опцию выполнения, и проблема исчезла.

Answer 19

У меня возникла эта проблема при добавлении ссылки на подключенную службу в веб-службу ASP.Net. Добавлена ​​эта ссылка в проект Nop.Plugin.SDE, вызывающая добавление ссылки на System.ServiceModel.Http 4.4.4, в то время как она уже ссылалась на проект Nop.Services, имеющий ссылку на System.ServiceModel.Http 4.7.0. Решением было обновить ссылку на System.ServiceModel.Http до версии 4.7.0 из проекта Nop.Plugin.SDE.