-
Notifications
You must be signed in to change notification settings - Fork 10.4k
Description
I investigated adding launch.json and tasks.json configurations to VSCode to enable a one step solution to running your Blazor WASM project which looks like:
The drawbacks of this solution was:
- The user gets a ton of pretty complex/advanced/fragile code added to their launch.json and tasks.json files in VSCode
- If the debugger fails to attach you end up left with an orphaned Blazor dev server locking all your files/reserving the port that you need to manually go kill in the Terminal window of VSCode.
Soooo the solution would be to add a debug adapter to encapsulate all of this functionality much like how the debugger team has added a "coreclr" debug type.
After talking with some debugger folks the suggestion verbatim was:
I think the cleanest way would to have an extension (perhaps the C# extension, or a Blazor extension) provide its own debug type and trigger js-debug from that. That would let you hide the internals from where users would see it, need to configure it, and/or accidentally mess it up.
When a debug session starts, the configuration is passed to the DebugConfigurationProvider to give it the opportunity to provide configuration. This interface has the ability to return “undefined” which cancels the launch. What you could do is have a stub debug configuration provider for the “blazor” debug type, cancel the launch in the DebugConfigurationProvider, start your server, and call vscode.debug.startDebugging with a fulfilled set of configuration options for js-debug. If you have extension code in place like this, you could use the onDidTerminateDebugSession event to year down the background server.