Home: NuGet gives detected package downgrade error when there are no version constraint conflicts in the dependency tree

[sanderaernouts]

Details about Problem

NuGet product used (VS UI | Package Manager Console):
NuGet version 4.4.1.4656
VS version: 15.4.5 (but issues also occurs with latest 15.5 update)
OS version: Microsoft Windows 10 Pro (10.0.16299 Build 16299)

Detailed repro steps so we can see the same problem

1. Create a new empty solution
2. Add 3 class library projects (A, B and C)
3. Set the target framework to <TargetFramework>net461</TargetFramework> for all 3 projects
4. Install NewtonSoft.json version 8.0.1 into project B
5. Install NuGet.Packaging version 4.5.0 into project C
6. Update NewtonSoft.json to version 9.0.1 in project B

I now have the following situation:

NuGet reports errors here even though the dependency constraints can be satisfied:

Trying to update to version 9.0.1 in project B doesn't work as well because of these errors even though this update would resolve the error NuGet reports:

Problem

Project B requires >=8.01 and project C requires >=9.0.1 through NuGet.Packaging thus 9.0.1 is the lowest possible version that satisfies both version constraints in this dependency tree. However NuGet chooses 8.0.1. I would expect NuGet to be able to resolve this simple dependency tree because the version constraints in this tree are not conflicting, however NuGet detects this as a package downgrade. There is no error in the tree, all constraints can be satisfied so I do not expect an error here.

I cannot update either to resolve the issue or consolidate in a bit more complex scenario because of the errors NuGet reports.

Expected behaviour

1. No errors
2. The resolved dependency version is 9.0.1 as this is the lowest possible version that satisfies all version constraints in the dependency tree.

Verbose Logs

Running restore with 8 concurrent jobs.
Reading project file C:\tmp\NuGetIssueSample\B\B.csproj.
Restoring packages for C:\tmp\NuGetIssueSample\B\B.csproj...
Restoring packages for .NETFramework,Version=v4.6.1...
Resolving conflicts for .NETFramework,Version=v4.6.1...
Checking compatibility of packages on .NETFramework,Version=v4.6.1.
Checking compatibility for B 1.0.0 with .NETFramework,Version=v4.6.1.
Checking compatibility for Newtonsoft.Json 8.0.1 with .NETFramework,Version=v4.6.1.
Checking compatibility for C 1.0.0 with .NETFramework,Version=v4.6.1.
Checking compatibility for NuGet.Packaging 4.5.0 with .NETFramework,Version=v4.6.1.
Checking compatibility for NuGet.Common 4.5.0 with .NETFramework,Version=v4.6.1.
Checking compatibility for NuGet.Packaging.Core 4.5.0 with .NETFramework,Version=v4.6.1.
Checking compatibility for NuGet.Frameworks 4.5.0 with .NETFramework,Version=v4.6.1.
Checking compatibility for NuGet.Versioning 4.5.0 with .NETFramework,Version=v4.6.1.
All packages and projects are compatible with .NETFramework,Version=v4.6.1.
Detected package downgrade: Newtonsoft.Json from 9.0.1 to 8.0.1. Reference the package directly from the project to select a different version.
B -> C -> NuGet.Packaging 4.5.0 -> Newtonsoft.Json (>= 9.0.1)
B -> Newtonsoft.Json (>= 8.0.1)
Package restore failed. Rolling back package changes for 'B'.
Time Elapsed: 00:00:00.0691017
========== Finished ==========

Sample Project

NuGetIssueSample.zip

[emgarten]

There is no error in the tree, all constraints can be satisfied so I do not expect an error here.

You are completely correct and NuGet emits NU1605 as a warning. (Warnings are >= 1500)

Your project is likely treating this warning as an error.

Add <NoWarn>NU1605</NoWarn> to resolve this, or remove NU1605 from WarningsAsErrors

[sanderaernouts]

You are completely correct and NuGet emits NU1605 as a warning. (Warnings are >= 1500)

If that is the case then why does NuGet emit a package downgrade warning? If NewtonSoft.Json 9.01 is the lowest possible version that satisfies all constraints in the dependency tree and this version is resolved this way by NuGet. Then 8.01 -> 9.01 is not a downgrade for project B.

Add NU1605 to resolve this, or remove NU1605 from WarningsAsErrors

Adding <NoWarn>NU1605</NoWarn> makes the error go away but this is not a solution for the problem if it means adding this to every project I create. I created a new empty solution and added 3 dotnet core class library projects after that I added the dependencies as described in the steps to reproduce and the error occurs. I have update the steps to reproduce to include the creation of a new, empty solution and adding 3 new class library projects to it.

I did not change anything else, however in the project's properties I do see this:

This apparently is the default value when you create a new project. Which, if I understand you correctly, is wrong.

[emgarten]

If NewtonSoft.Json 9.01 is the lowest possible version that satisfies all constraints in the dependency tree and this version is resolved this way by NuGet. Then 8.01 -> 9.01 is not a downgrade for project B.

The warning is for NuGet.Packaging which may depend on APIs in 9.0.1, but it is instead going to use 8.0.1 at runtime.

[sanderaernouts]

Project B is asking for >=8.0.1 and NuGet.Packaging is asking for >=9.0.1 so 9.01 is the possible lowest version that satisfies both >=8.0.1 and >=9.0.1. Why will 8.0.1 be used at runtime then? If B was asking for [8.0.1] then I would expect an error, not a warning.

If NuGet picks 8.0.1 over 9.0.1 it makes sense that this is treated as an error. If NuGet.Packaging was compatible with 8.0.1 it would have a dependency on >= 8.0.1 instead of >=9.0.1.

In that case I am still unable to resolve this warning/error by updating project B to take a dependency on >=9.0.1 because the update commands fails on restore with this warning that is treated as an error by default.

[emgarten]

@sanderaernouts you can find out more on how the resolver works here: https://docs.microsoft.com/en-us/nuget/consume-packages/dependency-resolution

[sanderaernouts]

@emgarten I am aware of how the resolver works. But I ran into the NU1605 error again last week.

As you said:

You are completely correct and NuGet emits NU1605 as a warning. (Warnings are >= 1500)

Apparently behavior when create a new project is to threat NU1605 as an error. Which, if I understand you correctly, is wrong.

[clittell]

From the link:

When the package graph for an application contains different versions of the same package, NuGet chooses the package that's closest to the application in the graph and ignores all others.

You're getting 8.01. Dependency resolution is breadth first, so the first one encountered wins.

[dotnetKyle]

I just had this issue again with Visual Studio 15.8.5 & Nuget version: 4.8.1.5435.
I removed NU1605 from "Treat warnings as errors" but I had to close and re-open visual studio for it to take actually effect.

[nathanchere]

Clearing out the local packages and restoring has worked around a significant number of these for me.

[yairush88]

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

Package References:
Package A
Package B

Project References:
Package C
Package A

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