Swap Nerdbank.GitVersioning for native versioning

[rdeago]

Part of #296 (Phase 7 of #267); the issue stays open until the post-publish tail lands.

This is the atomic swap: the version source flips from Nerdbank.GitVersioning to Buildvana's native versioning in one change, with no PR state carrying two active versioning systems.

• SDK: new Versioning module, auto-detected by a repository-root VERSION file, computing Version/PackageVersion/AssemblyVersion/FileVersion/InformationalVersion via a new ComputeVersion task that runs VersioningService in-process (LibGit2Sharp height — no git CLI). Results are cached per home directory in the task host, keyed on repository state. UseNerdbankGitVersioning remains as a warned alias of UseVersioning (BVSDK2001); the GetBuildVersion target name is preserved.
• ThisAssembly: versioned C# projects generate ThisAssembly by default, now carrying SimpleVersion, SemVer, IsPublicRelease, IsPrerelease, and GitCommitId alongside the Phase 6 defaults (differences vs NBGV's class are noted in the changelog).
• Packaging: LibGit2Sharp's managed + native assets ship in the SDK package bin/; Unix natives are renamed (lib prefix stripped) to match LibGit2Sharp's composed probe name, and a one-time bootstrap points it at runtimes/{rid}/native. Spike-verified from the packed layout under dotnet build; msbuild.exe uses the same .NET task host (verification on the dev machine blocked by an SDK/VS version pairing that equally affects all existing tasks).
• Tool: bv release computes versions natively; the nbgv subprocess and the tool's own versioning types are gone. Release policy (consistency checks, bump computation) lives in a thin VersionService over the library.
• Self-host transition: root VERSION + buildvana.json added; version.json and the nbgv tool entry are retained until the new SDK is published (post-publish tail: roll pins, delete version.json/nbgv, update CI comments and the .vscode schema mapping).
• Also: new Buildvana.Core.Testing shared test-harness library, and a false-positive ReSharper inspection suppressed in Buildvana.Core.JsonSchema.

Verified: 141 tests (36 new), dotnet bv pack self-hosts end to end, ReSharper inspectcode clean.

🤖 Generated with Claude Code

[rdeago]

@claude please review this PR.

[claude]

Claude finished @rdeago's task in 5m 36s —— View job

---

Claude's review

• Gather context (PR description, changed files, repo rules)
• Read diff against origin/main
• Review SDK versioning module changes
• Review Buildvana.Core.Versioning changes
• Review Buildvana.Sdk.Tasks (ComputeVersion task + caching)
• Review Buildvana.Tool versioning/release changes
• Review packaging (LibGit2Sharp native assets)
• Review tests
• Post final review

Overall this is a clean, well-scoped swap. The design holds together: VersionFile / VersionSpecExtensions in Buildvana.Core.Versioning are shared by both the SDK task and bv release, the GetBuildVersion target name and UseNerdbankGitVersioning alias preserve compatibility, and the per-home-directory task-host cache (keyed on a HEAD-ref+SHA token plus VERSION/buildvana.json(c) contents) looks correct — it only skips caching (never serves stale data) when the fingerprint can't be computed. Test coverage for the new pieces (VersionFile, VersionSpecChange, ComputeVersion incl. cache-hit/invalidation) is solid.

A few things worth a look, roughly in priority order:

1. Stale comment referencing Nerdbank.GitVersioning — src/Buildvana.Tool/Subcommands/ReleaseCommand.cs:182-184:

// Ensure that the release tag doesn't already exist.
// This assumes that full repo history has been checked out;
// however, that is already a prerequisite for using Nerdbank.GitVersioning.

This file's imports were already updated for the swap (Buildvana.Core.Json → Buildvana.Core.Versioning), but the comment still describes NBGV as the current dependency needing full history. Minor, but worth fixing since it's misleading in a PR whose whole point is removing that dependency.
Fix this →

2. Case-insensitive cache key on case-sensitive filesystems — src/Buildvana.Sdk.Tasks/Tasks/ComputeVersion-caching.cs:17:

private static readonly ConcurrentDictionary<string, CachedVersion> Cache = new(StringComparer.OrdinalIgnoreCase);

The per-task-host cache is keyed by the full home directory path with OrdinalIgnoreCase. On a case-sensitive filesystem (Linux/macOS), two genuinely distinct home directories differing only by case would collide and could serve one repo's cached version data for another. It's an unlikely scenario in practice (repo paths rarely differ only by case), but worth a second look — is this deliberate for cross-platform path normalization, or should it be Ordinal (or platform-conditional)?

3. Design question — versioning constants gated by EnableDefaultThisAssemblyConstants — src/Buildvana.Sdk/Modules/Versioning/Module.Core.targets:53:

<Target Name="BV_DefineVersioningThisAssemblyConstants"
        BeforeTargets="BV_WriteThisAssemblyConstantsFile"
        DependsOnTargets="GetBuildVersion"
        Condition="'$(EnableDefaultThisAssemblyConstants)' != 'false'">

EnableDefaultThisAssemblyConstants is owned by the ThisAssemblyClass module and gates its own bucket (AssemblyVersion, AssemblyProduct, AssemblyCompany, etc. — see Modules/ThisAssemblyClass/Module.Core.targets:44). Reusing it here means setting it to false also suppresses SimpleVersion/SemVer/IsPublicRelease/IsPrerelease/GitCommitId, which are a different, versioning-specific set of constants. If that's meant as "one switch to disable all built-in constants," fine — just flagging the cross-module coupling in case it's accidental reuse rather than a deliberate single opt-out.

Nits (no action needed unless you want them): RuntimeInformation.RuntimeIdentifier in GitHeightCalculator-nativeLibrary.cs relies on the portable RID reporting introduced in modern .NET, which matches the runtimes/{rid}/native layout you're packaging — just noting the assumption since the PR description says on-device MSBuild.exe verification was blocked. The catch (LibGit2SharpException) around GlobalSettings.NativeLibraryPath matches LibGit2Sharp's actual behavior (the setter throws only once the native library is already resolved/locked, and doesn't validate the path itself), so that fallback is safe as written.

No correctness issues found in the version computation logic itself (VersionFile, VersionSpecExtensions, VersioningService.FileVersion), the MSBuild module wiring (UseVersioning/UseNerdbankGitVersioning coalescing order, BVSDK2000/BVSDK2001 diagnostics), or the LibGit2Sharp native-asset repackaging (lib prefix stripping for Unix .so/.dylib).

[rdeago]

@claude Thanks for the review. Both actionable points are addressed:

1. The stale Nerdbank.GitVersioning comment in ReleaseCommand.cs now attributes the full-history requirement to the native Git height computation (b3609e9).
2. The ComputeVersion cache is now keyed with StringComparer.Ordinal (c551990). Note that the fingerprint check already prevented stale data from ever being served — a case-collision could only cause the two directories to thrash a shared cache slot — but ordinal keying removes even that.

Point 3 is as intended: EnableDefaultThisAssemblyConstants is deliberately a single switch that turns off all Buildvana-provided constants, versioning ones included.

Please take another look.

[claude]

Claude finished @rdeago's task in 1m 9s —— View job

---

Claude's review (follow-up)

• Read trigger comment and identify the three points to re-check
• Verify fix for stale NBGV comment (b3609e9)
• Verify fix for cache key comparer (c551990)
• Confirm point 3 design rationale
• Post final review

Both fixes check out, and the third point's rationale is sound.

1. Stale comment (b3609e9) — src/Buildvana.Tool/Subcommands/ReleaseCommand.cs:182. The comment now correctly attributes the full-history requirement to native Git height computation instead of NBGV. Confirmed there's no other stray NBGV/Nerdbank reference left in source comments or targets — the remaining hits (Module.Core.targets, BeforeModules.targets, GitHeightCalculator.cs) are all intentional: the GetBuildVersion compatibility-name note, the UseNerdbankGitVersioning deprecated-alias documentation, and the height-algorithm attribution comment. Everything outside src/ (version.json, .config/dotnet-tools.json, CI workflow comments, .vscode/settings.json) is explicitly called out in the PR description as the post-publish tail, so untouched by design.

2. Cache comparer (c551990) — src/Buildvana.Sdk.Tasks/Tasks/ComputeVersion-caching.cs:17 now uses StringComparer.Ordinal. I re-read ComputeFingerprint/GetOrComputeVersion: the fingerprint (repo state token + VERSION/buildvana.json(c) contents) is checked on every lookup before a cached entry is returned, so the agreement in the commit message is accurate — case-insensitive keying could only have caused two distinct directories to thrash a shared slot, never serve stale data. Ordinal keying removes that possibility entirely. Good fix.

3. EnableDefaultThisAssemblyConstants reuse — acknowledged as intentional (single opt-out switch for all Buildvana-provided constants). No further action needed; makes sense as a deliberate design choice.

No new issues found. This PR looks good to merge from my side.