Fix MAUI launch queue handoff - #19383
Open
Gerald Versluis (jfversluis) wants to merge 2 commits into
Open
Conversation
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Contributor
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 19383Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 19383" |
Copilot started reviewing on behalf of
Gerald Versluis (jfversluis)
August 14, 2026 09:07
View session
Contributor
There was a problem hiding this comment.
Pull request overview
Updates MAUI platform launch handoff while preserving serialized builds for shared projects.
Changes:
- Uses platform-specific MAUI Run commands and queue-release policies.
- Adds bounded, state-aware lock release handling.
- Expands regression tests and documentation.
Show a summary per file
| File | Description |
|---|---|
src/Aspire.Hosting.Maui/Annotations/MauiBuildInfoAnnotation.cs |
Stores the platform lock-release policy. |
src/Aspire.Hosting.Maui/Lifecycle/MauiBuildQueueEventSubscriber.cs |
Implements state-aware, timed queue handoff. |
src/Aspire.Hosting.Maui/MauiPlatformHelper.cs |
Configures Android and non-Android launch behavior. |
src/Aspire.Hosting.Maui/README.md |
Documents platform-specific queue semantics. |
tests/Aspire.Hosting.Maui.Tests/MauiBuildQueueTests.cs |
Tests handoff states, timeout, and cancellation. |
tests/Aspire.Hosting.Maui.Tests/MauiPlatformExtensionsTests.cs |
Verifies platform command shapes and policies. |
Review details
💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.
- Files reviewed: 6/6 changed files
- Comments generated: 0
- Review effort level: Balanced
Contributor
|
Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt. |
This was referenced Aug 14, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This extracts the MAUI build-queue and launch-handoff fix from #18591 into a focused PR so the queue behavior can be reviewed independently from the larger OTLP, DevTunnels, DCP lifecycle, readiness, and Foundry changes.
MAUI platform resources that share one project must serialize their pre-builds because MSBuild cannot safely build the same project concurrently. The existing launch handoff used
dotnet build --no-restore /t:Run -p:NoBuild=true, which .NET SDK 10.0.201 rejects withNETSDK1085because theBuildtarget is still invoked whileNoBuild=true.This change preserves the shared project build queue while making the launch handoff platform-aware:
dotnet build --no-restore /t:Run -p:BuildDependsOn= -p:NoBuild=true. ClearingBuildDependsOnbefore settingNoBuild=trueavoidsNETSDK1085, and the queue is released when DCP reportsRunningso another platform can build while the launched app remains alive.dotnet build --no-restore /t:Runbecause its Run target performs required fast-deploy/runtime upload work after compilation. Android retains the queue throughRunningand releases it when the short-lived Run process reaches a terminal or unavailable state.Buildingsnapshot using Aspire's resource-state comparer, handles raw DCPTerminatedlocally, and has a bounded timeout so a failed deployment cannot hold the queue indefinitely.User-facing usage
No AppHost changes are required. Multiple platform resources for one MAUI project continue to use the existing APIs:
The platforms build serially, but successfully launched non-Android apps no longer hold the queue for their full lifetime. Android holds it only until deployment and runtime upload complete.
Validation
Automated validation on rebased head
188909a89764483886786644219a7c4e18de5f1fagainst latestmainatf721513cf34b4abdc5217ccb001b52ccf2008f4a:./restore.shMSBUILDTERMINALLOGGER=false dotnet build src/Aspire.Hosting.Maui/Aspire.Hosting.Maui.csproj --no-restore -m:1— succeeded with 0 warnings and 0 errorsAspire.Hosting.Maui.Testsproject with quarantined and outerloop exclusions — 183 passedgit diff --check main...HEADand the six-file allowlist check passedManual AppHost/device validation was completed before the conflict-free latest-
mainrebase on the equivalent queue changes atdc8225702b9c0bdf4c8641f13cb9e24cb383f88c:Runningwhile both/t:Runprocesses and apps remained aliveBuildDependsOn/NoBuildcommand shape withoutNETSDK1085Runningand deploying, and released it only after/t:RunexitedFinishedThe first cold Android build exceeded the existing 10-minute build timeout under local disk/cache pressure. A direct incremental pre-build completed in 39.55 seconds and the real retry then passed. Local validation also required linking the already-installed MAUI workload packs into the worktree SDK and suppressing the playground's pre-existing
NU1605package mismatch.After rebasing, the MAUI hosting project build and complete 183-test MAUI suite were rerun successfully, followed by fresh generic and Aspire architecture reviews with no findings.
Related focused work
#19386 is the sibling follow-up containing only the MAUI OTLP dev-tunnel endpoint resolution and Android/iOS environment refresh extracted from #18591. It intentionally excludes long-running DevTunnel watcher reconciliation, stale-port cleanup, shared allocation serialization, and broader DCP/readiness/Foundry lifecycle changes.
Fixes # (issue)
Checklist
<remarks />and<code />elements on your triple slash comments?