Online sources are always checked even when local exists

[samcragg]

When specifying local and nuget.org as sources, nuget.org is always checked even when the package exists in a local folder. This is contradictory to the documentation.

Please find the attached sample solution (NugetTest.zip), and here's the output from the command prompt (running on Linux Mint 20, but have observed the same behaviour under Windows 10):

dotnet --version
3.1.404
dotnet restore ConsumerApp/ConsumerApp.csproj -v:n --no-cache --packages Packages
...
       Restore:
         Restoring packages for [...]ConsumerApp.csproj...
           GET https://api.nuget.org/v3-flatcontainer/localonlypackage/index.json
           NotFound https://api.nuget.org/v3-flatcontainer/localonlypackage/index.json 705ms
...
         Feeds used:
             [...]/PackageSources
             https://api.nuget.org/v3/index.json

To give some background, I want to be able to test my package before publishing it. As suggested by @nkolev92, I'm creating a separate issue from #3676 as he was quite confident the local feeds would be used before the online one, however, the above output shows a GET to nuget.org (adding nearly a second to my simple build 🙁)

[nkolev92]

Thanks for clarifying your scenario.

Here's my output:

Microsoft (R) Build Engine version 16.8.0+126527ff1 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
  LocalOnlyPackage -> C:\Users\Roki2\Downloads\NugetTest\NugetTest\LocalOnlyPackage\bin\Debug\netstandard2.0\LocalOnlyPackage.dll
  Successfully created package 'C:\Users\Roki2\Downloads\NugetTest\NugetTest\PackageSources\LocalOnlyPackage.1.0.0.nupkg'.
Build started 08-Dec-20 11:02:18 AM.
     1>Project "C:\Users\Roki2\Downloads\NugetTest\NugetTest\ConsumerApp\ConsumerApp.csproj" on node 1 (Restore target(s)).
     1>_GetAllRestoreProjectPathItems:
         Determining projects to restore...
       Restore:
         Restoring packages for C:\Users\Roki2\Downloads\NugetTest\NugetTest\ConsumerApp\ConsumerApp.csproj...
         Installing LocalOnlyPackage 1.0.0.
         Committing restore...
         Writing assets file to disk. Path: C:\Users\Roki2\Downloads\NugetTest\NugetTest\ConsumerApp\obj\project.assets.json
         Restored C:\Users\Roki2\Downloads\NugetTest\NugetTest\ConsumerApp\ConsumerApp.csproj (in 155 ms).

         NuGet Config files used:
             C:\Users\Roki2\AppData\Roaming\NuGet\NuGet.Config
             C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.FallbackLocation.config
             C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config

         Feeds used:
             C:\Users\Roki2\Downloads\NugetTest\NugetTest\PackageSources
             https://api.nuget.org/v3/index.json

         Installed:
             1 package(s) to C:\Users\Roki2\Downloads\NugetTest\NugetTest\ConsumerApp\ConsumerApp.csproj
     1>Done Building Project "C:\Users\Roki2\Downloads\NugetTest\NugetTest\ConsumerApp\ConsumerApp.csproj" (Restore target(s)).

Build succeeded.
    0 Warning(s)
    0 Error(s)

I made one small change. I provided a version in the consumer project.

Basically what happens is that because a version was not provided, NuGet searches for the lowest applicable version, and in order to be confident that the lowest version was selected, NuGet needs to contact all sources.

This is by design.
Created an issue to consider improving the docs, https://github.com/NuGet/docs.microsoft.com-nuget/issues/2226.

[samcragg]

Thanks @nkolev92 for your help and continued patience - it's really appreciated 🙂

Unfortunately, I can't specify the version, as it changes with each build. Worst, if the logic is that NuGet searches for the lowest version, then it will always pick the previously published version on nuget.org over the local package 😕

To recap, what I want is to be able to use a package that's been placed in a specific folder as part of the build in order to be able to verify that everything works with consuming it (the package has targets in it that hook in to the build process, so the integration tests verify that all of it hooks up correctly). I was hoping it should be a supported scenario (testing a package that is), but am yet to find a solution.

Since there are a few issues around this, is there a process to put together a proposal (similar to csharplang)? I don't mind rolling my sleeves up and taking a stab at getting things moving if there's anything I can do to help.

[nkolev92]

Hey @samcragg

I think the fact that NuGet supports specifying no version is in my personal opinion a restriction that is too relaxed.
One thing you can consider are floating versions where you specify a specific prerelease label and that label can be only be generated locally.

Beyond that, #6579 is probably where the problem of testing packages locally needs to be solved.

We do have a contribution process! We'd be happy to review your proposal.

See https://github.com/NuGet/NuGet.Client/blob/dev/CONTRIBUTING.md for code contributions and https://github.com/NuGet/NuGet.Client/blob/dev/docs/feature-guide.md#how-do-i-know-if-i-need-a-design-for-my-work for submitting a design for your proposed change!

[samcragg]

Thanks for the links. I've created a design document (#10386) to hopefully get some discussion going on whether it's something that's worthwile adding (there were quite a few issues around the same theme it turns out!)

[nkolev92]

Thanks @samcragg

We really appreciate you starting the conversation toward a solution.
I will try to review the doc and provide some feedback.

Please note that due to it being the end of the year, many stakeholders are on vacation already/will go on vacation soon, so it might take some time to get a proper turnaround!