Pin .NET SDK (global.json) + central package management + align EF Core majors

[Chris0Jeky]

Summary

Closes #1127

• Pin .NET SDK: Add backend/global.json pinning SDK to 8.0.415 with rollForward: latestPatch so all contributors and CI use a consistent .NET 8.0.x SDK
• Central Package Management: Add backend/Directory.Packages.props with ManagePackageVersionsCentrally, moving all 38 NuGet version declarations out of 11 individual .csproj files into one central location
• Align mixed NuGet majors:
  • Microsoft.EntityFrameworkCore.Tools 10.0.8 → 8.0.27 (match EF Core 8.x family + net8.0 TFM)
  • Npgsql.EntityFrameworkCore.PostgreSQL 9.0.4 → 8.0.11 (match EF Core 8.x family)

Files changed

File	Change
backend/global.json	New — SDK pin
backend/Directory.Packages.props	New — CPM central version file
5 src .csproj files	Remove Version= from PackageReference
6 test .csproj files	Remove Version= from PackageReference

Test plan

• dotnet restore backend/Taskdeck.sln — all 11 projects restore cleanly
• dotnet build backend/Taskdeck.sln -c Release — 0 errors (11 pre-existing warnings unchanged)
• dotnet test --filter "FullyQualifiedName~FirstRunBootstrapper" — 11 tests pass
• CI green on ci-required.yml
• Verify no .csproj retains a Version= attribute on any PackageReference

[gemini-code-assist]

Code Review

This pull request introduces Central Package Management (CPM) for the backend solution by adding a central Directory.Packages.props file and a global.json SDK configuration, while removing explicit version attributes from package references across all project files. The review feedback recommends aligning the versions of Microsoft.AspNetCore.SignalR.Client and several Microsoft.Extensions.* packages to the 8.0.x family to match the net8.0 target framework and prevent potential major version mismatches.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The PR description mentions aligning mixed NuGet majors to match the EF Core 8.x family and the net8.0 TFM (e.g., changing Microsoft.EntityFrameworkCore.Tools from 10.0.8 to 8.0.27). However, Microsoft.AspNetCore.SignalR.Client is still set to 10.0.8.\n\nThis should be aligned to the 8.0.x family (specifically 8.0.27 to match the other ASP.NET Core packages in this file) to prevent major version mismatches and ensure compatibility with the net8.0 target framework.

    <PackageVersion Include="Microsoft.AspNetCore.SignalR.Client" Version="8.0.27" />

[gemini-code-assist]

Similar to the EF Core alignment, these Microsoft.Extensions.* packages are currently pinned to major version 10.0.8.\n\nSince the project targets net8.0, these should be aligned to the 8.0.x family (e.g., 8.0.8) to avoid major version mismatches and potential runtime compatibility issues.

    <PackageVersion Include="Microsoft.Extensions.Hosting" Version="8.0.8" />\n    <PackageVersion Include="Microsoft.Extensions.Http.Polly" Version="8.0.8" />\n    <PackageVersion Include="Microsoft.Extensions.Logging.Abstractions" Version="8.0.8" />

[Chris0Jeky]

Adversarial Self-Review Findings

CRITICAL

F1: Dockerfile.production Docker build will fail — Dockerfile.production copies individual .csproj files before dotnet restore for layer caching, but does NOT copy Directory.Packages.props or global.json. Since .csproj files no longer contain version attributes, dotnet restore will fail with "version not specified" errors.

• Fix: Add COPY backend/global.json backend/ and COPY backend/Directory.Packages.props backend/ before the restore layer.

MEDIUM

F2: NuGet cache key in release-desktop.yml won't invalidate on version changes — The cache-dependency-path in release-desktop.yml hashes backend/**/*.csproj for the NuGet cache key. Now that versions live in Directory.Packages.props, changing a package version won't bust the cache, potentially causing stale package restores.

• Fix: Add backend/Directory.Packages.props to cache-dependency-path.

LOW

F3: Historical migration snapshots retain ProductVersion 9.0.14 — Three older migration designer files (EfCore9SnapshotResync, AddTokenInvalidatedAt, AddChatMessageToolCallMetadata) still show "ProductVersion", "9.0.14". These are historical artifacts from when EF Core 9.x was briefly used and are not harmful (the current snapshot is 8.0.26), but they remain as minor noise. Out-of-scope for this PR.

Analysis: No issues found

• All 38 packages correctly centralized in Directory.Packages.props
• No residual Version= attributes in any .csproj file
• global.json correctly pins 8.0.415 with latestPatch roll-forward
• backend.Dockerfile uses COPY backend/ ./backend/ (bulk copy) so it picks up both new files
• CI workflows use dotnet-version: 8.0.x which is compatible with the global.json pin
• EF Core Tools correctly aligned from 10.0.8 to 8.0.27
• Npgsql EF Core PostgreSQL correctly aligned from 9.0.4 to 8.0.11

[Chris0Jeky]

Fix Evidence (post-review)

All findings from adversarial self-review and Gemini Code Assist review have been addressed:

Finding	Severity	Fix commit	Verification
F1: Dockerfile.production missing CPM files	CRITICAL	ccac4d4	COPY backend/global.json and COPY backend/Directory.Packages.props added before restore layer
F2: release-desktop.yml NuGet cache key stale	MEDIUM	ccac4d4	backend/Directory.Packages.props added to cache-dependency-path
F4 (Gemini): SignalR.Client 10.0.8 misaligned	MEDIUM	83a8c7d	Downgraded to 8.0.27
F5 (Gemini): Extensions.* 10.0.8 misaligned	MEDIUM	83a8c7d	Hosting -> 8.0.1, Http.Polly -> 8.0.27, Logging.Abstractions -> 8.0.3
F3: Historical migration ProductVersion 9.0.14	LOW	Out-of-scope	Pre-existing artifacts, current snapshot is 8.0.26

Post-fix verification:

• dotnet restore backend/Taskdeck.sln -- all 11 projects restore cleanly
• dotnet build backend/Taskdeck.sln -c Release -- 0 errors, 11 pre-existing warnings
• dotnet test --filter "FullyQualifiedName~FirstRunBootstrapper" -- 11/11 pass
• grep PackageReference.*Version= backend/**/*.csproj -- 0 matches (no residual versions)

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7aa17a9a1d

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Move global.json to the checkout root

When CI or the documented local commands run from the repository root, this backend/global.json is not seen by the .NET CLI muxer; Microsoft documents that dotnet starts global.json lookup at the current working directory and walks upward, not down into the solution directory (https://learn.microsoft.com/en-us/dotnet/core/tools/global-json). I checked .github/workflows/reusable-backend-solution.yml and .github/workflows/ci-release.yml, which run dotnet restore/build/test backend/Taskdeck.sln from the checkout root, so the main restore/build/test path still uses whichever SDK setup-dotnet installed as 8.0.x instead of this pin. Put the file at the repo root or change those commands to run with working-directory: backend so the SDK pin actually protects CI and contributors.

Useful? React with 👍 / 👎.

[Chris0Jeky]

2nd-Pass Review Fix Evidence

PR1196-1 (CRITICAL — 20 CI workflows missing cache key): Fixed in 99a2983a

Added backend/Directory.Packages.props to cache-dependency-path in all 20 workflows that hash .csproj files for NuGet cache keys.

PR1196-2 (IMPORTANT — global.json invisible to root-level commands): Fixed in 99a2983a

Moved global.json from backend/ to repo root so it's visible to dotnet commands run from the checkout root (CI + local dev). Updated Dockerfile.production COPY path accordingly.

PR1196-3 (IMPORTANT — unaddressed Codex bot comment): Addressed — the global.json placement fix resolves the Codex bot's concern.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 99a2983aec

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Copy the SDK pin into the compose backend image

This only updates deploy/Dockerfile.production to copy global.json, but the baseline container path still builds deploy/docker/backend.Dockerfile (checked deploy/docker-compose.yml:25-27, .github/workflows/reusable-container-images.yml:20-21, and docs/TESTING_GUIDE.md:1268-1270). That Dockerfile copies only backend/ before dotnet restore, so the new root global.json is absent from /src and compose/local/container CI builds continue using whatever SDK is in mcr.microsoft.com/dotnet/sdk:8.0 instead of the pinned SDK. Please copy global.json in the compose backend Dockerfile as well, or place the pin where that build already copies it.

Useful? React with 👍 / 👎.