Skip to content

Add, respect auto-open aspire dashboard setting. Open the first application url in dotnet projects if multiple are provided#12674

Merged
adamint merged 6 commits intodotnet:mainfrom
adamint:dev/adamint/fix-server-ready-actions
Nov 5, 2025
Merged

Add, respect auto-open aspire dashboard setting. Open the first application url in dotnet projects if multiple are provided#12674
adamint merged 6 commits intodotnet:mainfrom
adamint:dev/adamint/fix-server-ready-actions

Conversation

@adamint
Copy link
Member

@adamint adamint commented Nov 4, 2025

Description

I noticed yesterday that server ready actions weren't working as I'd expect when there are multiple URLs in the applicationUrls property. The first should be opened. After a question from Tommaso, I also investigated and found that the dashboard was not auto-opening because of the same issue.

To allow opting out of launching the dashboard, I added a new VS Code setting (aspire.enableAspireDashboardAutoLaunch), which is true by default. If true, the launch aspire dashboard informational message no longer appears, as it would be redundant.

cc @tommasodotNET

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?
        • Yes
        • No
    • No
  • Does the change require an update in our Aspire docs?

@github-actions
Copy link
Contributor

github-actions bot commented Nov 4, 2025

🚀 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/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 12674

Or

  • Run remotely in PowerShell:
iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 12674"

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR adds a new configuration option aspire.enableAspireDashboardAutoLaunch to control whether the Aspire Dashboard automatically opens in the browser when debugging an Aspire apphost. When set to false, the dashboard won't auto-launch, and an informational message prompts the user to manually open it.

Key Changes

  • Added new VS Code setting aspire.enableAspireDashboardAutoLaunch (default: true) to control dashboard auto-launch behavior
  • Modified displayDashboardUrls to conditionally show info message based on the new setting
  • Updated determineServerReadyAction to handle multiple URLs separated by semicolons by selecting the first URL
  • Conditional logic in dotnet debugger to respect the auto-launch setting for apphost projects

Reviewed Changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 4 comments.

Show a summary per file
File Description
extension/package.json Added new boolean configuration property for dashboard auto-launch control
extension/package.nls.json Added localization key for the new configuration description
extension/loc/xlf/aspire-vscode.xlf Added localization translation unit for the new setting
extension/src/server/interactionService.ts Added conditional logic to skip info message when auto-launch is enabled
extension/src/debugger/languages/dotnet.ts Added conditional serverReadyAction based on auto-launch setting for apphost projects
extension/src/debugger/launchProfiles.ts Enhanced URL handling to extract first URL from semicolon-separated list
extension/src/test/rpc/interactionServiceTests.test.ts Updated tests to verify behavior with both auto-launch enabled and disabled
extension/src/test/launchProfiles.test.ts Added test for semicolon-separated URL handling
Comments suppressed due to low confidence (1)

extension/src/debugger/launchProfiles.ts:206

  • This use of variable 'applicationUrl' always evaluates to true.
    let uriFormat = applicationUrl && applicationUrl.includes(';') ? applicationUrl.split(';')[0] : applicationUrl;

adamint and others added 4 commits November 4, 2025 13:42
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>

if (launchOptions.isApphost) {
// The Aspire dashboard URL will be set as the apphost's application URL. Check if auto-launch is enabled
const enableDashboardAutoLaunch = vscode.workspace.getConfiguration('aspire').get<boolean>('enableAspireDashboardAutoLaunch', true);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a way to have this check in a single spot? that way:

  1. We don't have duplicate code
  2. how expensive is this check?

Copy link
Member Author

@adamint adamint Nov 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I can put getters for getConfiguration calls into workspace.ts!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked into this more and it doesn’t seem like that’s a common pattern in most extensions. I may keep for now? If the amount of settings grows we may benefit from some sort of setting manager

const enableDashboardAutoLaunch = vscode.workspace.getConfiguration('aspire').get<boolean>('enableAspireDashboardAutoLaunch', true);

if (enableDashboardAutoLaunch) {
debugConfiguration.serverReadyAction = determineServerReadyAction(baseProfile?.launchBrowser, baseProfile?.applicationUrl);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(nit) is there a way to refactor the logic so we only need to set debugConfiguration.serverReadyAction in a single spot?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's definitely possible, but seemingly not without computing enableDashboardAutoLaunch even when it is not necessary or having a variable at the scope of enableDashboardAutoLaunch that serverReadyAction is then set to

Copy link
Member

@eerhardt eerhardt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@adamint adamint merged commit c26bce0 into dotnet:main Nov 5, 2025
582 of 585 checks passed
@dotnet-policy-service dotnet-policy-service bot added this to the 13.1 milestone Nov 5, 2025
@github-actions github-actions bot locked and limited conversation to collaborators Dec 6, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants