Repository navigation
[docs] Document AddCSharpApp obsoletion in favor of AddDotnetProject - #1853
Draft
aspire-repo-bot[bot] wants to merge 1 commit into
Draft
aspire-repo-bot[bot] wants to merge 1 commit into
aspire-repo-bot[bot] wants to merge 1 commit into
Conversation
Documents the breaking change from microsoft/aspire#20825: AddCSharpApp (and the polyglot addCSharpApp export) is now marked [Obsolete] instead of [Experimental("ASPIRECSHARPAPPS001")], producing CS0618 instead of the experimental diagnostic. Adds migration guidance pointing consumers to AddDotnetProject from the Aspire.Hosting.Dotnet package. - Added a breaking-change entry to What's new in Aspire 17.0 - Added a Migrating to AddDotnetProject section to the C# file-based apps integration page, with updated Aside/limitations text - Updated the ASPIRECSHARPAPPS001 diagnostic page and the diagnostics overview table to note the obsoletion - Cross-referenced the migration guidance from the .NET host page, project-resources comparison, and the existing-app onboarding guide Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
4 of 14 tasks
Contributor
Author
Frontend HTML artifact readyThe latest frontend build uploaded the This comment updates automatically when a new frontend build artifact is uploaded. |
4 of 8 tasks
David Fowler (davidfowl)
added a commit
to microsoft/aspire
that referenced
this pull request
Oct 12, 2026
## Description Deprecates `Aspire.AppHost.Sdk` and migrates the default C# AppHost experience toward explicit packages, Project Resource v2 (`AddDotnetProject`), and the CLI bundle. Addresses #20594; **not yet feature complete**. ### Implemented through `3efe19d5ef52f2243a0ac9e5123311199f962ed4` - Retains the functional obsolete SDK, including original `ProjectReference` resources. `ASPIRE012` is suppressible through `SuppressAspireAppHostSdkObsoleteWarning` or `NoWarn`; no removal date is promised. - Establishes `IsAspireHost` from the AppHost package without requiring a test/user-injected property. Preserves the file-based AppHost's non-AOT behavior. - Defaults the workload compatibility version to the actual AppHost package version. Pinned CLI selection independently follows that package, even with an older retained SDK. - Preserves `ASPIRE007` for pre-9 SDKs that cannot set the new marker. - Documents the required `Aspire.Hosting.Dotnet` migration dependency, file-based migration, resource-build tradeoffs and behavioral verification; adds a migration-assistance skill. - Strengthens regression assertions to reject empty/unsubstituted versions and exercise package props rather than injecting `IsAspireHost`. - Converts C# project/file templates and CLI init to explicit AppHost/Dotnet packages; starter services use `AddDotnetProject` paths. Preserves non-C# defaults. - Recognizes and updates package-only AppHosts without restoring the obsolete SDK or removing the explicit AppHost package, including CPM and persisted channel/version configuration. - Makes the CLI bundle required by default for C# AppHosts. Disabling it produces unsuppressible `ASPIRE010`; SDK-warning suppression does not opt out of the bundle. - Uses real native runtime packages in template tests, covers runtime-only Dotnet consumers in CI with/without project-graph analysis, and removes duplicate test-target imports that blocked CI setup. - Recognizes unrestored package-only AppHosts while respecting explicit `IsAspireHost=false`. Shares metadata parsing between discovery and the .NET runner. - Uses evaluated imported package references for updates, rejects `PackageReference Update` as a discovery marker, and parses complete directive lines rather than commented/embedded examples. - Preserves MTP test commands during metadata-only CI enumeration, keeps the extension scenario's required bundle enabled, and stores native template payloads under the harness cleanup root. - Preserves full updater support for F#/VB, versionless SDK directives, and evaluated imported SDK declarations. Updates imported SDK/package declarations in place without introducing duplicate references. - Limits discovery and single-file rewrites to active directive preambles, preserving examples in multiline comments and strings. - Aligns archive deployment fixtures with package-only templates; retained-SDK lanes explicitly restore SDK and resource `ProjectReference` items. Prepares the complete native bundle in each isolated extension home. - Preserves malformed/trailing-token and uppercase package-directive lines during cleanup; only complete valid directives are removed. - Uses package-only C# scaffolding for Aspire 17+, retaining SDK-based scaffolding for earlier versions instead of requesting an unpublished Dotnet integration. - Updates imported legacy SDKs that lack the evaluated SDK-use marker, without treating inactive shared SDK imports as package-only projects' SDK declarations. - Preserves inactive project-local SDK imports in package-only C#/F#/VB AppHosts. Automatic SDK rewrites are limited to unconditional declarations; ambiguous conditional SDKs fail explicitly before edits. Diagnostics use the CLI localization resources. - Migrates the FileKeyRef fixture to `AddDotnetProject`, explicitly opts the EF fixture into its existing experimental v2 API, and removes the Deno fixture's assumption that generated AppHosts contain an SDK directive. Deployment failures capture Compose logs before cleanup. ### CPM guidance documented in `d26c77bd620fdd3fafd5629f0c1026774d78027d` Generated explicit-package AppHosts require manual CPM adjustment: centralize AppHost/Dotnet versions and remove `Version` from their package references, retaining the explicit AppHost reference. Matching central versions alone do not prevent `NU1008`. Packaged baseline comparisons confirmed previously working SDK-only AppHost cases are newly affected; the baseline Redis starter already fails under CPM. David's [accepted team guidance](https://teams.microsoft.com/l/message/19%3AuuDJgMCR7JeFSM-0RK2xRW5mAq2WFNfUK0TLmYDvAU01%40thread.tacv2/1791757040412?groupId=f2e0b0b6-f130-46fa-8ec6-2ef4a7168ed2&parentMessageId=1791622155244) retains the template/CPM convention until further notice. The migration guide documents the expanded limitation rather than changing template policy. A conditional-reference candidate passed five local restore/build/start/stop scenarios but remains unpublished; those results do not qualify the published templates. ### Recorded decisions and ownership - **D003, accepted:** Damian Edwards directed retention of the obsolete but functional SDK, original C# project resources, suppressible build warning and coordinated SDK/AppHost targets. [Team decision](https://teams.microsoft.com/l/message/19%3AuuDJgMCR7JeFSM-0RK2xRW5mAq2WFNfUK0TLmYDvAU01%40thread.tacv2/1791646379788?groupId=f2e0b0b6-f130-46fa-8ec6-2ef4a7168ed2&parentMessageId=1791622155244). - **D004, accepted:** David Fowler directed extension of this PR and ownership of **all** follow-up template/default/bundle work. [Owner direction](https://teams.microsoft.com/l/message/19%3AuuDJgMCR7JeFSM-0RK2xRW5mAq2WFNfUK0TLmYDvAU01%40thread.tacv2/1791650382170?groupId=f2e0b0b6-f130-46fa-8ec6-2ef4a7168ed2&parentMessageId=1791622155244). That work remains in scope, not unassigned or disclaimed. - **D005/D008, pending:** Explicit deprecation/migration sign-off and coordinated `microsoft/aspire.dev` branch/review/publication guidance remain unanswered in [the existing request](https://teams.microsoft.com/l/message/19%3AuuDJgMCR7JeFSM-0RK2xRW5mAq2WFNfUK0TLmYDvAU01%40thread.tacv2/1791649965862?groupId=f2e0b0b6-f130-46fa-8ec6-2ef4a7168ed2&parentMessageId=1791622155244). Adjacent docs PRs microsoft/aspire.dev#1853 and #1804 require coordination, not duplicate writes. - **D006/D007, accepted delivery gates:** Required human approvals/green CI and explicit sign-off, coordinated public docs, and all relevant merges are required. Merge is **not** final acceptance: after official internal daily artifacts publish, the coordinator must start a **new session**, verify their source SHA includes all merged changes, and manually qualify the official new/migrated AppHost and CLI journeys. Local builds and PR dogfood do not replace that gate. ### Validation and remaining gates **Latest continuation:** `bb5a4d0cd343c7c7cadfe7316a4430bd6a47b643` removes only the repo-local migration skill and updates the migration guide; production code, templates and tests are unchanged against `d26c77bd`. Following [David's location request](#20867 (comment)), [microsoft/aspire-skills#93](microsoft/aspire-skills#93) extends the existing migration skill with separately approved, exact-package-capability-gated SDK removal. CODEOWNER reviews are requested; exact current validation is below. The companion is draft/unmerged/unpublished and adds a tracked delivery gate. New source-head checks are not inferred from the previous green run. **New-head native qualification (`bb5a4d0cd`):** production CLI reports `17.0.0-pr.20867.gbb5a4d0c`; native `11724922206`, managed `11724946316`, and Linux RID `11724214237` archives were independently downloaded, SHA256-matched against GitHub metadata and ZIP-integrity checked. A fresh generated explicit-package/AddDotnetProject starter started healthy API/frontend resources with real HTTP and correct Reference/WaitFor relationships. The authenticated rendered Dashboard reported `"Rebuild" succeeded`; API HTTP afterward and CLI restart succeeded. Production `aspire update --channel pr-20867` preserved the AppHost project byte-for-byte and persisted its channel/version. After update/restart the rendered frontend showed five forecasts loaded through the API service. Bundle opt-out still fails ASPIRE010 despite NoWarn; invalid bundle path fails ASPIRE009; normal build then succeeds with zero warnings/errors and unchanged source. All task-owned AppHosts were stopped. Local certificate exceptions and explicit NuGetAudit=false remain qualification limitations, not official-daily acceptance. **Current checks:** source CI [38198464573, attempt 4](https://github.com/microsoft/aspire/actions/runs/38198464573/attempts/4) is **completed/success** at exact `bb5a4d0cd343c7c7cadfe7316a4430bd6a47b643`. Fully paginated settled results conserve **418 unique completed jobs: 415 success / 3 skipped**, all at this head/attempt, with no failures or running jobs. Repository automation initiated the retries; this worker requested none. **Original failures, retained as history:** attempt 1 failed Windows Hosting, Windows Dashboard.Components and macOS CLI. Windows recovery expected POST/GET but observed no requests (482 passes/1 failure/2 skips); Linux reproduction initially had 5 passes/1 same-symptom failure in a different theory case. Exact base `a1f8cbd` passed all six; subsequent current/base runtime controls passed six each. This does not prove Windows root cause or baseline causality, and no timeout/assertion weakening was published. The Dashboard chart-filter-open assertion failed (746 passes/1 failure); its unchanged test passed locally. macOS CLI hung for ten minutes with three unfinished tests; 6420 passes/49 skips/0 assertion failures plus one runner error was **not** a suite pass. The final retry's success does not establish the original failures' causes. Original failed-job artifacts `11723833975`, `11724428662`, and `11725065389` were independently downloaded, digest/head/ZIP-verified and their TRX counters/assertions inspected. Exact-base [main CI `38099325878`](https://github.com/microsoft/aspire/actions/runs/38099325878) attempt 1 was fully paginated (338 unique, same-head completed jobs): both current failing Windows lanes passed at base. The base macOS CLI lane also hung, but with different unfinished tests; that does not establish the current hang's cause or justify dismissing either Windows failure. The Dashboard assertion passes in both current and unmodified base local builds. Harness side effect: default starter generation also installed agent skills/hooks globally; that side effect was not isolated. No known pre-state exists for those shared files, so they were not blindly reverted. **Companion checks:** current `965767d7abb44de8183ba492b3af3026e727d70c` applies the owner-approved correction to exactly the router and migration executor values, from unsupported `gpt-5.6-sol-fast` to `gpt-5.6-sol`. Parsed specs were independently compared: judge, thresholds, stimuli/fixtures, trial counts and guards are unchanged. **52 focused tests and 377 exact-commit full Node tests pass**; GitHub lint and all three platform test+bundle checks pass. The [actual agent-eval gate](https://github.com/microsoft/aspire-skills/actions/runs/38204985764/job/114666377185) completed **success**, with **51 executed/graded trials and no execution/grading infrastructure errors**. Migration passed **24/24, score 100% at unchanged 100% threshold**; router passed **26/27 cases, aggregate 97.53% at unchanged 70% threshold**. Both SDK capability/approval guard cases passed with empty workspace patches. Downloaded result artifact `11727331701` independently matched GitHub SHA256 `d4083d79112d603d85fd7c4721a44f12a5eef69a9b91d6849a2bed41a6538920`, source head and ZIP integrity; raw trial conservation/grades and the repository integrity checker were verified again locally. Local authenticated reproduction remains enterprise-DNS-blocked; hosted actual behavior is now verified within this scoped gate. **Explicit eval limitation:** router case `should_trigger_08` activated `aspire-init` for read-only `aspire doctor` instead of the contract's `aspire-orchestration`. Both unchanged skills document doctor. This is not an all-individual-cases pass or full-nightly-suite acceptance; no grader/threshold was weakened and no unrelated routing rewrite was mixed into SDK delivery. **Configuration decision and human IDE check:** [main's actual nightly eval](https://github.com/microsoft/aspire-skills/actions/runs/38117249387) at `da1230ca` failed on the same old executor, including original migration cases. David's later, independently verified 04:20 UTC "Yep do it" approved the exact two-setting proposal and supersedes his earlier conditional maintainer hold for this correction. Approval and calibrated confidence were communicated in the authorized Teams thread before the edit. This is configuration permission, not PR review/merge approval or deprecation sign-off. No judge/threshold/fixture/trial/guard weakening or manual CI retry was requested. Damian's planned Windows/Visual Studio try-out remains a human qualification gate, not satisfied by Windows CI or Linux manual results. **Owned publication follow-up:** the current installer and embedded snapshot still pin skills `v0.0.3`, whose digest-verified archive does not contain the new SDK migration reference. Merging/publishing #93 alone will not update this pinned CLI payload. This owner retains the source follow-up: after approved companion publication, use the existing attestation-enforcing updater to refresh the archive/metadata, installer version, project resource and telemetry hooks, then qualify the resulting source head. Default bundle support remains `>=13.5.0 <13.7.0`; remote and remote-origin cached bundles enforce it, while embedded-origin bundles explicitly skip compatibility. Current embedded fallback success is not proof of remote CLI17 compatibility. Do not bypass attestation or silently widen the whole bundle's support claim. **Fresh `d26c77bd` compatibility and E2E:** installed the production native PR CLI/hive and independently rechecked native archive `11717736089` SHA256 `1226001c9b51d4d7367f0544727db916a7b0f288ca3956a764764fdfbbbec25d`. The generated AddDotnetProject starter started both services with working HTTP/health/references/waits, rendered authenticated Dashboard, successful Dashboard Rebuild, HTTP after rebuild, resource restart and graceful stop. Genuine released CLI13.6.1 ran this new explicit-package starter and SDK17 with an original AddProject resource; the PR CLI ran unchanged SDK13.6.1 with an original resource and working HTTP. A CLI-only upgrade does not rewrite SDK/resources or introduce the new SDK's ASPIRE012. These are tested combinations, not universal old-version support. **Retained coverage and human review:** the two unchanged legacy resource classes passed **90/90**, the SDK target class passed **69 with 3 Windows-only skips**, and both runtime-consumer selector tests passed. AddProject is not newly deprecated by this PR. [Selector rationale](#20867 (comment)), [measured helper-library run-hook rationale](#20867 (comment)), and [skill-location response](#20867 (comment)) are posted. The three human threads remain unresolved; replies are not acceptance or approval. **Fresh qualification limitations:** full restore failed first on audit connectivity and then feed downloads; focused builds used explicit `NuGetAudit=false` and a build-only HTTP/2 workaround. Initially leaking that workaround into AppHost runtime broke Dashboard gRPC; removing it and restarting produced the fresh GUI results above. No vulnerability-audit success, full cross-platform/extension GUI, Windows debugger correction, full Kubernetes/FileKeyRef/Deno deployment, or official-daily acceptance is claimed. The scoped plugin migration was exercised manually in the current Copilot host, not via a separate Vally agent-output evaluation. All task-owned AppHosts were stopped and known process IDs verified absent. [Substantive Teams answer](https://teams.microsoft.com/l/message/19%3AuuDJgMCR7JeFSM-0RK2xRW5mAq2WFNfUK0TLmYDvAU01%40thread.tacv2/1791773933006?groupId=f2e0b0b6-f130-46fa-8ec6-2ef4a7168ed2&parentMessageId=1791622155244) was posted and independently read back. **Previous runtime-head CI:** [CI run 38180555189, attempt 3](https://github.com/microsoft/aspire/actions/runs/38180555189) is **completed/success** at exact head `d26c77bd`, confirmed independently from the workflow resource and PR checks; both final aggregates succeeded. Smaller-page pagination independently conserved **418 unique completed jobs: 415 success / 3 skip**, all reporting attempt 3 and the exact head. This was an externally triggered retry, not requested by this worker. The advisory Windows debugger limitation below is not erased by green checks. Human approving review, explicit deprecation/migration sign-off, coordinated public docs, companion-skill delivery and official-daily acceptance remain required. **Native updater evidence (`d26c77bd`):** production `aspire update` on the migrated package-only project succeeded, preserved its `Microsoft.NET.Sdk` and explicit AppHost/Dotnet references byte-for-byte, and persisted PR channel/version configuration. The updated project built successfully. A duplicate-cased local NuGet config from fixture setup caused the first explicit failure; removing that duplicate corrected it. **Exact-package negative diagnostics (`d26c77bd`):** disabling the bundle fails with `ASPIRE010` even with `NoWarn=ASPIRE010`; a nonexistent bundle path fails with actionable `ASPIRE009` installation/path guidance. Both nonzero outcomes were asserted. The subsequent normal build succeeds with zero warnings/errors and the project remains unchanged. **Exact-head production native evidence (`d26c77bd`):** Linux CLI archive `11717736089`, managed packages `11718275023`, and RID packages `11717586279` were downloaded and their SHA256 values matched GitHub metadata. Installed CLI reports `17.0.0-pr.20867.gd26c77bd`. Original template generation, real `AddDotnetProject` service startup/HTTP, authenticated rendered Dashboard, Dashboard Rebuild success and HTTP after rebuild, native restart/stop, retained-SDK original `ProjectReference` resources, and explicit-package migration startup/HTTP/rebuild succeeded. All task-owned AppHosts were stopped. SDK acquisition initially hit stale source mapping; the verified SDK was then cached and normal resolution succeeded. These use the preview SDK, explicit runtime root and `NuGetAudit=false`; they do not qualify vulnerability audit, full extension GUI, cross-platform behavior or official daily artifacts. **Historical review/CI state at `d26c77bd`:** earlier inline threads were addressed and resolved, before the three subsequent human questions recorded above. This is not an approving review. Previous runtime-head CI succeeded as recorded above, not qualification of the new documentation-only head. Historical attempt-1 Linux tray-watch and Windows Kubernetes recovery failures were tested against merge `3eeac162` into base `a1f8cbd`; the relevant production/test paths are unchanged against that base. Local focused tray cases (4), full tray class (34), recovery cases (3), updater class (128), and package marker/AOT cases (2) passed. Those focused results do not establish Windows reproduction or unrelated-baseline causality; the successful external retry does not explain the original failures. **Exact-head extension evidence:** Linux edge-cases job `114594546086` independently confirms the required `gd26c77bd` bundle and **6 passing** UI scenarios, including debugger-install guidance with the AppHost source closed. Windows browser-debugger job `114594546186` finished with **7 passes / 1 failure**: standalone Blazor WASM root-session attachment timed out. The workflow explicitly makes completed failures in this lane advisory under #20117; its successful job status is **not** an all-scenarios pass. **Historical qualification correction:** attempt 1 settled at **418 jobs: 411 success / 4 failure / 3 skip** (two actual test failures and two aggregates), before the successful external attempt 3. This worker did not request either retry. Full local CLI scheduling reproduced the tray exit-code failure that focused runs missed. That run had **7,085 passes / 45 failures / 57 skips**, including missing shell prerequisites and privileged-filesystem assumptions, and is not a suite pass. The full SDK target class passed **69 / 3 Windows-only skips**. The documented manual CPM adjustment builds with the exact-head packages. No speculative cancellation patch, test weakening or template-policy change was published. **Current source evidence (`3efe19d5e`):** updater/parser/locator tests passed **285 / 3 platform/filesystem skips**. A real package-only AppHost with an inactive project-local SDK import built successfully; source CLI update preserved its active AppHost package and inactive import byte-for-byte. A real active conditional SDK **13.6.1** produced the documented explicit manual-edit error without changing the source. These use matching `8cf28660d` packages with the corrected source CLI, not a final-head native binary. Deployment test-project build and Deno E2E TypeScript compilation passed; compilation is not full deployment or GUI acceptance. **Earlier imported-SDK evidence (`8cf28660d`):** the focused classes passed **277 / 3 skips**, covering imported marker-absent SDKs and inactive shared imports, but not the project-local conditional-import bug fixed above. Real imported SDK **13.6.1** migrated successfully with the corrected source CLI, including restore/build and ASPIRE012. The broader project-class selection had **1,140 passes / 2 failures / 4 skips** in untouched process-shutdown and root-permission tests; not a full-suite pass. **Scoped native evidence (`8cf28660d`, not final HEAD):** Linux archive `11695117081` and matching packages `11695056414` matched their GitHub SHA256 metadata; the installed CLI reported `17.0.0-pr.20867.g8cf28660`. The corrected EF fixture compiled, generated its migration bundle, and published Compose output. Full deployment failed: captured PostgreSQL and Dashboard logs explicitly report **No space left on device**. This is an environment-blocked failure, not a pass. FileKeyRef deployment and actual Deno GUI/debugger qualification remain pending. **Earlier source evidence:** `4c1687cc1` focused discovery/parser/updater/new/init/template tests passed **664 / 3 skips**; trigger-map infrastructure tests passed **156** before its directive-casing-only change. Source-built CLI `0da548f42` generated an SDK-based `13.6.1` AppHost against the stable feed; restore, startup, authenticated Dashboard inspection, describe and graceful stop succeeded. These remain historical evidence, not final-head native qualification. **Production native evidence (`56ebe3bfa`, not current HEAD):** verified Release native archive `11693801830` and matching packages `11694316113` passed **7/7** archive scenarios and **2/2** C# channel-update scenarios. Manual package-only AppHost/API startup, authenticated Dashboard rebuild, CLI resource restart/update/stop, retained-SDK migration preserving original project resources, both ASPIRE012 suppression mechanisms, and explicit migration to `AddDotnetProject` all succeeded. Missing-resource restart and bundle opt-out failed explicitly as required. Both live AppHosts were stopped. These results do **not** qualify subsequent cleanup/stable-template/imported-SDK commits. **CI/infrastructure evidence and limitations:** `56ebe3bfa` run [38117084347](https://github.com/microsoft/aspire/actions/runs/38117084347) selected all **101 test projects / 11 job categories**, without skipped/unattributed projects. Downloaded Hosting shard counters were **174 passed / 2 not executed / 0 failed**; this is one shard, not complete partition/execution conservation. Logs verify tested merge `82ca627` into base `a1f8cbd`, explaining tests absent from the older local base; DevTunnels, Windows Kubernetes recovery, Windows child-process and macOS telemetry failures are in unchanged paths relative to that actual base, not proven PR regressions. The stable C# Smoke failure's captured diagnostics identified unpublished `Aspire.Hosting.Dotnet@13.6.1`; this is corrected by the source/runtime qualification above. Prior CI ultimately had **342 success / 8 failure / 66 cancellation / 2 skip** jobs; it was not green. Prior-head `8cf28660d` [CI run 38120117496](https://github.com/microsoft/aspire/actions/runs/38120117496), attempt 1, had **418 jobs: 409 success / 6 failure / 3 skip**. Four actual failures were Linux CLI's tray-watch test, EF deployment, FileKeyRef deployment, and Linux Deno debugger; the other two failures were aggregates. The three fixture failures' source causes are corrected above; the unchanged tray-watch failure has no demonstrated PR-specific cause. Later attempts were observed, not requested by this worker. Final-head CI and Linux native/migration/dashboard evidence are recorded above; full cross-platform GUI and official-daily acceptance are not inferred. Prior `4c1687cc1` [run 38118765689](https://github.com/microsoft/aspire/actions/runs/38118765689) and earlier local CLI results were not green acceptance. Local extension GUI remains blocked by VS Code download DNS/socket failures; local Kubernetes failed before scaffolding during KinD startup. **Earlier evidence below is historical, not replacement-worker or latest-head acceptance.** The single owner retains all remaining qualification and follow-up scope. DamianEdwards's human review request was posted and independently verified; no approval is inferred. Reconstructed SDK tests passed **67 / 3 Windows-only skips** and selected CLI discovery/init/update/template tests passed **604 / 3 platform/filesystem skips** against the integrated production changes. Warning/suppression tests now require successful builds, and file-based package props explicitly assert `PublishAot=false`. The CI import failure was reproduced by evaluation and corrected at source. Coherent `17.0.0-issue20594` packages were produced at `e82f4e7f`; the template harness passed **3 real build/start/stop scenarios** covering CPM and retained SDK with/without an explicit AppHost reference, then passed all three again after the cleanup-root changes now persisted at `1ed3f183`. These use actual native Dashboard/DCP packages and isolated pinned SDKs, supplying real bundle paths and suppressing only CLI delegation so the harness controls process lifetime. The follow-up discovery/runner/updater/parser checks passed **492 / 3 skips**, including first-restore, explicit opt-out, imported-package, commented-directive and metadata-update regressions. Extension E2E TypeScript compilation passed; this is not a GUI scenario pass. Both CI-failing test projects now compute their MTP run command with a deliberately nonexistent tasks assembly, while the bundle remains enabled. Hosting MSBuild passed **29 / 2 Windows-only skips** unchanged after removing a verified stale generated attribute file that caused the earlier 13 failures. Expanded trigger routing passed **156** invariants. Standalone exact-head native CLI publication at `75e78efd` passed; embedded publication previously exited 137 and is retrying serially against `1ed3f183`. Full CLI/embedded-bundle/new-service/migration/dashboard-UX qualification remains in progress. Audit connectivity warnings `NU1900`/`NU1905` remain visible and do not establish a successful vulnerability audit. Earlier retired-environment results are **not** current evidence. Full integrated E2E/UX, Windows-specific behavior, required CI, human approval, explicit deprecation sign-off, coordinated docs publication and new-session official-artifact acceptance remain outstanding. Bot reviews and product decisions are not PR approval. ## Checklist - Is this feature complete? - [ ] Yes. Ready to ship. - [x] No. Follow-up changes expected within this owner's scope. - Are you including unit tests for the changes and scenario tests if relevant? - [x] Yes - [ ] No - Did you add public API? - [ ] Yes - [x] No - Does the change make any security assumptions or guarantees? - [ ] Yes - [x] No --------- Co-authored-by: David Fowler <davidfowl@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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.
Documents changes from microsoft/aspire#20825
@mitchdennyTarget branch
Targeting
release/17.0based on the source PR milestone17.0(exact_match).Why this PR is needed
PR #20825 replaces the experimental
ASPIRECSHARPAPPS001diagnostic onAddCSharpApp(and the polyglotaddCSharpAppexport) with a warning-level[Obsolete]attribute directing consumers toAddDotnetProjectfromAspire.Hosting.Dotnet. This is a labeledbreaking-change: existing C#AddCSharpAppcalls now produceCS0618instead of the experimental diagnostic, and the docs site previously describedAddCSharpAppas purely experimental with no obsoletion/migration guidance.Triggered signals from the automated analysis:
obsolete_attribute_added(new[Obsolete(...)]on the public/internalAddCSharpAppoverloads inProjectResourceBuilderExtensions.cs),integration_readme_changed(Aspire.Hosting.Dotnet/README.mdgained a "Migrating from AddCSharpApp" section),pr_label_breaking_change, and PR-body signals confirming a deprecation marker and a "User-facing usage" section.Summary of documentation changes
whats-new/aspire-17.mdx— added a#### AddCSharpApp is obsoleteentry under Breaking changes, explaining the[Obsolete]/CS0618change and linking to the source PR and migration guidance.integrations/dotnet/csharp-file-based-apps.mdx— changed the topAsidebanner from "Experimental" to "Obsolete", updated the limitations list, and added a new## Migrating to AddDotnetProjectsection with install/usage snippets for both C# and TypeScript, plus aCS0618suppression example for consumers who keep usingAddCSharpApp.diagnostics/aspirecsharpapps001.mdx— added a note that the diagnostic is obsolete starting in 17.0 and now surfaces asCS0618, with a link to the new migration section.diagnostics/overview.mdx— updated theASPIRECSHARPAPPS001table row description to mention theCS0618replacement.integrations/frameworks/dotnet/dotnet-host.mdx— added a note pointing readers migrating fromAddCSharpAppto the new migration section.integrations/dotnet/project-resources.mdx— added a note to the "AddProject vs. AddCSharpApp" comparison section flagging the obsoletion.get-started/add-aspire-existing-app.mdx— updated theAddCSharpApp is experimentalcaution callout toAddCSharpApp is obsolete, recommendingAddDotnetProjectfor new AppHosts.All pages were existing — no new pages were created.
Files modified
src/frontend/src/content/docs/whats-new/aspire-17.mdxsrc/frontend/src/content/docs/integrations/dotnet/csharp-file-based-apps.mdxsrc/frontend/src/content/docs/diagnostics/aspirecsharpapps001.mdxsrc/frontend/src/content/docs/diagnostics/overview.mdxsrc/frontend/src/content/docs/integrations/frameworks/dotnet/dotnet-host.mdxsrc/frontend/src/content/docs/integrations/dotnet/project-resources.mdxsrc/frontend/src/content/docs/get-started/add-aspire-existing-app.mdxValidation
Documentation-only change; no code to build or test. Verified internal anchor links (
#migrating-to-adddotnetproject,#breaking-changes) resolve to the headings added in this PR, and checked:::Aside/note fence balance in each edited file.