Deprecate Aspire.AppHost.Sdk (ASPIRE012)

[David Fowler (davidfowl)]

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 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.
• D004, accepted: David Fowler directed extension of this PR and ownership of all follow-up template/default/bundle work. Owner direction. 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. Adjacent docs PRs [docs] Document AddCSharpApp obsoletion in favor of AddDotnetProject aspire.dev#1853 and Fix dashboard startup ordering. #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, 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 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 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 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 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, measured helper-library run-hook rationale, and skill-location response 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 was posted and independently read back.

Previous runtime-head CI: CI run 38180555189, attempt 3 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 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, 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 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.
  • No. Follow-up changes expected within this owner's scope.
• Are you including unit tests for the changes and scenario tests if relevant?
  • Yes
  • No
• Did you add public API?
  • Yes
  • No
• Does the change make any security assumptions or guarantees?
  • Yes
  • No

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 20867

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 20867"

[Copilot]

🟡 Changes recommended

The package-only migration path remains disabled, selects an incompatible CLI fallback version, and omits a required package.

2 open findings

• Package path never sets IsAspireHost · New
• Migration omits the Aspire.Hosting.Dotnet package · New

What changed in this PR

Soft-deprecates Aspire.AppHost.Sdk and documents migration to package-based AppHosts using Project Resource v2.

Changes:

• Adds suppressible diagnostic ASPIRE012.
• Updates AppHost target detection and SDK-version handling.
• Adds migration documentation and regression tests.

File	Description
src/​Aspire.AppHost.Sdk/​SDK/​Sdk.in.props	Marks SDK-based AppHosts.
src/​Aspire.AppHost.Sdk/​SDK/​Sdk.in.targets	Emits ASPIRE012.
src/​Aspire.Hosting.AppHost/​build/​Aspire.Hosting.AppHost.in.targets	Adjusts version defaults and ASPIRE007.
tests/​Aspire.Hosting.Sdk.Tests/​AppHostSdkTargetsTests.cs	Adds diagnostic and migration-path tests.
docs/​migrate-from-apphost-sdk.md	Adds migration instructions.
docs/​list-of-diagnostics.md	Documents ASPIRE012.

🧠 Review effort: Balanced

[Copilot]

🔵 Needs a closer look

Package-only AppHosts are not fully activated, CLI fallback is pinned incorrectly, and old SDK detection regresses.

2 open findings

• Package path never sets IsAspireHost
• Migration omits the Aspire.Hosting.Dotnet package

Previously missed (3)

In code that hasn't changed since last review

Preserve package version for Aspire CLI selection

src/​Aspire.Hosting.AppHost/​build/​Aspire.Hosting.AppHost.in.targets:15

AspireHostingSDKVersion is not used only by the workload check: line 225 also uses it to build the pinned DNX reference aspire.cli@$(AspireHostingSDKVersion). A current package-only AppHost following the guide will therefore fall back to Aspire CLI 9.0.0 (including DnxPinned) instead of the CLI paired with the installed Aspire.Hosting.AppHost package. Preserve the real package version in a separate property for CLI selection rather than reusing this sentinel value.

Add backward-compatible fallback for pre-9 AppHost SDK

src/​Aspire.Hosting.AppHost/​build/​Aspire.Hosting.AppHost.in.targets:743

This marker was introduced by this PR, so a genuinely pre-9 Aspire.AppHost.Sdk cannot set it. If such a project resolves the current Aspire.Hosting.AppHost package, this condition skips ASPIRE007; the new test masks that compatibility case by manually adding the new marker. Keep a backward-compatible version-based fallback (the new 9.0.0 default already prevents package-only projects with an empty version from failing).

Reject unparsable values in the version assertion

tests/​Aspire.Hosting.Sdk.Tests/​AppHostSdkTargetsTests.cs:129

This assertion accepts any nonempty unparsable value because Version.TryParse returning false makes MSBuildStringVersionIsLessThan9 return false. In particular, the unsubstituted @VERSION@ token that the production comment explicitly aims to avoid would pass this regression test. Assert the intended fixed value directly.

🧠 Review effort: Balanced

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Copilot]

🟡 Changes recommended

The documented migration conflicts with current aspire update behavior, and regression coverage has correctness gaps.

3 open findings

• Package path never sets IsAspireHost
• Fix aspire update handling for package-only AppHost migration · New
• Test package props disable PublishAot for file-based apps · New

1 resolved since last review

• Migration omits the Aspire.Hosting.Dotnet package

Previously missed (1)

In code that hasn't changed since last review

Assert successful builds in warning and suppression tests

tests/​Aspire.Hosting.Sdk.Tests/​AppHostSdkTargetsTests.cs:249

The warning/suppression tests return only process output and never check the MSBuild exit code. In particular, each Assert.DoesNotContain("ASPIRE012", output) test will pass if the generated project fails before PrepareForBuild, so regressions in this target can be hidden by an unrelated build failure. Assert a zero exit code before returning the output.

🧠 Review effort: Balanced

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Copilot]

🔵 Needs a closer look

The PR explicitly remains feature-incomplete, with final-head CI and native migration, dashboard, and extension qualification still outstanding.

5 open findings

• Avoid explicit package versions in CPM-enabled AppHost template
• Update E2E scenario for AspireUseCliBundle error behavior
• Package path never sets IsAspireHost
• Test package props disable PublishAot for file-based apps
• Fix aspire update handling for package-only AppHost migration

1 resolved since last review

• Make empty template package references CPM-compatible

Files not reviewed (1)

• src/Aspire.Cli/Resources/UpdateCommandStrings.Designer.cs: Generated file

🧠 Review effort: Balanced

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Tests selector

Selects the full PR test matrix + all PR-gated jobs (ALL) — a rule matching 'tests/Shared/RepoTesting/Aspire.RepoTesting.props' selects ALL

---

Selection computed for commit bb5a4d0.

[Copilot]

🔵 Needs a closer look

It is explicitly feature-incomplete, spans several user-facing compatibility contracts, and still requires human sign-off and post-publication qualification.

0 open findings

5 resolved since last review

• Avoid explicit package versions in CPM-enabled AppHost template
• Update E2E scenario for AspireUseCliBundle error behavior
• Package path never sets IsAspireHost
• Test package props disable PublishAot for file-based apps
• Fix aspire update handling for package-only AppHost migration

Files not reviewed (1)

• src/Aspire.Cli/Resources/UpdateCommandStrings.Designer.cs: Generated file

🧠 Review effort: Balanced

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[github-actions]

Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt.

[Damian Edwards (DamianEdwards)]

PR Testing Report

PR Information

• PR: microsoft/aspire#20867, Deprecate Aspire.AppHost.Sdk (ASPIRE012)
• Head commit: bb5a4d0cd343c7c7cadfe7316a4430bd6a47b643
• Tested: October 12, 2026, approximately 10:53-11:05 PDT
• Execution: Local Windows x64, isolated PR installation and fresh temporary apps
• SDK: 11.0.100-rc.1.26425.128; generated projects target net10.0
• Scope: Verify functional SDK retention, suppressible deprecation, SDK-free C# templates, project/file migration, and package-only CLI discovery/update.

Artifact Version Verification

• Installed CLI: 17.0.0-pr.20867.gbb5a4d0c
• Expected commit: bb5a4d0cd343c7c7cadfe7316a4430bd6a47b643
• Status: Passed; short commit matches. PR head was rechecked after testing and is unchanged.
• Installer source run: 38198464573, attempt 4, completed/success at the exact head.
• Retained package: Aspire.AppHost.Sdk.17.0.0-pr.20867.gbb5a4d0c.nupkg is in the downloaded hive and restores successfully.
• CLI executable: D:\tmp\aspire-pr-20867-ysvx1oxx.xwd\dogfood\pr-20867\bin\aspire.exe
• PR packages: D:\tmp\aspire-pr-20867-ysvx1oxx.xwd\hives\pr-20867\packages
• Version evidence: version.txt under the test root.

The published native Windows CLI and downloaded PR packages were used, not a locally modified build. PATH was changed only inside individual testing shell processes; the user's persistent PATH and PowerShell profiles were not modified.

Changes Analyzed

Area	Relevant changes
SDK/build targets	src/Aspire.AppHost.Sdk/SDK/Sdk.in.props, Sdk.in.targets; src/Aspire.Hosting.AppHost/build/*: ASPIRE012, SDK-use marker, required bundle, package-derived host/version defaults, file-based non-AOT behavior
CLI	Init, C# empty scaffolding, AppHost discovery/parser, .NET runner, project updater and localized updater diagnostics
C# templates	Standalone AppHost, empty solution, single-file AppHost, Blazor starter, and React/C# starter
Tests	SDK target tests, template execution, CLI discovery/update and E2E fixtures
Supporting CI	Dotnet runtime-consumer trigger-map additions, test-run-hook suppression, shared test targets, native extension fixture setup
Documentation	Diagnostic list and staged SDK migration guide, including CPM limitations

There are no dashboard/client-product changes. Extension changes are harness/fixture updates, not a new extension product feature. No official Azure Pipelines YAML or signing/publishing change is present.

Commands and Setup

These variables identify the actual installation and fixtures:

$root = 'D:\tmp\aspire-pr-20867-ysvx1oxx.xwd'
$cli = "$root\dogfood\pr-20867\bin\aspire.exe"
$hive = "$root\hives\pr-20867\packages"
$version = '17.0.0-pr.20867.gbb5a4d0c'
$env:PATH = "$(Split-Path $cli);$env:PATH"

The official PR installer was invoked with 20867 -InstallPath $root -SkipExtension -SkipPath: passed. & $cli --version: passed, exact version above.

Fresh CLI projects were generated with the following commands: all passed.

& $cli new aspire-starter --name PrStarter --output "$root\scenarios\PrStarter" --source $hive --version $version --test-framework None --use-redis-cache false --localhost-tld false --suppress-agent-init --non-interactive
& $cli new aspire-empty --language CSharp --name PrFile --output "$root\scenarios\PrFile" --source $hive --version $version --localhost-tld false --suppress-agent-init --non-interactive
& $cli new aspire-ts-cs-starter --name PrReact --output "$root\scenarios\PrReact" --source $hive --version $version --localhost-tld false --suppress-agent-init --non-interactive

Additional legacy migration fixtures used the same starter/empty generation commands with PrLegacy and PrLegacyFile names and distinct output directories.

The actual template package was also installed into a separate custom template hive. These commands passed:

dotnet new install "$hive\Aspire.ProjectTemplates.17.0.0-pr.20867.gbb5a4d0c.nupkg" --debug:custom-hive "$root\template-hive"
dotnet new aspire-apphost --name PrStandalone --output "$root\scenarios\PrStandalone" --no-restore --debug:custom-hive "$root\template-hive"
dotnet new aspire --name PrEmptyProject --output "$root\scenarios\PrEmptyProject" --no-restore --debug:custom-hive "$root\template-hive"
dotnet new aspire-apphost-singlefile --name PrPackagedFile --output "$root\scenarios\PrPackagedFile" --debug:custom-hive "$root\template-hive"

The generated CLI starter NuGet configuration was copied to the direct-dotnet template fixtures so those apps could resolve the same local PR packages. No repository NuGet configuration was edited.

Test Scenarios Executed

1. New project-based templates

Coverage: Happy path and output shape. Status: Passed.

Generated standalone AppHost, empty solution, Blazor starter, and React/C# starter. Programmatic assertions verified each AppHost has Sdk="Microsoft.NET.Sdk" and explicit Aspire.Hosting.AppHost and Aspire.Hosting.Dotnet references. Starter services use AddDotnetProject; none needs the obsolete SDK.

Each AppHost started with aspire start --apphost <path> --isolated --format Json --non-interactive and stopped successfully with aspire stop --apphost <path> --non-interactive. Direct dotnet build for the standalone and React AppHosts passed with zero warnings/errors.

Blazor API/frontend were Healthy. API /weatherforecast returned five forecasts, frontend /weather returned HTTP 200, and the frontend retained Reference/WaitFor edges to the API. aspire resource apiservice rebuild passed; API health and five-forecast HTTP response were verified afterward.

React server/frontend were Healthy/Running, with Reference/WaitFor edges intact. Server /api/weatherforecast returned five forecasts; frontend root returned HTTP 200; frontend /api/weatherforecast proxy returned five forecasts. The npm installer completed with exit code zero.

Empty AppHost dashboards returned HTTP 200. These are HTTP/backend checks, not a claim that browser-rendered frontend pages or Visual Studio were manually exercised.

Evidence: template-shape-assertions.json, starter-create.log, starter-describe.json, starter-http.log, starter-rebuild.log, standalone-build.log, standalone-dashboard.log, empty-project-dashboard.log, react-build.log, react-describe.json, react-http.log.

2. New file-based templates

Coverage: Happy path, output shape, evaluated defaults. Status: Passed.

Both the CLI's C# empty template and the packaged single-file template contain explicit AppHost/Dotnet package directives and no Aspire SDK directive. Both started and served their dashboards successfully.

Added a fresh dotnet new web service to the CLI-generated file AppHost using AddDotnetProject. The service reached Running and returned HTTP 200 with exactly Hello World!.

Evaluated the migrated package-only file AppHost with:

dotnet build .\apphost.cs --nologo -getProperty:PublishAot,IsAspireHost,AspireUseCliBundle,AspireHostingSDKVersion,_AspireAppHostPackageVersion

Passed: PublishAot=false, IsAspireHost=true, AspireUseCliBundle=true, and both version properties equal the actual PR package version. No test-injected IsAspireHost property was used.

Evidence: file-create.log, packaged-file-start.log, packaged-file-dashboard.log, file-resource-describe.json, file-resource-http.log, migrated-file-properties.log.

3. Retained SDK and original project resources

Coverage: Backward compatibility and warning behavior. Status: Passed.

Converted a separate fresh starter fixture to the PR SDK with original service ProjectReference entries and AddProject<Projects.*> calls.

dotnet build .\PrLegacy.AppHost\PrLegacy.AppHost.csproj --nologo: passed, one ASPIRE012 warning, zero errors. SDK package resolution succeeded from the downloaded hive. Both original resources started Healthy and API HTTP returned five forecasts.

These suppression builds passed with zero warnings/errors:

dotnet build .\PrLegacy.AppHost\PrLegacy.AppHost.csproj --no-restore --nologo -p:SuppressAspireAppHostSdkObsoleteWarning=true
dotnet build .\PrLegacy.AppHost\PrLegacy.AppHost.csproj --no-restore --nologo -p:NoWarn=ASPIRE012

A separate SDK-based file fixture used #:sdk, #:project, and AddProject<Projects.LegacyFileService>. It also started and returned HTTP 200/Hello World!.

Evidence: legacy-build.log, legacy-suppress-SuppressAspireAppHostSdkObsoleteWarning.log, legacy-suppress-NoWarn.log, legacy-describe.json, legacy-http.log, legacy-file-describe.json, legacy-file-http.log.

4. Project-based staged migration

Coverage: Migration and resource behavior preservation. Status: Passed.

Migrated the functioning legacy starter by replacing the Aspire SDK with Microsoft.NET.Sdk, retaining explicit AppHost, adding Dotnet, removing resource project references, and changing resource declarations to AddDotnetProject.

Build passed with zero warnings/errors. Both services remained Healthy; API HTTP returned five forecasts. Resource Restart and health recovery succeeded.

Programmatic before/after comparison confirmed the same resource names, Running/Healthy states, HTTP/HTTPS endpoint schemes, and Reference/WaitFor relationships. Dynamic names, ports, and PIDs were deliberately excluded from comparison.

Evidence: migrated-project-build.log, migrated-project-describe.json, migrated-project-http.log, migrated-project-restart.log, migration-resource-comparison.json, migration-invariant-assertion.log.

5. File-based staged migration

Coverage: Migration, rebuild, and non-AOT behavior preservation. Status: Passed.

Migrated the functioning SDK-based file fixture by replacing SDK/project directives with AppHost/Dotnet package directives and using AddDotnetProject.

The same named resource started and returned HTTP 200/Hello World!. aspire resource legacyfileservice rebuild passed; HTTP response was checked again afterward. Package-only AppHost defaults were verified as described in scenario 2.

Evidence: migrated-file-start.log, migrated-file-describe.json, migrated-file-http.log, migrated-file-rebuild.log, migrated-file-properties.log.

6. Package-only discovery and update

Coverage: SDK-free updater compatibility. Status: Passed.

These commands passed:

& $cli update --apphost .\PrStarter.AppHost\PrStarter.AppHost.csproj --channel pr-20867 --yes --non-interactive
& $cli update --apphost .\apphost.cs --channel pr-20867 --yes --non-interactive

Both project and file contents were compared before/after and preserved exactly. The updater persisted PR channel/version configuration and did not restore an Aspire SDK reference. The updated project built with zero warnings/errors; project/file AppHosts subsequently restarted successfully and their resources reached Healthy/Running.

Evidence: starter-update.log, file-update.log, starter-post-update-build.log, starter-post-update-start.log, file-post-update-start.log, generated aspire.config.json files.

7. Required-bundle failure boundaries and recovery

Coverage: Negative/boundary. Status: Passed, expected nonzero outcomes asserted.

For both retained-SDK and package-only AppHosts, building with AspireUseCliBundle=false and NoWarn=ASPIRE010 failed with error ASPIRE010. SDK-warning suppression did not make bundle opt-out legal.

Building the package-only standalone AppHost with a nonexistent AspireCliBundlePath failed with error ASPIRE009 and explicit installation/PATH/property guidance.

Removing those command-line overrides produced a normal successful build with zero warnings/errors. Negative cases did not alter source.

Evidence: legacy-bundle-disabled.log, package-bundle-disabled.log, invalid-bundle.log, bundle-recovery.log.

8. Standard dotnet run entry points

Coverage: Project/file run-hook integration. Status: Startup and runtime passed.

dotnet run --project .\PrStandalone.csproj -- --non-interactive
dotnet run .\apphost.cs -- --non-interactive

Both connected to their AppHosts and started the dashboard using the installed PR CLI. The file resource returned HTTP 200/Hello World!; the project AppHost was discoverable through aspire describe.

Both long-running commands were intentionally stopped using aspire stop; the outer commands subsequently exited with code 1. These are verified startup/runtime checks, not assertions of a zero exit code after external shutdown.

Evidence: project-dotnet-run.log, file-dotnet-run.log, file-dotnet-run-describe.json, file-dotnet-run-http.log.

CI Infrastructure Validation

Source run: 38198464573, attempt 4, exact PR head, success. Existing CI coverage was inspected rather than unnecessarily rerunning already-covered unit suites.

Downloaded and parsed actual TRX artifacts:

Scope	Result	Evidence
Infrastructure.Tests, Linux	1,546 passed, 0 failed, 0 skipped	job 114656753015, ci-artifacts\infrastructure
Hosting.Sdk, Windows	81 passed, 0 failed, 2 Unix-only cases skipped	job 114656743882, ci-artifacts\sdk-windows
BuildAndRunTemplateTests, Windows	5 passed, 0 failed, 0 skipped	job 114656755101, ci-artifacts\templates-windows
Native starter qualification, Windows x64	Success; log confirms exact-head package generation and running resources	job 114656749164, ci-starter-windows.log

The TRX explicitly records passing deprecation/suppression and file-AOT cases, plus both DotnetProjectResourceChangesRunGeneratedAppHostConsumers tests, with and without ProjectGraph.

Dependency/routing inspection: New AppHost templates consume Dotnet at runtime. Trigger-map additions cover template tests, CLI E2E, starter validation, and extension E2E through affected-project and fallback path rules. Changes add routing rather than remove an execution lane. Existing package production feeds downloaded managed/RID packages into template/CLI tests; the extension harness prepares a complete native bundle under its isolated home. Shared RepoTesting changes preserve MTP execution by suppressing the AppHost run hook for test projects rather than disabling the bundle.

Failure-mode scan: Checked fallback routing without ProjectGraph, runtime-only package consumption, MTP-versus-AppHost run behavior, complete native fixture bundle requirements, and Windows bundle/project execution. No workflow trigger, permission, fork policy, action-pin, or gh-aw lock change is present. No workflow dispatch or official AzDO run was needed for this focused product qualification. Extension-wide and deployment suites were not independently requalified locally.

Artifacts: ci-infrastructure.log, ci-sdk-windows.log, ci-templates-windows.log, ci-starter-windows.log, ci-trx-summary.json, and downloaded TRX/binlog artifacts under ci-artifacts.

Known Limitations and Harness Notes

• CPM remains a documented limitation: Generated explicit package versions require manual central-package adjustment under ManagePackageVersionsCentrally; otherwise NU1008 can occur, even with matching central versions. This expanded limitation is explicitly documented in the PR. It was not independently exercised here and this report does not claim out-of-box CPM support.
• SDK retention was tested with the PR SDK/package version, not every older released SDK/CLI combination.
• Local .NET SDK was an 11.0 preview, with net10.0 target projects. This is not separate local qualification of stable-SDK-only or Visual Studio launch/debug behavior.
• HTTP checks against local HTTPS development endpoints used -SkipCertificateCheck. HTTP-only service/proxy checks used normal validation. No NuGet audit-disable or feed workaround was needed.
• No browser screenshots were captured; there is no dashboard styling change. Dashboard HTTP and structured resource/health/relationship observations were captured instead.
• Initial harness invocations used an incorrect direct-dotnet empty-template short name, supplied two resource arguments to a single-resource wait command, and guessed React resource names/route. These were corrected to aspire, individual waits, server/webfrontend, and /api/weatherforecast. Corrected scenarios passed; these were not product defects.
• Process cleanup was rechecked after the short asynchronous shutdown delay; no task-owned AppHost/detached CLI PID remained.
• Analysis used exact-head fetched source/diff; the testing worktree was not force-reset or rebased onto the PR. No repository source was edited.

Summary

Scenario	Status	Key evidence
PR native CLI and retained SDK availability	Passed	Exact commit/version; SDK restore/build
Four project-based template variants	Passed	Microsoft.NET.Sdk, explicit packages, successful startup
Two file-based template variants	Passed	No SDK directive, package defaults, working .NET resource
SDK legacy compatibility and suppression	Passed	Original AddProject resources and documented ASPIRE012 suppression
Project migration	Passed	HTTP, restart, identical normalized resource relationships
File migration	Passed	HTTP, rebuild, non-AOT defaults
Package-only discovery/update	Passed	Source preserved; no SDK reintroduced; restart succeeds
Bundle negative cases and recovery	Passed	Unsuppressible ASPIRE010; actionable ASPIRE009; normal build recovery
Standard dotnet run	Startup/runtime passed	Live AppHosts and resource HTTP; intentionally externally stopped
Focused CI artifact inspection	Passed	Actual TRX results, exact-head starter logs, fallback routing tests

Overall Result

Passed for the requested Windows SDK-retention, migration, and SDK-free project/file-template scope. No product defect was found in these exercised scenarios.

This does not establish universal compatibility, out-of-box CPM support, Visual Studio qualification, or acceptance of official post-merge daily artifacts.

Artifacts, Posting, and Cleanup

• All local logs/apps: D:\tmp\aspire-pr-20867-ysvx1oxx.xwd
• Persistent report: C:\Users\dedward\.copilot\session-state\36556d3b-ad98-45f1-a8bc-fc4db58eb7d5\files\pr-20867-testing-report.md
• PR comment: Posting explicitly authorized by the user.
• Process cleanup: All task-owned AppHosts and detached CLI processes stopped and known PIDs checked absent.
• Workspace retention: Installation, apps, and evidence retained for the user's requested manual verification. No container was used.

[Damian Edwards (DamianEdwards)]

Manual Visual Studio verification of the retained-SDK and package-only C# AppHost examples using 17.0.0-pr.20867.gbb5a4d0c (bb5a4d0cd343c7c7cadfe7316a4430bd6a47b643) surfaced these non-blocking follow-up discoveries:

Follow-up	Tracking
Windows DCP orchestration logging fails while applying the logging socket directory's ACL. It occurs with and without the SDK; resources can still start because the logging setup exception is caught.	Existing issue #20606, with additional confirmation rather than a duplicate issue.
Switching to Microsoft.NET.Sdk loses the web-style Solution Explorer nesting of appsettings.Development.json under appsettings.json. The AppHost package should preserve the SDK's nesting capabilities; also audit the SDK-only AspireOrchestration capability.	#20934
Template-generated AddDotnetProject calls should use the shorter supported project-directory path, with a trailing slash, rather than the full .csproj path.	#20933

The initial warning concern was clarified, so no defect issue was filed for it: ASPIRE012 appears when Error List is opened, and <WarningsAsErrors>ASPIRE012</WarningsAsErrors> promotes it to an error. TreatWarningsAsErrors alone covers compiler warnings, not this MSBuild-emitted warning; MSBuildTreatWarningsAsErrors is the documented project-level opt-in for all unsuppressed MSBuild warnings.

One correction to the earlier automated testing report: the DCP logging failure was already present in its captured logs but was missed in the initial analysis. The successful startup/HTTP checks remain valid, but they did not qualify orchestration logging as working.

These findings are follow-up work, not blockers for this PR.

[Damian Edwards (DamianEdwards)]

Approving after manual Visual Studio verification of the retained-SDK and package-only AppHost examples at bb5a4d0. Current checks are complete with no failures, and the latest Copilot review reports zero open findings. The discoveries documented in #20867 (comment) are non-blocking follow-ups.