build: SDK patch drift breaks locked restore (NU1004); refresh the lock files #137

New Issue

2026-11-10T18:10:29Z

james.maes commented

2026-11-10 18:10:29 +00:00

Problem

A locked restore fails with NU1004 whenever the installed .NET SDK patch is newer than the one that wrote the lock files, and an unlocked restore rewrites gclo.Engine/packages.lock.json and gclo.ViewModels/packages.lock.json.

Cause: both projects set EnableSingleFileAnalyzer, which adds the implicit package Microsoft.NET.ILLink.Tasks at the SDK's bundled runtime version. global.json pins 10.0.401 with rollForward: latestFeature, so any newer 10.0.x SDK resolves a different version (10.0.12 in the lock files, 10.0.14 with SDK 10.0.403).

Related defects found in the same review:

.github/workflows/nuget-updates.yml commits **/*.csproj and lock files only, but the update script edits Directory.Packages.props, so the weekly pull request carries lock files without the version change and cannot pass a locked restore.
Directory.Build.props still has VersionPrefix 1.0.1 although v1.1.0 shipped.

Scope

Bump global.json to the current SDK and refresh every lock file.
Add Directory.Packages.props to the update workflow's add-paths.
Set VersionPrefix to the next expected release, 1.1.1.

rollForward stays latestFeature, as the KofTwentyTwo standard asks. The structural question (committed lock files cannot survive a floating SDK) goes to the standards repository.

Acceptance

dotnet build gclo.slnx -p:Platform=x64 -warnaserror -p:RestoreLockedMode=true passes with the SDK named in global.json.
Both test suites pass with the 100% coverage gate; dotnet format --verify-no-changes is clean.

## Problem A locked restore fails with NU1004 whenever the installed .NET SDK patch is newer than the one that wrote the lock files, and an unlocked restore rewrites `gclo.Engine/packages.lock.json` and `gclo.ViewModels/packages.lock.json`. Cause: both projects set `EnableSingleFileAnalyzer`, which adds the implicit package `Microsoft.NET.ILLink.Tasks` at the SDK's bundled runtime version. `global.json` pins `10.0.401` with `rollForward: latestFeature`, so any newer 10.0.x SDK resolves a different version (10.0.12 in the lock files, 10.0.14 with SDK 10.0.403). Related defects found in the same review: - `.github/workflows/nuget-updates.yml` commits `**/*.csproj` and lock files only, but the update script edits `Directory.Packages.props`, so the weekly pull request carries lock files without the version change and cannot pass a locked restore. - `Directory.Build.props` still has `VersionPrefix` 1.0.1 although v1.1.0 shipped. ## Scope - Bump `global.json` to the current SDK and refresh every lock file. - Add `Directory.Packages.props` to the update workflow's `add-paths`. - Set `VersionPrefix` to the next expected release, 1.1.1. `rollForward` stays `latestFeature`, as the KofTwentyTwo standard asks. The structural question (committed lock files cannot survive a floating SDK) goes to the standards repository. ## Acceptance - `dotnet build gclo.slnx -p:Platform=x64 -warnaserror -p:RestoreLockedMode=true` passes with the SDK named in `global.json`. - Both test suites pass with the 100% coverage gate; `dotnet format --verify-no-changes` is clean.

james.maes added the .NET quality labels 2026-11-10 18:10:29 +00:00

james.maes referenced this issue from a commit

2026-11-10 18:15:17 +00:00

build: pin the single-file analyzer package so lock files survive SDK patches

james.maes referenced a pull request that will close this issue

2026-11-10 18:15:18 +00:00

build: pin the single-file analyzer package so lock files survive SDK patches #138

james.maes referenced this issue from a commit

2026-11-10 18:15:51 +00:00

build: pin the single-file analyzer package so lock files survive SDK patches (#138)

james.maes closed this issue

2026-11-10 18:15:51 +00:00