Fix guest AppHost update with older CLI#17100
Conversation
Preflight guest AppHost package updates when the target SDK is newer than the running CLI so users can update the CLI first. Defer saving aspire.config.json until guest SDK regeneration succeeds. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
sebastienros
requested review from
JamesNK,
davidfowl and
mitchdenny
as code owners
There was a problem hiding this comment.
Pull request overview
Fixes #17077 where aspire update on a guest AppHost (e.g. TypeScript) project would mutate aspire.config.json to newer package versions before SDK regeneration ran, leaving the project in a broken state when the bundled CLI/code-generator lagged the new packages.
Changes:
GuestAppHostProject.UpdatePackagesAsyncnow keeps the updated config in memory, regenerates the SDK first, and only persistsaspire.config.jsonafter regeneration succeeds.IAppHostServerProject.PrepareAsync(andDotNetBasedAppHostServerProject.CreateProjectFilesAsync/PrebuiltAppHostServer.PrepareAsync) accept an optionalrequestedChannel, so regeneration uses the channel matching the in-memory config instead of re-reading from disk.UpdateCommandadds aTryUpdateCliBeforeGuestProjectUpdateAsyncpreflight that compares the target Aspire.Hosting version against the running CLI and prompts the user to update the CLI first (skipping the project update if they accept).
Reviewed changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| src/Aspire.Cli/Projects/GuestAppHostProject.cs | Stage config in memory; save only after regen succeeds; thread config.Channel into PrepareAsync calls. |
| src/Aspire.Cli/Projects/IAppHostServerProject.cs | Add optional requestedChannel parameter to PrepareAsync. |
| src/Aspire.Cli/Projects/PrebuiltAppHostServer.cs | Honor caller-supplied requestedChannel, falling back to project resolution. |
| src/Aspire.Cli/Projects/DotNetBasedAppHostServerProject.cs | Thread requestedChannel through CreateProjectFilesAsync / PrepareAsync. |
| src/Aspire.Cli/Commands/UpdateCommand.cs | Preflight CLI-vs-target version check for guest projects with a prompt to update CLI first. |
| tests/Aspire.Cli.Tests/Commands/UpdateCommandTests.cs | Three new tests covering accept/decline/no-download-url branches of the new preflight. |
| tests/Aspire.Cli.Tests/Projects/GuestAppHostProjectTests.cs | Rewritten regression test asserts config is not advanced when regeneration fails. |
| tests/Aspire.Cli.Tests/Projects/AppHostServerSessionTests.cs | Updated test double for new PrepareAsync signature. |
| tests/Aspire.Cli.Tests/TestServices/TestAppHostProjectFactory.cs | Made LanguageId/DisplayName configurable and added UpdatePackagesAsyncCallback to support guest-language tests. |
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 17100Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 17100" |
Clarify the pre-update CLI prompt, explain that project update is skipped after accepting CLI update, and share guest AppHost SDK version resolution between the preflight and updater. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
@maddymontaquila @nmontaquila15 would appreciate if you can confirm this build fixes your issue |
PR testing summaryTested this PR with the repo-local Aspire PR container runner. I also checked the linked issue #17077 and added a closer variant of that repro to the scenario set. Result: ? Verified CLI version: Scenarios run:
No PR-blocking issues found in these scenarios. |
|
Took this one for a real dogfood spin — it captures the bug nicely. CLI / installPR build Scenarios (TypeScript guest AppHost)S1 — same-channel sanity (downgrade S2 — THE BUG (running CLI < target SDK): project pinned to
S3 — second leg with the newly self-updated CLI: re-ran the same Code reviewOne finding (verified against
Everything else I walked through looked correct:
LGTM modulo the |
…ix-typescript-apphost-update # Conflicts: # src/Aspire.Cli/Commands/UpdateCommand.cs # src/Aspire.Cli/Projects/DotNetBasedAppHostServerProject.cs # tests/Aspire.Cli.Tests/Projects/GuestAppHostProjectTests.cs
|
❓ CLI E2E Tests unknown — 92 passed, 0 failed, 2 unknown (commit View all recordings
📹 Recordings uploaded automatically from CI run #26106919016 |
When aspire update targets a non-C# (guest) AppHost and the selected SDK is newer than the running CLI, the command now prompts the user to update the CLI first and skips the project update until they do. Documents changes from microsoft/aspire#17100. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Pull request created: #1013
|
|
📝 Documentation has been drafted in microsoft/aspire.dev#1013 targeting Updated
Note This draft PR needs human review before merging. |
Description
aspire updatecould advanceaspire.config.jsonfor guest AppHost projects before SDK regeneration completed. With older CLIs updating TypeScript AppHosts to a newer SDK, regeneration could fail because the bundled CLI lacked the matching code generator, leaving the project broken.This change preflights guest AppHost updates against the target channel SDK version and prompts for a CLI update before mutating the project when the target SDK is newer than the running CLI. It also stages guest config updates in memory and writes
aspire.config.jsononly after SDK regeneration succeeds, while threading the requested channel into AppHost server preparation so regeneration uses the selected SDK before persistence.Validated with the focused Aspire CLI
UpdateCommandTestsandGuestAppHostProjectTestsrun.Fixes: #17077
Checklist
<remarks />and<code />elements on your triple slash comments?