Error NU1605 Detected package downgrade
Solution 1
I had a similar issue with a .netcoreapp2.2 console application.
The project was building successfully. However, publishing was failing with several NU1605 errors.
The problem was originated from log4net version 2.0.8. It was referenced in a .netstandard2.0 project with the following dependencies:
They were causing package downgrades in the projects referencing log4net. And during publish these warnings are treated as errors...
To solve the problem I added correct versions of these libraries via Nuget.
Finally, the publishing succeeded.
P.S. When I first added packages with the newest version of libraries, a yellow warning sign was displayed on the dependencies list as if the packages were not suitable for that project. After unloading the project and loading back the warning sign gone! (I'm using Visual Studio 2019)
Solution 2
Error NU1605 Detected package downgrade
For the error NU1605:
You can use <NoWarn>NU1605</NoWarn>
to clear the WarningsAsErrors
in your project.
That because netcoreapp2.0
projects have <WarningsAsErrors>NU1605</WarningsAsErrors>
by default. Check it from Properties->Build->Treat warning as errors:
Add like following:
<PackageReference Include="Colorful.Console" Version="1.2.6">
<NoWarn>NU1605</NoWarn>
</PackageReference>
Check the blog post here: MSBuild integration of NuGet warnings and errors and Unexpected package version warnings.
For the error NU1603:
The warning occurs because System.Runtime.Handles
(>= 4.1.0) does not exist in the feed. Typically this is a package authoring error because the package depends on something that doesn't exist.
You can also use <NoWarn>NU1603</NoWarn>
to resolve this issue:
<PropertyGroup>
<NoWarn>NU1603</NoWarn>
</PropertyGroup>
Note:You would notice that your project has another warning, notice the yellow triangle insignia on the PackageReference DotSpinners
on Reference. That because the package DotSpinners
is a .NET Framework project, not compatible with your .NET Core project.
Solution 3
Just had the same issue (NU1605) with .Net core 3.1
and log4Net
:
error NU1605: Detected package downgrade: System.Net.NameResolution from 4.3.0 to 4.0.0.
What I did is adding a Nuget reference to System.Net.NameResolution
and install version 4.3.0, then I closed Visual Studio and re-opened the Solution.
Solution 4
All of the above did not help me with my .NET Core 3.1 project.
The error NU1605 reappeared again and again after complete recompilation. All references to the version number have been correct in the csproj file.
What finally helped was to delete the obj folder!
Afterwards the recompilation worked without problems.
Solution 5
Make sure that you are using same version for build and publish you can fix it adding 2.1.9 in .csproj file under PropertyGroup this should match with your current settings version. Ex:
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.1</TargetFramework>
<RuntimeFrameworkVersion>2.1.9</RuntimeFrameworkVersion>
</PropertyGroup>
Error which I got was: NETSDK1061: The project was restored using Microsoft.NETCore.App version 2.1.9, but with current settings, version 2.1.0 would be used instead.
Dave New
Updated on December 03, 2021Comments
-
Dave New over 2 years
I am experiencing the following NU1605 dependency errors in my netcoreapp2.0 console application:
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)
I have tried referencing these package versions in csproj, but this doesn't fix the problem. See 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>
And they do seem to restore fine:
The project is also referencing the Microsoft.NETCore.App 2.0 SDK.
When performing dotnet restore from the CLI, I also get the following error, which I am not sure is related:
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]
I have no idea why it's trying to retrieve information about 'System.Runtime.Serialization.Formatters' from our private company package repository.
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>
I also have the following NU1603 warning if this means anything:
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.
-
Michael Brown over 4 yearsgood info, but doesn't actually resolve the issue it just ignores the issue during build. When publishing you will get runtime errors when these dll's are trying to be loaded. See Mert's answer.
-
phansen over 4 yearsI just encountered this exact problem. I have a project I am publishing which targets .Net Core and .Net Standard. I think this problem only manifested when I added .Net Standard as a target framework. Adding those three packages solved the issue.
-
M P about 4 yearsI am getting exact same problem with log4net. How did you change specific DLL dependency for it? My .NetCore version is 3.1.0.
-
Mert Can Ilis about 4 yearsYou can search for the dll in nuget and install the latest version.
-
Jahmic almost 4 yearsIt seems much more often than not, ignoring these warnings, building and running will be fine. Yes, it's good practice to pay attention and resolve the core issues. But in this case, these should remain as warnings and not as errors. Perhaps this will get changed in future versions.
-
Adnan almost 4 yearsYes, just had the exact same issue with log4net in a .NET Core 3.1 console app. I had to add those packages to my class library as well as the main executable project.
-
Carson Evans almost 4 yearsFor log4net specifically, the Microsoft.NETCore.Targets library added to the solution fixes it as well. See stackoverflow.com/questions/47712035/…
-
Ian Gibblet almost 4 yearsFor me, A Visual Studio restart was all that was needed. Odd.
-
Alberto Chiesa over 3 yearsI really, really don't like this answer. Silencing warning should never be a solution. Especially when there are alternatives.
-
Nishant Kumar Verma over 3 yearsI struggle alot finally just added the latest version of dll from nugget, then unload ->reload the project and everything work to normal. Thanks
-
Kamran Shahid over 3 yearssame here. but problem is resolved in latest log4net nugetpacakge now. so i have removed it
-
Piotr Kula over 3 yearsthat didnt work for me.. so annoying this issue
-
Hamza Iftikhar almost 3 years@IanGibblet For every problem restart should be The first solution to try :D
-
markyk almost 3 yearsThis is the correct answer for anyone looking. We are getting this building Xamarin projects. Open the project in VSCode and look in the .csproj files of the sub projects for the item group with the "PackageReference" elements and update them to be the same as the default. I am still looking into why VS isn't doing this, but this will get you on your way.
-
Mehdi Daustany over 2 yearsUpdating "System.ServiceModel.Primitives" has solved my problem, thanks.
-
Jacek Labuda over 2 yearsIt was helpful also for migration from .Net 5 to .Net 6