NuGet is restoring packages from feeds that are not configured

[stevendarby]

NuGet Product Used

MSBuild.exe

Product Version

.NET SDK:
Version: 10.0.301
Commit: 96856fd726
Workload version: 10.0.300-manifests.8c7d7c03
MSBuild version: 18.6.4+96856fd72

Runtime Environment:
OS Name: Windows
OS Version: 10.0.26100
OS Platform: Windows
RID: win-x64
Base Path: C:\Program Files\dotnet\sdk\10.0.301\

Worked before?

No response

Impact

It's more difficult to complete my work

Repro Steps & Context

1. Create two nuget feeds, e.g. in Azure DevOps, named something like MyFeedA and MyFeedB
2. Publish MyPackage 1.0.0 to MyFeedA
3. Publish MyPackage 1.1.0 to MyFeedB (note: same name, different version, different feed)
4. Create a new solution with ProjectA and a directory nuget.config which clears existing package sources and only pulls from MyFeedA.
5. Add a reference to MyPackage 1.0.0 in ProjectA. Build in VS.
6. Separate directory: create a new solution with ProjectB and a directory nuget.config which clears existing package sources and only pulls from MyFeedB.
7. Add a reference to MyPackage 1.1.0 in ProjectB. Build in VS.
8. Return to ProjectA and update the version to 1.0.1. (note: this version doesn't exist, it's a way to trigger the particular error message through which I discovered this bug). Build in VS.

warning NU1603: ProjectA depends on MyPackage (>= 1.0.1) but MyPackage 1.0.1 was not found. MyPackage 1.1.0 was resolved instead.

The bug here is that it's resolved a package from a feed that it shouldn't consider or even be aware of. I'm wondering if the fundamental issue here is that locally cached nuget packages are not properly sorted/isolated by the feed?

Verbose Logs

[Nigusu-Allehu]

Thanks for the detailed repro.

One likely explanation is that MyPackage 1.1.0 was downloaded during your earlier restore (for the other solution+feed), and then the later restore reused that same version from the machine’s Global Packages Folder (GPF).

Could you please confirm whether MyPackage 1.1.0 already exists in your machine’s GPF?
If it is present there, NuGet may satisfy restore from the GPF.

Also, a quick clarification: <clear /> under packageSources only clears configured source entries for that property.

[stevendarby]

I will confirm tomorrow but unless I've misunderstood you, that's exactly what I think the bug is. I don't think it should be able to do that; locally the cached feed packages should be separated by the feed id too.

And yep, clear is at the top of the package sources for both configs.

[stevendarby]

@Nigusu-Allehu any response? Problem is precisely when I have the packages cached locally.

[Nigusu-Allehu]

There are multiple layers of caching. The global packages folder is where installed packages are stored. It allows better performance as you can imagine. FYI, you can override the folder path using NUGET_PACKAGES env variable..

Thinking about your proposal to have the GPF segregated by sources. We would have to come up with a rule that says: If a package PackageA@Version is downloaded from Source1, only restores that configure Source1 can use the package. With that rule in place there is a couple of things we would have to think about

• If I am using PackageA@Version in a different project but my project configures source2 not source1, I can't use the local package now because of the above rule. I would have to make an http request and download the package again. That is inefficient.
• If there are n number of package sources that contain a package PackageA, we would have to download and store PackageA in the GPF n times. That is storage inefficient.