Pin the SDK feature band so release builds can't roll onto an untested one

[HarryCordewener]

What broke

The v1.5 release build failed with:

CSC : error MAUIX2000: Cannot resolve type "clr-namespace:SharpClient.App.Components:Routes".
CSC : error MAUIG1001: An error occured while parsing Xaml: Type not found .

…on the exact commit whose CI run (Android head build, same dotnet build -c Release -f net10.0-android) had gone green 13 minutes earlier. No source change explains it.

Root cause

global.json used rollForward: latestFeature, so setup-dotnet takes whatever the newest 10.0.x feature band is at that moment:

run	18:10 CI (green)	18:23 release (failed)
SDK	10.0.302 (runner-preinstalled)	10.0.400 (just published)
workload set	10.0.302.1	none advertised yet → SDK baseline
maui manifest	10.0.20	10.0.0

The 10.0.400 band had no published workload set, so dotnet workload restore fell back to the SDK's baseline maui manifest — 10.0.0, older than what the 10.0.3xx band ships. That version's XAML source generator (we opt into MauiXamlInflator=SourceGen) can't resolve Routes, the Razor-generated root component referenced from MainPage.xaml.

So a release build silently changed toolchains between CI and packaging.

Fix

rollForward: latestPatch — accept 10.0.3xx patches, nothing higher. CI, the release pipeline, and dev machines now build on the same band. Moving bands becomes a deliberate version bump gated on a green Android head build, documented in docs/store/release-checklist.md and at the setup-dotnet step.

If we later need 10.0.4xx before that band's maui manifest catches up, the code-level escape hatch is registering the Blazor root component in MainPage.xaml.cs instead of XAML, which removes the source-generator dependency entirely. Not needed at 10.0.20+.

Verification

• dotnet publish -c Release -f net10.0-android locally, both apk and aab, clean obj/bin: succeeds, 0 warnings (TreatWarningsAsErrors on).
• release-apk.yml dispatched on this branch: run 31532318170.

Also refreshed two stale spots in the checklist (keystore/tags are done; next tag is v1.6).

🤖 Generated with Claude Code

https://claude.ai/code/session_015MPRzndB5egy4F2A3q5852

Summary by CodeRabbit

• Documentation

  • Updated the release checklist for version 1.6, including completed releases through version 1.5.
  • Added guidance for maintaining consistent .NET SDK and MAUI build environments.
  • Simplified release preparation tasks to focus on Play Console work.

• Maintenance

  • Improved SDK version handling to use the latest compatible patch release.
  • Added release workflow notes describing when SDK updates should be made deliberately.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: e823539f-8cbf-4bec-80cc-f79dda88c1d4

📥 Commits

Reviewing files that changed from the base of the PR and between dbaf5a9 and d7f6dec.

📒 Files selected for processing (3)

• .github/workflows/release-apk.yml
• docs/store/release-checklist.md
• global.json

---

Walkthrough

The release configuration now uses latest-patch SDK roll-forward behavior. Workflow comments and release documentation describe feature-band pinning. The store checklist advances to v1.6 and records completed v1.5 release preparation.

Changes

Release toolchain and checklist

Layer / File(s)	Summary
SDK band pinning and validation .github/workflows/release-apk.yml, global.json, docs/store/release-checklist.md	global.json now uses latestPatch. Workflow comments and checklist guidance document SDK feature-band pinning and Android build validation.
Release checklist status docs/store/release-checklist.md	The next release changes to v1.6 with version code 100060000. The checklist records completed v1.5 preparation and leaves Play Console tasks as pending work.

Estimated code review effort: 2 (Simple) | ~10 minutes

Suggested reviewers: motherrisi

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: pinning the tested .NET SDK feature band for release builds.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

---

_{Comment @coderabbitai help to get the list of available commands.}

[Copilot]

Pull request overview

This PR makes Android release builds reproducible by preventing the .NET SDK from rolling onto a newer, unvetted feature band at build time (the root cause of the v1.5 release breaking minutes after CI).

Changes:

• Pin SDK roll-forward behavior in global.json to latestPatch to stay within the 10.0.3xx feature band.
• Document the rationale and the “how to move bands safely” process in the store release checklist.
• Add an in-workflow note in release-apk.yml explaining why the toolchain is pinned and where to find the checklist guidance.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
global.json	Switch rollForward to latestPatch to prevent feature-band jumps.
docs/store/release-checklist.md	Add a “toolchain pinning” section and refresh version/tag guidance.
.github/workflows/release-apk.yml	Document why the workflow relies on the pinned SDK feature band.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.