Implement "attach" property support for Blazor debug extension

[captainsafia]

This issue depends on the changes introduced in dotnet/razor#1885.

Currently, the Blazor debugger supports the launch property, meaning it starts a new dev server and browser from scratch.

Launch configurations can also support an attach option. For example, the VS Code Chrome debug extension will attach to an existing browser (enabled with debugging) that is set to the same URL the user is targetting.

[captainsafia]

The implementation for this will assume that a user has:

• Already configured the inspectUri in their launch settings correctly
• Is running the application server on their machine
• The user has already launched Chrome/Edge with the remote-debugging flags enabled

The requirements above are a mix of what our dev server needs and what the underlying JS debugger expects.

The attach configuration for the Blazor debugger will look something like this. The attach configuration will accept the same configuration attributes as the launch configuration.

{
  type: "blazorwasm",
  request: "attach",
  browser: "edge"
}

Under the hood, this configuration will not spawn a process for the devserver and will launch the browser in attach mode. Unlike launch mode, attach mode will not clean up the devserver processes on the system. I think it is sensible to expect if it is not launched from the debugger, it doesn't need to be cleaned up by the debugger.

[captainsafia]

A conversation with @SteveSandersonMS has me re-thinking this a bit.

The interpretation of "attach" that I used above relies on a literal mapping of how attach currently works in the JS debug adapter.

In actuality, a user using the "blazorwasm" debug adapter to "attach" probably intends to attach to a running Blazor WASM application, not a running debugging browser.

This makes a lot more sense and is probably more useful to users than the model proposed above.
For example, maybe you want to run your Blazor WASM application in watch mode and want the attach request in the "blazorwasm" debug adapter to open a new debugging session attached to this running process.

Besides, if a user has already done the work to launch a browser in debug mode hooked to their application then the adapter isn't really providing much of an additional value to them (aside for hooking up their session to VS Code which 🤷)

So really, the experience should be, you run dotnet run somewhere else to launch your application then attach via the blazorwasm debug adapter to launch your debugging browser.

[SteveSandersonMS]

@captainsafia That sounds good to me. I agree that the most useful "attach" gesture would be "open a new browser and attach it to an existing running app", rather than "attach the IDE to an existing browser+app pair".

Could it be configurable? For example, if the launch settings options included a launchBrowser bool flag (defaulting to true), then that could control whether you're doing "launch a new browser and attach to existing app" versus "attach the IDE to an existing browser+app".

If making it configurable makes it really complicated then I'd be fine with only having the option to open a new browser (attaching to an existing app).

[captainsafia]

We've got the flexibility to support both, it's largely a matter of how simple we want to keep the configuration to the end user.

The debugging adapter we're releasing this week supports the launchBrowser=true scenario. We can see how users react to this and make updates accordingly.