Skip to content

chore: finish CPM, centralise build properties, restore SourceLink - #10

Merged
StuartMeeks merged 1 commit into
mainfrom
chore/adopt-standard-cpm
Aug 20, 2026
Merged

chore: finish CPM, centralise build properties, restore SourceLink#10
StuartMeeks merged 1 commit into
mainfrom
chore/adopt-standard-cpm

Conversation

@StuartMeeks

Copy link
Copy Markdown
Owner

What changed

PR C of the NextIteration.Standards adoption sequence (ADOPTING.md step 3). Closes the last four file clauses.

  • §1.3Directory.Packages.props gains CentralPackageVersionOverrideEnabled=false. This repo already had CPM with versionless PackageReferences, so this is the one-line completion rather than a migration. Without it MSBuild silently ignores a stray inline Version= and uses the central one — the exact drift the file exists to prevent.
  • §1.2 — the root Directory.Build.props is replaced with the canonical template, and every property each csproj restated is deleted from it. The src csproj now carries only PackageId, Version, Description, TargetFrameworks, tags, icon and its own URLs. Tests and demo set GenerateDocumentationFile=false to opt back out of the new default — sample and fixture code has no XML docs, and TreatWarningsAsErrors would fail the build over every missing one.
  • §1.8PackageOutputPath points at artifacts/packages instead of a hardcoded C:\nuget-local\ dev feed, and GeneratePackageOnBuild is scoped to Release. A local dev feed is a personal preference, not repo config; even guarded to Windows it made one machine's layout part of the build.
  • §1.7Microsoft.SourceLink.GitHub restored with PrivateAssets="All", at the estate-wide 10.0.400.

The §1.3 proof

Packed before and after from a clean obj/ at the same commit (873d8a7), so SourceLink cannot embed two different git SHAs and move the MVID for reasons unrelated to the change.

§1.2 + §1.3 + §1.8 alone — every entry in both packages is byte-identical:

Entry Result
NextIteration.SpectreConsole.Splash.nuspec same
README.md, icon.png, [Content_Types].xml same
lib/net8.0/*.dll, lib/net10.0/*.dll same
lib/net8.0/*.xml, lib/net10.0/*.xml same
lib/net8.0/*.pdb, lib/net10.0/*.pdb (snupkg) same
_rels/.rels, *.psmdcp differ — regenerated per pack

Adding §1.7's SourceLink reference on top is the only thing in this PR that changes a shipped byte:

  • .nuspec, README.md, icon.png and both XML doc files: still identical.
  • Each .pdb grows 48 bytes; each .dll changes 72 of 34304 bytes, first at offset 137 — the PE header's deterministic stamp. Consistent with the assembly's embedded PDB checksum moving, not with a code change.
  • The source-link document map itself is unchanged: one blob either way, same raw.githubusercontent.com URL, same commit SHA, no duplicate blob.

So the property/CPM migration is provably consumer-neutral, and the only package delta is the one §1.7 deliberately asks for.

A note on §1.7

This reference had been removed here as redundant, and that observation is correct as far as it goes — I verified it independently before touching anything: with no reference at all, SDK 10.0.111 still writes <repository … commit=…> into the nuspec and a full source-link document map into the PDB, because the SDK ships Microsoft.NET.Sdk.SourceLink.targets. The clause still wants the explicit reference, so that source linking is pinned to a version the estate controls rather than moving with whichever SDK feature band happens to build the package. Restored on that basis rather than because the removal was wrong about the mechanics.

CHANGELOG

The [Unreleased] "Removed Microsoft.SourceLink.GitHub" entry is deleted rather than contradicted — it never shipped, and leaving it beside its own reversal would be worse than either. The PackageOutputPath entry is rewritten, because §1.8 removes the dev feed outright rather than guarding it to Windows.

Verification

Local, at this commit: dotnet build --configuration Release0 warnings, 0 errors; dotnet test -- --coverage80 passed, 0 failed on both net8.0 and net10.0, coverage collected. No stray C:\ directory created anywhere in the tree.

Consumer impact

The .nuspec is byte-identical, so no dependency, floor, or metadata visible to NuGet changes. The shipped assembly and symbols shift by the 72/48 bytes described above, as a consequence of restoring the SourceLink reference. Step-through debugging and repository metadata worked before and work after.

Checklist

  • Build is clean — no new warnings (TreatWarningsAsErrors is on)
  • Tests pass on every shipped target framework
  • Public API changes carry XML docs — n/a, no API change
  • CHANGELOG.md updated under [Unreleased]
  • Dependency floors unchanged — proven by an identical .nuspec

🤖 Generated with Claude Code

PR C of the adoption sequence in ADOPTING.md. Closes the last four file
clauses: 1.2, 1.3, 1.7 and 1.8.

- 1.3: Directory.Packages.props gains CentralPackageVersionOverrideEnabled
  =false. This repo already had CPM with versionless PackageReferences, so this
  is the one-line completion rather than a migration. Without it MSBuild
  silently ignores a stray inline Version= and uses the central one, which is
  the exact drift the file exists to prevent.
- 1.2: root Directory.Build.props replaced with the canonical template, and the
  properties each csproj restated are deleted from it. The src csproj now
  carries only PackageId, Version, Description, TargetFrameworks, tags, icon
  and its own URLs. Tests and demo set GenerateDocumentationFile=false to opt
  back out of the new default -- sample and fixture code has no XML docs and
  TreatWarningsAsErrors would fail the build over every missing one.
- 1.8: PackageOutputPath now points at artifacts/packages instead of a
  hardcoded C:\nuget-local\ dev feed, and GeneratePackageOnBuild is scoped to
  Release. A local dev feed is a personal preference, not repo config; even
  guarded to Windows it made one machine's layout part of the build.
- 1.7: Microsoft.SourceLink.GitHub restored with PrivateAssets="All", at the
  estate-wide 10.0.400. It had been removed here as redundant, and that
  observation is correct as far as it goes -- see the proof below -- but the
  clause wants source linking pinned to a version the estate controls rather
  than moving with whichever SDK feature band happens to build.

The 1.3 proof, packed before and after from a clean obj/ at the same commit
(873d8a7) so SourceLink cannot embed two different git SHAs and move the MVID
for reasons unrelated to the change:

  1.2 + 1.3 + 1.8 alone, every entry in both packages:  BYTE-IDENTICAL
    nuspec, README.md, icon.png, [Content_Types].xml,
    lib/{net8.0,net10.0}/*.dll, *.xml, and both *.pdb -- all `same`.
    Only _rels/.rels and the .psmdcp differ, both regenerated per pack.

  adding 1.7's SourceLink reference on top:
    nuspec, README, icon, and both XML doc files: still identical.
    Each .pdb grows 48 bytes; each .dll changes 72 of 34304 bytes, first at
    offset 137 (the PE header's deterministic stamp) -- consistent with the
    assembly's embedded PDB checksum moving, not with a code change.
    The source-link document map itself is unchanged: one blob either way,
    same raw.githubusercontent.com URL, same commit SHA. No duplicate blob.

So the property/CPM migration is provably consumer-neutral, and the only
package delta in this PR is the one 1.7 deliberately asks for.

CHANGELOG: the [Unreleased] "Removed Microsoft.SourceLink.GitHub" entry is
deleted rather than contradicted -- it never shipped, and leaving it beside its
own reversal would be worse than either. The PackageOutputPath entry is
rewritten, because 1.8 removes the dev feed outright rather than guarding it.

Verified locally: Release build at zero warnings, 80 tests passing on both
net8.0 and net10.0 with coverage collected, and no stray C:\ directory created
anywhere in the tree.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@StuartMeeks
StuartMeeks merged commit 620b607 into main Aug 20, 2026
9 checks passed
@StuartMeeks
StuartMeeks deleted the chore/adopt-standard-cpm branch August 20, 2026 16:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant