Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhance support for configuring debuggers used for Blazor WASM apps #2774

Merged
merged 4 commits into from
Nov 30, 2020

Conversation

captainsafia
Copy link
Member

Summary of the changes

  • Adds support for passing underlying config to JS and .NET debuggers
    • Allows users to customize the hosted .NET debugger more fully
    • Allows users to configure prelaunch tasks for standalone server (for example, launching a local Azure Functions app)
  • Always launch .NET app using debugger to support passing custom config
    • Update clean up logic to check for standalone server launch from .NET debugger
    • Update config name for app launched via .NET debugger

Fixes: dotnet/aspnetcore#27518, dotnet/vscode-csharp#4161, dotnet/vscode-csharp#4108

},
"browserConfig": {
"description": "Options based",
"type": "object"
Copy link
Contributor

Choose a reason for hiding this comment

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

Is it just an object because it's a generic key=>value dictionary with no structure?

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 does have a structure. It should only contain the properties that you would pass to the JS debugger (or .NET debugger in the case above). I'll add docs to clarify this.

We could copy/paste the entire config setup for the .NET/JS debuggers here but that didn't seem sustainable.

Copy link
Contributor

Choose a reason for hiding this comment

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

I feel like you'll probably get some push back on this only because users will be "off on their own" to setup these configuration options. VSCode users typically rely heavily on IntelliSense to configure things like this

Copy link
Member Author

Choose a reason for hiding this comment

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

Hmmmmm. Good point. I'll strike a balance by including the options that users are more likely to use here.

Copy link
Contributor

@ryanbrandenburg ryanbrandenburg left a comment

Choose a reason for hiding this comment

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

LGTM though my area knowledge is weak here.

@@ -114,6 +89,7 @@ export class BlazorDebugConfigurationProvider implements vscode.DebugConfigurati
inspectUri: '{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}',
trace: configuration.trace || false,
noDebug: configuration.noDebug || false,
...configuration.browserConfig,
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we need a separate category of #PranavPoints for Typescript?

@captainsafia captainsafia merged commit a76afe2 into master Nov 30, 2020
@captainsafia captainsafia deleted the safia/dbgr-fixes branch November 30, 2020 22:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Attaching webassembly debugger causes a second copy of the app to start
4 participants