Granular control for package updates in RestoreLockedMode (selective updates)

[Grastveit]

NuGet Product(s) Involved

dotnet.exe

The Elevator Pitch

We are requesting refined command-line features for dotnet restore to allow highly granular updates to the dependency graph while primarily remaining in RestoreLockedMode.

Scenario

We utilize RestoreLockedMode for deterministic builds. We rely on a committed packages.lock.json file. We need mechanisms to handle two distinct update scenarios efficiently:

• Scenario A (Internal Packages): Update the resolved version of an internal floating package without changing the .csproj file.
• Scenario B (3rd-Party Packages): Update the pinned version of an external package in the .csproj file and the corresponding lock file entry, without affecting the pinned versions of other internal packages.

Problem

The current tools only offer an "all or nothing" approach (dotnet restore for nothing, dotnet restore --force-evaluate for everything). It is impossible to achieve Scenario B reliably: changing the .csproj intent and running a restore immediately causes a full re-evaluation of the internal dependencies, potentially pulling unintended newer versions into the lock file.

Our current manual workarounds are complex, error-prone, and involve converting all dependencies to pinned versions in the .csproj files to gain manual control, a process that fundamentally alters our intended dependency management strategy.

Desired Behavior

We would like command-line arguments that enable selective updates while preserving the locked state of all other packages.

A potential syntax could look like this:

# Update a single package to latest compatible version, keeping all others locked
dotnet restore --update-package <PackageName> [--version 1.2.3]

# Perform a restore that respects the .csproj changes for ONE package only, keeping others locked
dotnet restore --selective-update <PackageName> 

These commands would provide the necessary granularity to manage updates safely and efficiently in environments that rely heavily on the integrity of the packages.lock.json file.

Additional Context and Details

No response