Respect package update version ranges

[Saibamen]

Summary

Fixes the version-range update behavior tracked in NuGet/Home#6566. When package update tooling evaluates an installed PackageReference or central PackageVersion with an authored version range, NuGet now respects that range while selecting update candidates and preserves the authored constraint when writing the update back.

Previously, update flows could select versions outside an existing upper bound, or replace a bounded range such as [1.0.0, 2.0.0) with a fixed version after a successful in-range update. This made update behavior inconsistent across PM UI, Package Manager Console, and dotnet package update, and could silently discard constraints that users intentionally authored.

Fixes: NuGet/Home#6566

Behavior

Updates now preserve version-range intent when all are true:

• The installed package has an authored allowed version range.
• The requested or discovered update version satisfies that range.
• The update operation writes a new PackageReference or central PackageVersion value.

For upper-bounded ranges, NuGet updates the lower bound to the selected package version while keeping the original upper bound. Floating ranges are preserved as authored. Explicit update requests outside an authored floating or upper-bounded range are rejected or skipped instead of producing an out-of-range install action. Fixed PackageReference versions are treated as normal installed versions, not authored update constraints, so explicit downgrade operations continue to work.

Implementation

The change carries the installed VersionRange through package update action creation in NuGetPackageManager so PM UI and Package Manager Console flows can reject out-of-range explicit updates and preserve allowed ranges for in-range updates.

For dotnet package update, latest-version resolution now accepts an optional allowed range and filters package source results before selecting the highest candidate. The command runner also reads central package version ranges when Central Package Management is enabled, so CPM updates follow the same range-preserving behavior as project-local PackageReference updates.

Test plan

• dotnet test test\NuGet.Core.Tests\NuGet.CommandLine.Xplat.Tests\NuGet.CommandLine.Xplat.Tests.csproj --filter FullyQualifiedName~GetPackageToUpdateTests --no-restore
• dotnet test test\NuGet.Core.Tests\NuGet.PackageManagement.Test\NuGet.PackageManagement.Test.csproj --filter FullyQualifiedName~BuildIntegratedTests --no-restore
• dotnet test test\NuGet.Core.FuncTests\NuGet.XPlat.FuncTest\NuGet.XPlat.FuncTest.csproj --filter FullyQualifiedName~GetLatestVersionAsyncTests --no-build
• dotnet format whitespace --verify-no-changes NuGet.sln

Notes / follow-ups

• The functional test path that writes project files depends on local .NET SDK discovery in this environment; the targeted source-filtering functional tests were validated separately.
• The range-preserving write path intentionally keeps the existing upper bound instead of widening user-authored constraints during update.

[voroninp]

Does it allow upgrading with the version out of the range but with the saved intent?

For example: [8.*, 9) -> [9.*, 10) ?

[Saibamen]

@voroninp: No

[Saibamen]

.

[martinrrm]

@Saibamen Thanks for creating this PR, this is a good change for the Package Manager UI and solves some of the pains listed in the original issue. But I don't think this PR fixes it completely so we will need to create a new issue, so we don't close the original.

Also, this is a change in design, so we need to have a design spec for this and have a review with the team. I assigned this to myself and will work on a spec next week so we can all review it.

[dotnet-policy-service]

This PR has been automatically marked as stale because it has no activity for 7 days. It will be closed if no further activity occurs within another 30 days of this comment. If it is closed, you may reopen it anytime when you're ready again, as long as you don't delete the branch.