Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -131,6 +131,25 @@ All of these commands are debuggable; you can step into custom publishers and de

The `debuggers` property forwards configuration to specific debuggers. Recognized keys are: `apphost`, `project` (C#/.NET), `node`, `python`, `browser`, and `azure-functions`.

For `project`, the extension normally generates a `serverReadyAction` from the project's `launchSettings.json` to automatically open the browser when the server is ready. Set `debuggers.project.serverReadyAction` explicitly to override this generated default with your own action and pattern:

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Contradicted on release/13.5. This paragraph says a user can override the generated default, but on this branch that override is discarded for project resources. In extension/src/debugger/debuggerExtensions.ts:51-78 the user's debuggers.project (including serverReadyAction) is merged into the debug configuration before the .NET callback runs; then extension/src/debugger/languages/dotnet.ts:451-452 unconditionally reassigns serverReadyAction = determineServerReadyAction(...) for every non-AppHost project, overwriting the user value. The guard that preserves an explicitly-configured value only exists on main (dotnet.ts comment: "A serverReadyAction the user configured explicitly in launch.json is still respected … never overwritten here"), where the extension also no longer generates one from launchSettings.json at all. So on release/13.5 this describes behavior that doesn't ship yet — retarget to the release carrying microsoft/aspire#19200, or hold until it lands on release/13.5.

(Note: the override does survive for the AppHost, because dotnet.ts:451 skips the generated action when isApphost — which is why the AppHost note below is accurate. But the "override this generated default" scenario is the project case, where it's overwritten.)


Comment thread
ellahathaway marked this conversation as resolved.
:::note[AppHost behavior]
A .NET AppHost also uses the `project` debugger, so `debuggers.project.serverReadyAction` is included in its debug configuration. If you set both `debuggers.apphost.serverReadyAction` and `debuggers.project.serverReadyAction`, the `project` value takes precedence.
:::

```json title=".vscode/launch.json — override debuggers.project.serverReadyAction"
{
"debuggers": {
"project": {
"serverReadyAction": {
Comment thread
ellahathaway marked this conversation as resolved.
"action": "openIntegratedBrowser",

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

openIntegratedBrowser can't be verified as a valid action. It has zero occurrences in microsoft/aspire@release/13.5, and the extension's own ServerReadyAction type (extension/src/debugger/launchProfiles.ts:362-366) declares action: "openExternally" — which is also the only action the extension ever generates (launchProfiles.ts:380). serverReadyAction is ultimately consumed by VS Code core, but nothing in the Aspire extension produces or recognizes openIntegratedBrowser, so this example is likely to mislead. Consider using openExternally (the value the generated default uses), or documenting the exact set of supported action values.

"pattern": "\\bNow listening on:\\s+(https?://\\S+)"
}
Comment thread
ellahathaway marked this conversation as resolved.
}
}
}
```

Finally, you can specify `env` and `args` to set environment variables and command-line arguments for the AppHost process.

```json title=".vscode/launch.json — deploy with debugger settings, env, and args"
Expand Down
Loading