nuget: bring NuGet lock file support to parity with npm (parse lockedVersion from packages.lock.json + update-lockfile behavior)

[florianwakam]

Hi 👋 — this is a feature idea, not a bug. I've verified the behavior in the current source (renovate 43.212.4) and via a self-hosted dry run. Framing it as a parity request with the npm manager.

What I'd like Renovate to do

For .NET projects that enable NuGet lock files (<RestorePackagesWithLockFile>true</RestorePackagesWithLockFile>, producing packages.lock.json next to each .csproj), I'd like Renovate to be able to propose lock-file-only updates for transitive / minor-patch dependencies — i.e. regenerate packages.lock.json when a transitive dependency can move within the declared version range, without requiring lockFileMaintenance to be enabled.

The npm manager already does exactly this: it parses lockedVersion from package-lock.json and returns the update-lockfile range strategy, so Renovate proposes lock-file updates and runs npm install to regenerate the lock file as a side effect — even when package.json doesn't change.

Current NuGet behavior

NuGet bare versions (e.g. 8.6.1 in Directory.Packages.props / .csproj) are ranges ([8.6.1, 9.0.0) per NuGet semantics). Renovate resolves currentVersion to the highest version satisfying the range (e.g. 8.7.0), concludes the package is already up to date, and proposes no update. As a result the artifacts regen path is never reached via the normal update path:

lib/modules/manager/nuget/artifacts.ts:

if (updatedDeps.length === 0 && config.isLockFileMaintenance !== true) {
  logger.debug(`Not updating lock file because no deps changed and no lock file maintenance.`);
  return null;
}

So dotnet restore --force-evaluate only runs when a version bump is proposed, or when lockFileMaintenance is enabled.

Why NuGet differs from npm today

• nuget/index.ts: supportsLockFileMaintenance = true, lockFileNames = ['packages.lock.json'] ✅ (maintenance works)
• nuget/extract.ts (~L240): the lock file is only recorded (res.lockFiles = [lockFileName]) — it is never parsed for a lockedVersion. There is no NuGet equivalent of npm's getLockedVersions() (npm/extract/post/locked-versions.ts).
• NuGet has no update-lockfile range strategy (npm returns 'update-lockfile' from npm/range.ts:28).

Workaround (works today)

Enable lockFileMaintenance globally — it triggers dotnet restore --force-evaluate unconditionally on a dedicated renovate/<parentDir>-lock-file-maintenance branch. I verified this works end-to-end in a self-hosted dry run (including with additionalBranchPrefix: "{{parentDir}}-" folder splitting — the maintenance branch was correctly prefixed, and dotnet restore --force-evaluate ran on all projects). So lockFileMaintenance is a valid supported workaround today; this request is about closing the parity gap with npm.

Suggested enhancement

Bring NuGet to parity with npm:

1. Parse lockedVersion (and the resolved transitive graph) from packages.lock.json during extraction — a NuGet equivalent of getLockedVersions.
2. Add an update-lockfile-style behavior: when the declared version range is already satisfied but a newer compatible transitive version exists, propose a lock-file-only update so updateArtifacts runs dotnet restore --force-evaluate and regenerates packages.lock.json.

Happy to provide a minimal public reproduction repo if that helps. Thanks!