Fix config discovery to search from apphost directory and add aspire.config.json to .NET templates#15423
Conversation
Adds a test that verifies aspire.config.json is discovered adjacent to the apphost file when running from a parent directory, rather than being recreated in the current working directory. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 15423Or
iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 15423" |
When an apphost is found via recursive search, use its directory as the search root for aspire.config.json (walking upward) instead of defaulting to CWD. This prevents creating a duplicate config when the user runs 'aspire run' from a parent directory after 'aspire new'. Changes: - Add ConfigurationHelper.FindNearestConfigFilePath helper - ProjectLocator.CreateSettingsFileAsync: skip creation when config already exists near the apphost with valid appHost.path - GuestAppHostProject.GetConfigDirectory: search from apphost directory so launch profiles are read from the correct config Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The previous check skipped creation whenever any appHost.path existed, which broke config healing when the path was stale/invalid. Now we resolve the stored path and only skip if it points to the same apphost that was discovered via recursive search. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Fixes aspire.config.json discovery so running aspire run from a parent directory uses the config adjacent to the discovered apphost instead of creating a new config in the current working directory.
Changes:
- Adds a helper to locate the nearest
aspire.config.json(or legacy.aspire/settings.json) by walking upward from a specified directory. - Updates config discovery logic in
ProjectLocatorandGuestAppHostProjectto start searching from the apphost directory. - Adds an end-to-end test to cover the “run from parent directory” scenario.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| tests/Aspire.Cli.EndToEnd.Tests/ConfigDiscoveryTests.cs | Adds E2E coverage for discovering existing config near the apphost when running from a parent directory. |
| src/Aspire.Cli/Utils/ConfigurationHelper.cs | Introduces upward-walking helper to find the nearest config (new or legacy). |
| src/Aspire.Cli/Projects/ProjectLocator.cs | Changes settings/config creation behavior to consult config near the apphost first. |
| src/Aspire.Cli/Projects/GuestAppHostProject.cs | Aligns config directory selection with “search from apphost directory” behavior. |
Include aspire.config.json with appHost.path in the aspire-apphost (csproj) and aspire-apphost-singlefile templates so that aspire run from a parent directory finds the config adjacent to the apphost instead of creating a spurious one in the working directory. The csproj template uses sourceName 'Aspire.AppHost1' so the template engine substitutes the actual project name automatically. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Add aspire.config.json at the solution root for aspire-empty, aspire-starter, and aspire-ts-cs-starter templates. Each points to the AppHost csproj via a relative path. The template engine substitutes the sourceName so the path matches the actual project name chosen by the user. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
JamesNK
left a comment
JamesNK
left a comment
There was a problem hiding this comment.
Overall the approach is sound — searching from the apphost directory upward instead of CWD is the right fix. A few issues noted inline, the most significant being that the CreateSettingsFileAsync early-return doesn't handle the legacy .aspire/settings.json case correctly.
|
I thought creating a file like this (at least when it was Also, is creating this file skipped when there are multiple app hosts and one has to be picked? I thought it was created then to avoid having to select the app host you wanted each time you aspire run/start. |
mitchdenny
changed the title
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
cc @DamianEdwards @maddymontaquila @joperezr @radical — looking for your input on the template changes specifically. Why we're adding
|
Just but I think with the shift to |
- Fix legacy .aspire/settings.json path handling in ProjectLocator: resolve config root to parent of .aspire/ directory - Update GetConfigDirectory XML doc to reflect new behavior - Remove unused _configurationService field and constructor parameter - Assert originalContent == currentContent in E2E test Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Addressed all review feedback from @JamesNK and Copilot in 46e5a59:
All 1,701 CLI unit tests pass locally. |
|
🎬 CLI E2E Test Recordings — 54 recordings uploaded (commit View recordings
📹 Recordings uploaded automatically from CI run #23332903707 |
|
@mitchdenny we should make |
joperezr
left a comment
joperezr
left a comment
There was a problem hiding this comment.
Validated this works. Thanks @mitchdenny!
Description
When a user runs
aspire newfollowed byaspire runfrom the parent directory (withoutcd-ing into the created project), the CLI creates a spuriousaspire.config.jsonin the current working directory instead of using the one adjacent to the discovered apphost. This happens because config discovery searches upward from CWD rather than from the apphost's directory.Changes:
Fix config discovery to search from apphost directory — Added
ConfigurationHelper.FindNearestConfigFilePath()helper that searches upward from a given directory. UpdatedProjectLocator.CreateSettingsFileAsyncandGuestAppHostProject.GetConfigDirectoryto search from the apphost's directory rather than CWD.Handle stale config paths — Only skip config creation when the stored
appHost.pathresolves to the same apphost that was discovered. If the path is stale/invalid, fall through so the config gets healed.Add
aspire.config.jsonto all .NET apphost templates — The CLI's TypeScript templates already includedaspire.config.json, but the .NET SDK templates did not. Added minimalaspire.config.json(withappHost.path) to all five .NET templates:aspire-apphost(csproj)aspire-apphost-singlefileaspire-empty(solution)aspire-starter(solution)aspire-ts-cs-starter(solution)The template engine's
sourceNamesubstitution ensures the path matches the actual project name chosen by the user.E2E test —
ConfigDiscoveryTestscreates a TypeScript Empty AppHost viaaspire new, stays in the parent directory, runsaspire run, and asserts that no config leaks to CWD and the subdirectory config is preserved.Checklist