Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

[Breaking change]: Restore will no longer search package versions from the global packages folder when choosing a higher version #55108

Copy link
Copy link

Description

@zivkan
Issue body actions

Description

When a PackageReference requests a version of a package that does not exist on any package source, it will search all sources for available versions and select the lowest version that is higher than the requested version, and raise a NU1603 warning. If no higher version is found then an NU1102 error is reported. Previously, NuGet would use the versions available in the global packages folder in it's "next best version" search, and it will no longer do so in .NET 11 RC1.

Note that if the global packages folder contains the exact version the project references, that version will be used, even if none of the package sources contains that version. This behavior is unchanged.

Version

.NET 11 RC 1

Previous behavior

Consider the following scenarios:

package source global packages requested version version selected restore outcome
1.0.0, 2.0.0 1.5.0 1.1.0 1.5.0 NU1604 warning
1.0.0 1.5.0 1.1.0 1.5.0 NU1604 warning

When the project's PackageReference version, or a package's dependency version, requests a version that NuGet can't find in any package source or the global packages folder, NuGet searched both package sources and the global packages folder, for the "next best" version (lowest version higher than requested).

New behavior

NuGet no longer includes the global packages folder in a "nest best" search. It only searches package sources.

package source global packages PackageReference version version selected restore outcome
1.0.0, 2.0.0 1.5.0 1.1.0 2.0.0 NU1604 warning
1.0.0 1.5.0 1.1.0 n/a NU1102 error

Note, if the global packages folder contains the exact requested version, restore will use that version, even if the version does not exist on package sources. This is unchanged from previous behavior.

Type of breaking change

  • Binary incompatible: Existing binaries might encounter a breaking change in behavior, such as failure to load or execute, and if so, require recompilation.
  • Source incompatible: When recompiled using the new SDK or component or to target the new runtime, existing source code might require source changes to compile successfully.
  • Behavioral change: Existing binaries might behave differently at run time.

Reason for change

NuGet becomes more deterministic/repeatable. NuGet doesn't validate exact version matches to speed up performance, but otherwise will now have the same behavior on different computers where the global packages folder may have different versions available.

Recommended action

Only reference package versions that exist on package sources, to ensure that the package version selected during restore does not change over time (when new versions are published to the package sources). Also follow best practices to secure your supply chain

Feature area

SDK

Affected APIs

No response

Reactions are currently unavailable

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions

Morty Proxy This is a proxified and sanitized view of the page, visit original site.