[release/13.4] Fix resource service port collision in --isolated mode#18341
Conversation
When running multiple instances with --isolated, the AppHost's dashboard, resource service, and OTLP endpoints all tried to bind to the same fixed ports from the launch profile/user secrets. Fix by clearing port-bearing env vars (ASPNETCORE_URLS, ASPIRE_RESOURCE_SERVICE_ENDPOINT_URL, and ASPIRE_DASHBOARD_OTLP_*_ENDPOINT_URL) in ConfigureIsolatedModeAsync so the AppHost falls back to OS-assigned random ports. Also suppress the launch profile in the dotnet-run fallback path when isolated, so the fixed ports from the profile don't leak through.
…env vars" This reverts commit 4dc855d.
… true When DcpPublisher:RandomizePorts is enabled (e.g. --isolated mode), the DashboardServiceHost now ignores the fixed port from ASPIRE_RESOURCE_SERVICE_ENDPOINT_URL and binds to port 0 instead. This allows multiple isolated instances of the same project to run concurrently without port conflicts on the resource service endpoint.
|
🚀 Dogfood this PR with:
curl -fsSL https://github.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 18341Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 18341" |
|
Retrying the failed CI jobs for this pull request from the CI run attempt. The rerun is being tracked in the rerun attempt. |
|
✅ No documentation update needed. docs_optional → bug_fix_restores_documented_behavior No signals were triggered ( The existing
The bug was that |
Backport of #18332 to release/13.4
/cc @davidfowl @JamesNK
Customer Impact
Testing
Risk
Regression?