Version stamps derive from <Version> — 3.4.0 shipped binaries stamped 3.3.0.0

[erikdarlingdata]

Closes #2113.

What

SalmanRajwani's report verified straight from the tags: git show v3.4.0:Lite/PerformanceMonitorLite.csproj has <Version>3.4.0</Version> over <AssemblyVersion>3.3.0.0</AssemblyVersion> / <FileVersion>3.3.0.0</FileVersion> / <InformationalVersion>3.3.0</InformationalVersion> — and the Darling Service and Viewer csprojs carry the same stale pins. Every prior release (checked back to 3.2.0) moved all four together; the 3.4.0 bump commit touched only <Version>. Package metadata comes from <Version>, binary stamps from the pins — hence "3.4.0 package installs binaries stamped 3.3.0." The installed code is genuinely 3.4.0; only the stamps lie.

How

Delete the three pinned properties in the three live app projects and let MSBuild derive them from <Version> (AssemblyVersion/FileVersion → 3.4.0.0, InformationalVersion → 3.4.0), with IncludeSourceRevisionInInformationalVersion=false so the informational version doesn't grow a +sha suffix under CI SourceLink. A release bump is now one <Version> line per project, and this class of skew can't recur. Deprecated projects left untouched.

🤖 Generated with Claude Code

[claude]

Reviewed. This is a .csproj/CI change, not T-SQL, so the style guide doesn't directly apply — checked instead for correctness and Lite/Darling parity.

Correctness: Deleting the three hand-pinned properties and letting the .NET SDK derive AssemblyVersion/FileVersion/InformationalVersion from <Version> is standard, well-documented SDK-style project behavior (GenerateAssemblyInfo/GenerateAssemblyVersionInfo targets) — no custom logic to get wrong. IncludeSourceRevisionInInformationalVersion=false correctly suppresses the +sha suffix that CI SourceLink would otherwise append.

Worth noting: this bug wasn't just cosmetic. PerformanceMonitor.Common/Services/UpdateCheckService.cs reads Assembly.GetEntryAssembly().GetName().Version (i.e. AssemblyVersion) and compares it against the latest GitHub release tag to decide whether to nag the user to update. With the stale 3.3.0.0 pin, a user who'd already updated to 3.4.0 would still see "update available" forever. This fix resolves that too, not just the file-properties display.

Parity: All three live app projects (Lite, Darling Service, Darling Viewer) get identical treatment — no drift between SKUs. Deprecated projects correctly left alone per the stated scope.

Minor, non-blocking observation: the same IncludeSourceRevisionInInformationalVersion=false + comment block is now hand-duplicated verbatim across all three csproj files — a Directory.Build.props at the repo root could centralize it so this exact class of drift (the one this PR just fixed for the version pins) can't recur for this property either. Not required for this fix; just an opportunity if you're touching this area again.

Nothing else stood out — no security, correctness, or parity concerns.

[claude]

Reviewed. This is a clean, minimal fix and I don't see correctness, parity, security, or performance issues.

• Technical claim checks out: since the .NET 8 SDK, the built-in git plumbing appends a +<sha> suffix to InformationalVersion by default when building from a repo with a discoverable .git folder — no explicit SourceLink package reference required. Setting IncludeSourceRevisionInInformationalVersion=false is the correct, documented way to suppress that suffix while still deriving from <Version>.
• UpdateCheckService.GetCurrentVersion() (PerformanceMonitor.Common/Services/UpdateCheckService.cs:93) reads Assembly.GetEntryAssembly()?.GetName().Version, which is exactly the AssemblyVersion attribute baked from the (previously stale) pin. The changelog's claim that a 3.4.0 install would perpetually see "update available" is verified against that code path — this is a real, understood bug, not a cosmetic one.
• Parity: verified via grep -rl "<Version>" --include=*.csproj . that the only live, versioned app projects in the repo are Lite/PerformanceMonitorLite.csproj, Darling/PerformanceMonitor.Darling.Service/*.csproj, and Darling/PerformanceMonitor.Darling.Viewer/*.csproj — all three got the identical treatment (delete the three hand-pins, add the one suppression property). Deprecated projects (deprecated/Dashboard, deprecated/Installer*) still carry their own pins and were correctly left untouched per the PR description.
• No build-script or CI workflow passes -p:AssemblyVersion/-p:FileVersion/-p:InformationalVersion on the command line that would bypass or conflict with this (checked build-all.cmd, build-lite.cmd, build-dashboard.cmd, package-release.cmd, .github/workflows/*.yml).
• AssemblyVersion/FileVersion will correctly pad 3.4.0 → 3.4.0.0 under the SDK's default derivation, matching the PR description.

Nothing blocking. Nice, well-isolated fix for a real release-stamping bug.