Error NU1605 Detected package downgrade

Question

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.

Any update for this issue? Have you resolved this issue? If not, would you please let me know the latest information about this issue? — Leo Liu-MSFT, May 18 '18 at 02:08
If you are experiencing this issue,perhaps on a different package, its probably because you referenced a library that references same package but a different version. Try updating package via Nuget Manager in the referencing project. — oliverdejohnson, Apr 21 '20 at 13:43
Although this is quite an old issue, I just had similar issues with System.IO.FileSystem.Primitives and System.Runtime.Handles in .NET 5.0. Both were pointing that I had an outdated version, like 4.0.1 and told me to upgrade it to 4.3.0. I just installed these libraries in nuget with the correct versions so: System.IO.FileSystem.Primitives -> 4.3.0 System.Runtime.Handles -> 4.3.0 And it worked, the error was no longer there. Hopefully, I can help whoever will have this issue in the future. — GoodNickName, Jan 20 '21 at 13:48

Mert Can Ilis · Accepted Answer · 2019-09-30T13:53:19.233

67

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)

Hope it helps!

edited Sep 30 '19 at 13:53

answered Sep 20 '19 at 10:20

Mert Can Ilis

2,371
1
18
18

I 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. – phansen Jan 29 '20 at 18:34
1

I am getting exact same problem with log4net. How did you change specific DLL dependency for it? My .NetCore version is 3.1.0. – M P Feb 27 '20 at 16:41
You can search for the dll in nuget and install the latest version. – Mert Can Ilis Feb 28 '20 at 15:05
Yes, 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. – Adnan Jun 18 '20 at 16:24
For log4net specifically, the Microsoft.NETCore.Targets library added to the solution fixes it as well. See https://stackoverflow.com/questions/47712035/what-is-the-right-way-to-fix-error-nu1605-detected-package-downgrade-log4net – Carson Evans Jul 24 '20 at 15:16

score 42 · Answer 2 · edited Nov 01 '19 at 12:22

42

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.

Hope this helps.

edited Nov 01 '19 at 12:22

Newteq Developer

1,038
14
27

answered May 14 '18 at 04:31

Leo Liu-MSFT

52,692
7
69
81

9

good 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. – Michael Brown Nov 26 '19 at 21:29
It 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. – Jahmic May 26 '20 at 10:53
I really, really don't like this answer. Silencing warning should never be a solution. Especially when there are alternatives. – A. Chiesa Nov 03 '20 at 11:50
I struggle alot finally just added the latest version of dll from nugget, then unload ->reload the project and everything work to normal. Thanks – NishantVerma.Me Nov 25 '20 at 12:34

score 9 · Answer 3 · edited Dec 02 '20 at 10:06

9

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.

edited Dec 02 '20 at 10:06

Uwe Keim

36,867
50
163
268

answered Mar 25 '20 at 23:28

arielhad

493
3
6

1

For me, A Visual Studio restart was all that was needed. Odd. – Ian Gibblet Aug 12 '20 at 09:59
same here. but problem is resolved in latest log4net nugetpacakge now. so i have removed it – Kamran Shahid Jan 04 '21 at 18:39

score 5 · Answer 4 · answered Apr 16 '19 at 20:36

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.

score 4 · Answer 5 · answered Jun 14 '19 at 13:28

Something that I've run into that causes this error is having multiple references to the same package in one or more .csproj files. In our case, these references are to local dependencies in our own nuget repository.

This is invisible to a developer in Visual Studio, so you need to open the .csproj file in a separate editor.

For my team, I think the cause is a combo of a lot of churn in both a dependent library and the solution that consumes that dependency. For whatever reason, a git merge will take both versions in the .csproj file without raising a conflict. In several project files, I found 3 versions of the same dependency.

score 4 · Answer 6 · answered Aug 13 '20 at 16:00

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.

answered Aug 13 '20 at 16:00

Frankenstein

535
4
13

this helped thanks! – kofifus Jan 28 '21 at 01:14

score 1 · Answer 7 · answered Sep 24 '19 at 08:57

I had this problem with a .Net Core 2.2 project using a .Net Standard 2.0 DLL in the same solution. I had the errors reported for the .Net Standard DLL when I added several SeriLog packages to the .Net Core application. I backed out the changes, then added the SeriLog packages one-by-one, cleaning and rebuilding between each addition. This time there was no error...

score 1 · Answer 8 · answered Jan 09 '20 at 01:01

I am not sure if this is the best option or the way to fix this problem, but i had the same issue:

NuGet Warning NU1605 (package downgrade)

My process of elimination was to make sure my project was: 1. Saved 2. Build Solution (ctrl shift b) (only error was the NU1605) 3. Right click project folder, click into Manage NuGet packages. 4. Click on Updates, I personally updated all packages. 5. (Step 2 again).

This was all i needed to do. Hopefully this was the same outcome.

score 0 · Answer 9 · answered Dec 18 '19 at 21:28

0

I faced a similar problem (NU1605) when publishing but I figured out was the runtime linux-x64. So I removed the runtime option and the problem has gone.

answered Dec 18 '19 at 21:28

Gandarez

2,402
3
26
42

score 0 · Answer 10 · edited Oct 06 '20 at 07:39

0

I had a similar issue, where my project had package reference like this:

Package references:

Package A
Package B
- Package A

So because project B reference package A, I just deleted package A from the main packages list and was left with Package B referencing Package A. I rebuilt the solution and the problem was gone.

edited Oct 06 '20 at 07:39

Dharman

21,838
18
57
107

answered Oct 06 '20 at 07:34

Yair A.

11
2

score 0 · Answer 11 · answered Nov 03 '20 at 11:46

There are already a bunch of answers to the question, many of them fixing the problem, but I think the solution I applied is cleaner than everything else I saw online.

As stated, the usual suspect of the error in .Net Core 3.1 is some assembly depending upon a library requiring a System.* or Microsoft.* assembly.

When the build runs, everything can be fine, because the resolution of assemblies is using only project references.
When a "Publish" build is performed, with a runtime selected, the resolution of assemblies doesn't follow the algorithm used by Nuget when restoring, so the Warning creeps up.

From this situation, follows my solution: when we perform a build with a target runtime, we want to enforce that the correct runtime version is selected.

In the .csproj file, I added this:

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

The Microsoft.NETCore.Targets package, found at this link (which has lots of info on the warning) is one of the solutions to the dreaded warning, and having it included only in the publish build keeps all the other builds untouched. The nice thing of this package is that it is one package, and includes all the runtime.

that didnt work for me.. so annoying this issue – Piotr Kula Jan 04 '21 at 22:14 — Piotr Kula, Jan 04 '21 at 22:14

score 0 · Answer 12 · answered Nov 10 '20 at 07:22

I had this problem when adding a Connected Service reference to an ASP.Net Webservice. Added this reference in project Nop.Plugin.SDE causing a reference to System.ServiceModel.Http 4.4.4 to be added, while it already was referencing project Nop.Services having a reference to System.ServiceModel.Http 4.7.0. The solution was to upgrade the reference to System.ServiceModel.Http to version 4.7.0 from project Nop.Plugin.SDE.

score 0 · Answer 13 · answered Dec 04 '20 at 18:35

The GraphQL nuGet package I was referencing had a dependency to Newtonsoft.Json(>= 10.0.3). The only solution was the following:

Remove the GraphQL nuGet package.
Install the latest NewtonSoft.Json package v12.0.3
Go back and reinstall the GraphQL nuGet package.

score 0 · Answer 14 · answered Apr 06 '21 at 15:21

0

Somewhy dotnet restore brings dependency warnings only on RuntimeIdentifier:win10-x64. portable runtime works normally.

answered Apr 06 '21 at 15:21

Oleg

1,133
11
15

Error NU1605 Detected package downgrade

14 Answers14

Linked