You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Preserve package-only AppHost nesting and use starter directory paths - #20958
Follow up on merged #20867 for #20933 and #20934, keeping the obsolete SDK functional while preserving the package-only AppHost experience.
Supply DynamicFileNesting and DynamicFileNestingEnabled from Aspire.Hosting.AppHost only when IsAspireHost=true. Guard both package and legacy SDK declarations independently so either import order, including preexisting capabilities, produces one of each.
Use trailing-slash project-directory paths for the Blazor starter's API/frontend and the React/C# starter's server. Preserve resource names, template substitutions, and chained configuration.
Add regression coverage for capability occurrence counts/import orders, project and file-based evaluation fixtures, non-AppHosts, generated starter paths with Redis on/off, and absolute/relative project discovery with/without trailing slashes.
Update the SDK migration guide with the package-owned nesting capabilities and supported directory-path form.
AspireOrchestration remains SDK-owned. No repository consumer of that project capability was found; its external Visual Studio impact is unknown and this PR does not invent a fix. No public API, diagnostic suppression, transport default, project-reference compatibility, or central package management behavior changes.
Addresses #20933 and #20934. No companion repository change is required for these source fixes.
Fresh validation and draft limitations
Final head 3d83580ff7ff36361a83ac6609e9c75782b4a305, based on upstream da9f076de522c5638d685e729c2d93ec7d4a0be6. The standalone checks were rerun on that committed head using the repository-pinned .NET SDK 11.0.100-rc.1.26425.128 on Linux.
Passed; downloaded exact-head built-nugets, version 17.0.0-pr.20958.g3d83580f
Shipped SDK/AppHost targets from those packages
Passed another 32 import-order/preexisting-capability cases, 2 non-AppHost cases, and 3 actual .cs file-based evaluations; exact nesting counts and file-based PublishAot=false asserted
Shipped template pack
Passed 8 generated Blazor/React/Redis/name variants, exact package version substitutions, all directory strings and trailing slashes, and source-resolver discovery for all 12 paths
Linux: 4 succeeded, 0 skipped/failed. MSTest/NUnit/xUnit generated tests start the AppHost, await healthy webfrontend, and assert HTTP 200 from /; their nested test results are preserved in the job artifact
Linux jobs passed; C#/React checks AppHost startup, not a server HTTP response
Patch hygiene
git diff --check passed
Repository SDK test-project build and one standard retry
Blocked during restore by NU1900/NU1905; data.nuget.org DNS resolution failed
Local targeted Aspire.Hosting.Sdk.Tests, Aspire.Hosting.Dotnet.Tests, and Aspire.Templates.Tests execution
All blocked during restore by the same audit-feed errors; local execution is not claimed
The initial standalone checks use token-rendered source targets. The additional packaged checks use the actual final-head .nupkg targets/props through explicit imports, not a NuGet restore of file-based AppHosts. Both 32-case matrices include simulated FileBasedProgram=true projects and are supplemented by actual .cs file-based SDK evaluation. Standalone template generation skips restore; CI's package-based template suites restore/build/run generated projects. The source-resolver executable is not a substitute for the passing full Dotnet suites.
Remaining limits: Windows/Visual Studio GUI Solution Explorer nesting was not verified; Windows CI capability/build tests are not a GUI pass. The React/C# server's actual HTTP response and file-based #:package restore/startup were not separately exercised. The full outerloop browser suite was excluded by normal PR CI. No launch-profile/transport changes are included or implied. Local restore still fails audit DNS; NuGet audit, warning severity, TLS, and shared DNS settings were not weakened.
The final-head CI run is not wholly green: while the scoped suites above pass, the Windows extension suite failed with EPERM opening a notification-claim file, and AzureFunctionsTests.AddAzureFunctionsProject_WorksWithMultipleProjects failed with TaskCanceledException during StopAsync. Those failures are outside the edited surfaces; baseline status has not been established. Other jobs are still running. Keep this source PR in draft; integrated acceptance and GUI qualification remain separate obligations.
The superseded initial-head run caught a compile error in my new Dotnet test fixture: DistributedApplicationOptions.ProjectDirectory is the supported option, not AppHostDirectory. The second commit corrects it and the final-head Dotnet suites now pass on both platforms. Initial-head results and prior-worker historical evidence are not counted as final-head acceptance.
Checklist
Is this feature complete?
Yes. Ready to ship.
No. Follow-up changes expected.
Are you including unit tests for the changes and scenario tests if relevant?
Yes
No
Did you add public API?
Yes
If yes, did you have an API Review for it?
Yes
No
Did you add <remarks /> and <code /> elements on your triple slash comments?
Yes
No
No
Does the change make any security assumptions or guarantees?
Yes
If yes, have you done a threat model and had a security review?
Correct the test fixture option identified by fresh Linux and Windows CI compilation.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This test reads Aspire.Hosting.AppHost.in.targets directly from the repository, but eng/github-ci/test-trigger-map.yml does not route src/Aspire.Hosting.AppHost/** changes to test:Aspire.Hosting.Sdk.Tests, and the test project has no ProjectReference to that package. Future edits to the target can therefore skip this regression test. Add a path rule for the consumed AppHost build inputs and focused selector coverage.
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
needs-area-labelAn area label is needed to ensure this gets routed to the appropriate area owners
2 participants
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.
github-actions
Bot
added
the
needs-area-label
Description
Follow up on merged #20867 for #20933 and #20934, keeping the obsolete SDK functional while preserving the package-only AppHost experience.
DynamicFileNestingandDynamicFileNestingEnabledfromAspire.Hosting.AppHostonly whenIsAspireHost=true. Guard both package and legacy SDK declarations independently so either import order, including preexisting capabilities, produces one of each.AspireOrchestrationremains SDK-owned. No repository consumer of that project capability was found; its external Visual Studio impact is unknown and this PR does not invent a fix. No public API, diagnostic suppression, transport default, project-reference compatibility, or central package management behavior changes.Addresses #20933 and #20934. No companion repository change is required for these source fixes.
Fresh validation and draft limitations
Final head
3d83580ff7ff36361a83ac6609e9c75782b4a305, based on upstreamda9f076de522c5638d685e729c2d93ec7d4a0be6. The standalone checks were rerun on that committed head using the repository-pinned .NET SDK11.0.100-rc.1.26425.128on Linux..csevaluation with source props/rendered targetsIsAspireHost=true, andPublishAot=falseProjectPathResolver, linked into a dependency-free executablebuilt-nugets, version17.0.0-pr.20958.g3d83580f.csfile-based evaluations; exact nesting counts and file-basedPublishAot=falseasserted/; their nested test results are preserved in the job artifactgit diff --checkpassedNU1900/NU1905;data.nuget.orgDNS resolution failedAspire.Hosting.Sdk.Tests,Aspire.Hosting.Dotnet.Tests, andAspire.Templates.TestsexecutionThe initial standalone checks use token-rendered source targets. The additional packaged checks use the actual final-head
.nupkgtargets/props through explicit imports, not a NuGet restore of file-based AppHosts. Both 32-case matrices include simulatedFileBasedProgram=trueprojects and are supplemented by actual.csfile-based SDK evaluation. Standalone template generation skips restore; CI's package-based template suites restore/build/run generated projects. The source-resolver executable is not a substitute for the passing full Dotnet suites.Remaining limits: Windows/Visual Studio GUI Solution Explorer nesting was not verified; Windows CI capability/build tests are not a GUI pass. The React/C# server's actual HTTP response and file-based
#:packagerestore/startup were not separately exercised. The full outerloop browser suite was excluded by normal PR CI. No launch-profile/transport changes are included or implied. Local restore still fails audit DNS; NuGet audit, warning severity, TLS, and shared DNS settings were not weakened.The final-head CI run is not wholly green: while the scoped suites above pass, the Windows extension suite failed with
EPERMopening a notification-claim file, andAzureFunctionsTests.AddAzureFunctionsProject_WorksWithMultipleProjectsfailed withTaskCanceledExceptionduringStopAsync. Those failures are outside the edited surfaces; baseline status has not been established. Other jobs are still running. Keep this source PR in draft; integrated acceptance and GUI qualification remain separate obligations.The superseded initial-head run caught a compile error in my new Dotnet test fixture:
DistributedApplicationOptions.ProjectDirectoryis the supported option, notAppHostDirectory. The second commit corrects it and the final-head Dotnet suites now pass on both platforms. Initial-head results and prior-worker historical evidence are not counted as final-head acceptance.Checklist
<remarks />and<code />elements on your triple slash comments?🤖 Posted by Mona (AI Agent)