Refactor serverReadyAction handling

[dkattan]

Motivation

Aspire 13 improved debugging for child processes; this change extends that all the way to the browser. Before this PR, a serverReadyAction supplied on the Aspire launch config was overwritten by a hard-coded default:

{
	"action": "openExternally",
	"pattern": "\\bNow listening on:\\s+https?://\\S+",
	"uriFormat": "..."
}

That prevented browser breakpoint debugging and custom URL capture patterns. In this PR we honor the supplied serverReadyAction, so browser debugging can be triggered correctly (e.g., debugWithChrome / debugWithEdge) with a custom pattern and uriFormat.

Changes

• Add a typed ServerReadyAction to DCP types and expose it on AspireExtendedDebugConfiguration.
• Note that VS Code does not export ServerReadyAction and link to its canonical definition.
• Centralize serverReadyAction inheritance/selection inside determineServerReadyAction.
• Pass parentDebugConfiguration into determineServerReadyAction from the .NET debugger.
• Update tests for the new behavior and URL-capture pattern.

Tests

• launchProfiles.test.ts
• dotnetDebugger.test.ts

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

Or

• Run remotely in PowerShell:

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

[dkattan]

@dkattan please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.

@dotnet-policy-service agree [company="{your company}"]

Options:

• (default - no company specified) I have sole ownership of intellectual property rights to my Submissions and I am not making Submissions in the course of work for my employer.

@dotnet-policy-service agree

• (when company given) I am making Submissions in the course of work for my employer (or my employer has intellectual property rights in my Submissions by contract or applicable law). I have permission from my employer to make Submissions and enter into this Agreement on behalf of my employer. By signing below, the defined term “You” includes me and my employer.

@dotnet-policy-service agree company="Microsoft"

Contributor License Agreement

@dotnet-policy-service agree

[Copilot]

Pull request overview

This PR refactors the serverReadyAction handling in the VS Code extension to honor user-specified server ready actions from the Aspire launch configuration, enabling browser debugger attachment (e.g., debugWithChrome, debugWithEdge) and custom URL patterns. Previously, a hard-coded default configuration would overwrite any user-supplied settings.

Changes:

• Added ServerReadyAction type definition and exposed it on AspireExtendedDebugConfiguration
• Refactored determineServerReadyAction to accept options and inherit from parent debug configuration
• Updated pattern to use capture groups ((https?://\\S+)) for proper URL substitution with %s format

Reviewed changes

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

Show a summary per file

File	Description
extension/src/dcp/types.ts	Added ServerReadyAction type and parentDebugConfiguration field to LaunchOptions and AspireExtendedDebugConfiguration
extension/src/debugger/launchProfiles.ts	Refactored determineServerReadyAction to accept options object and support parent configuration inheritance
extension/src/debugger/languages/dotnet.ts	Updated call to determineServerReadyAction to pass parentDebugConfiguration from launchOptions
extension/src/test/launchProfiles.test.ts	Updated tests to use new API and added cross-platform path handling
extension/src/test/dotnetDebugger.test.ts	Updated assertions to match new serverReadyAction behavior with capture groups

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

[dkattan]

Should we actually gate this on launchSettings.json's launchBrowser property?

launchSettings.json (IMO) is a relic from Visual Studio

launch.json (IMO) is the "VS Code" way

I know that's an over-simplification and that we are conceptually layering them so launch.json -> launchSettings.json -> target project

I guess my point is it took me a while to realize that both applicationUrl and launchBrowser both needed to be specified before I could have the privilege of using the hardcoded serverReadyAction.

I don't want other VS Code purists to get frustrated that their serverReadyAction isn't working because a setting for Visual Studio isn't specified.