Home: When restoring with lock file, NU1603 warning shouldn't be raised.

[LordMike]

We're trying to adopt Locked package files in SDK 2.1.500, and were trying it out which revealed an issue. When we restore using --locked-mode (as if by CI), a lot of packages cannot be found, shown in messages like warning NU1603: System.Globalization 4.0.11 depends on Microsoft.NETCore.Platforms (>= 1.0.1) but Microsoft.NETCore.Platforms 1.0.1 was not found. An approximate best match of Microsoft.NETCore.Platforms 2.1.0 was resolved.

In this case, I would expect that the same warnings during a regular restore would be present during a --locked-mode restore -- in this case, a regular restore has no issues while a locked restore has "hundreds" of these.

We're also seeing errors

In our larger solution, we're seeing errors as well, such as the below. This may be related to the fact that we're using GitVersion, so maybe the version on a project changes after the lock file is created.. ?.. That's another issue though.

C:\Our-SDK\Evidence\ProjectA\ProjectA.csproj : error NU1004: The packages lock file is inconsistent with the project dependencies so restore can't be run in locked mode. Please disable RestoreLockedMode MSBuild property or pass explicit --force-evaluate flag to run restore to update the lock file. [C:\Our-SDK\Our-SDK.sln]

Details about Problem

NuGet product used (NuGet.exe | VS UI | Package Manager Console | dotnet.exe):
Dotnet.exe used for restore, new project, etc.

NuGet version (x.x.x.xxx): N/A

dotnet.exe --version (if appropriate): 2.1.500

OS version (i.e. win10 v1607 (14393.321)): Win10 10.0.17134

Worked before? If so, with which NuGet version: N/A -- new feature in 2.1.500

Detailed repro steps so we can see the same problem

1. Create new console project, dotnet new console
2. Add a few packages, dotnet add package Microsoft.EntityFrameworkCore
3. Restore and create locked file, dotnet restore --use-lock-file
4. Restore using locked mode, dotnet restore --locked-mode

Now you should see warnings like:

warning NU1603: NETStandard.Library 2.0.3 depends on Microsoft.NETCore.Platforms (>= 1.1.0) but Microsoft.NETCore.Platforms 1.1.0 was not found. An approximate best match of Microsoft.NETCore.Platforms 2.1.0 was resolved.

warning NU1603: System.Globalization 4.0.11 depends on Microsoft.NETCore.Targets (>= 1.0.1) but Microsoft.NETCore.Targets 1.0.1 was not found. An approximate best match of Microsoft.NETCore.Targets 2.1.0 was resolved.

Other suggested things

Verbose Logs

Please include verbose logs (NuGet.exe -verbosity detailed | dotnet.exe --verbosity diag | etc...)

dotnet restore --locked-mode --verbosity diag => dotnet.log

Sample Project

Very helpful if you can zip a project and paste into this issue!

bb.zip

[jainaashish]

This is interesting, thanks for pointing this out. Seems like first time there was one package which wanted Microsoft.NETCore.Platforms as 2.1.0 which is why it brought that version and didn't show any NU1603 warning. But with locked mode it just resolves to that specific version from lock file instead of doing any resolution which is why at later stage, it just raise these warnings.

We'll look into this.

[nkolev92]

I did some digging on NU1603 and related issues.
There are a lot of NU1603 related issues that have been filled.

https://github.com/NuGet/Home/issues/5764
Useful comment describing when NU1603 occurs
https://github.com/NuGet/Home/issues/5764#issuecomment-323613059

the important thing to ensure is that if all the resolutions are misses, a warning is raised for all of them similar to before.
https://github.com/NuGet/Home/issues/5633
https://github.com/NuGet/Home/issues/6014

Test the repro from:
https://github.com/NuGet/Home/issues/7625

Scenarios for which it'd be interesting to get a before and after, and lock vs no lock file. The number of warnings is also important.

Packages on feed:
B:1.0.1
A:1.0.0

= B 1.0.0

Scenarios:

• Install A.1.0.0 into a project.
• Install A 1.0.0 and B 1.0.1 into a project.

Packages on feed:
B 1.0.0
B:1.0.1
A:1.0.0

= B 1.0.0

Scenarios:

• Install A.1.0.0 into a project.
• Install A 1.0.0 and B 1.0.1 into a project.

Packages on feed:
B:1.0.1
A:1.0.0

= B 1.0.0
C:1.0.0
= B 1.0.0

Scenarios:

• Install C.1.0.0 and A.1.0.0 into a project.
• Install C.1.0.0 and A.1.0.0 and B 1.0.1 into a project.

Packages on feed:
B.2.0.0
A:1.0.0

= B 1.0.0
C:1.0.0
= B 2.0.0

Scenarios:

• Install C.1.0.0 and A.1.0.0 into a project.
• Install C.1.0.0 and A.1.0.0 and B 2.0.0 into a project.

[emgarten]

From discussing this with @jainaashish, I would say that NU1603 should be ignored or added to nowarn when running in locked mode.

The goal of NU1603 was to surface the cause of bad restore performance, and it has been successful in helping users fix their projects and notify package authors of broken dependencies.

Scenario:

• Restore a project
• Delete the http cache and assets file
• Restore the project again
• There should be zero http calls since all packages exist in the global source already

When the above scenario fails and http calls are made to find a package that is unintentionally floating due to a missing lower bound restore takes much longer to run.

NU1603 helps identify that it is a package or feed issue, and not a problem with NuGet restore itself. Finding that out is very difficult because only the flattened graph exists after restore, so users can't determine why restore decided to make a bunch of extra http calls even if they try.

When NU1603 was added it was found that some of the dotnet new templates had incorrectly authored packages and much of the restore time was caused by new projects going online to get packages that were assumed to be available in the offline installer.