[docs] Default Aspire CLI bundle opt-in in new C# AppHost templates - #1483
[docs] Default Aspire CLI bundle opt-in in new C# AppHost templates#1483aspire-repo-bot[bot] wants to merge 1 commit into
Conversation
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Frontend HTML artifact readyThe latest frontend build uploaded the This comment updates automatically when a new frontend build artifact is uploaded. |
There was a problem hiding this comment.
Pull request overview
Updates the Aspire 13.5 “What’s new” and Aspire SDK “Get started” documentation to reflect that newly generated C# AppHost templates (including single-file AppHosts) now default to using the installed Aspire CLI bundle via AspireUseCliBundle=true.
Changes:
- Added a new Aspire 13.5 release-note entry describing the new default behavior and linking to setup docs.
- Updated the Aspire SDK “Use the Aspire CLI bundle…” section to note the new default for newly created AppHosts.
- Added a single-file AppHost example showing the equivalent
#:property AspireUseCliBundle=truedirective.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| src/frontend/src/content/docs/whats-new/aspire-13-5.mdx | Adds a new release-note entry explaining the new default and linking to the relevant SDK docs section. |
| src/frontend/src/content/docs/get-started/aspire-sdk.mdx | Clarifies the default opt-in behavior for new AppHosts and documents the single-file #:property equivalent. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| New C# AppHost projects created with `aspire new` or `dotnet new`, and single-file AppHosts created with `aspire init`, opt in to `AspireUseCliBundle` by default. Existing AppHost projects need to set it explicitly to opt in during the transition before this behavior becomes the default for all AppHosts. | ||
|
|
||
| Set `AspireUseCliBundle` to `true` to opt in during the transition before this behavior becomes the default. | ||
|
|
|
|
||
| ## 📦 Aspire CLI bundle enabled by default in new C# AppHost templates | ||
|
|
||
| New C# AppHost projects and single-file AppHosts created with `aspire new`, `dotnet new`, or `aspire init` now set `AspireUseCliBundle` to `true` automatically, so they use the installed Aspire CLI bundle for DCP and Dashboard orchestration dependencies without an opt-in warning. Existing AppHost projects are unaffected and can opt in manually. |
Adam Ratzman (adamint)
left a comment
There was a problem hiding this comment.
One wording issue before this is ready.
| </PropertyGroup> | ||
| ``` | ||
|
|
||
| For a single-file AppHost created with [`aspire init`](/reference/cli/commands/aspire-init/), set the equivalent `#:property` directive: |
There was a problem hiding this comment.
Could this say For an existing single-file AppHost? The paragraph above says new aspire init AppHosts already opt in, so this currently reads like users need to add a directive that aspire init just generated.
Documents changes from microsoft/aspire#19076
@DamianEdwardsTargeting
release/13.5— the latest release branch onmicrosoft/aspire.dev— becauserelease/13.6(from the source PR milestone13.6) does not exist there.Why
microsoft/aspire#19076 makes new C# AppHost project templates, single-file AppHost templates, and the
aspire initsingle-file skeleton setAspireUseCliBundletotrueby default, so newly generated AppHosts use the installed Aspire CLI bundle for DCP/Dashboard orchestration dependencies without needing the opt-in.Changes
src/frontend/src/content/docs/get-started/aspire-sdk.mdx: Noted that new AppHost projects/single-file AppHosts now opt in toAspireUseCliBundleby default, and added a#:property AspireUseCliBundle=truesingle-file example next to the existing.csprojexample.src/frontend/src/content/docs/whats-new/aspire-13-5.mdx: Added a new 📦 Aspire CLI bundle enabled by default in new C# AppHost templates entry summarizing the change, with aLearnMorelink back to the Aspire SDK docs.Both pages were updated in place; no new pages were created.