Launch DebugProxy from IDE not runtime

[danroth27]

If you create a default ASP.NET Core hosted Blazor WebAssembly app and set the environment to Production then debugging will fail. The reason is obvious: the app.UseWebAssemblyDebugging() call is within a Development environment check. But the user experience is a bit unexpected. Visual Studio will still happily try to debug the Blazor WebAssembly app and will fail to connect to the non-existent debugging endpoint after a lengthy timeout:

This seems like it could be surprising to users. It seems reasonable to want to be able to debug your Blazor WebAssembly app even when you've set the environment to Production. We certainly support this for in general for ASP.NET Core apps, and it also works fine with standalone Blazor WebAssembly apps where the debugging endpoint is handled by the dev server.

Is there a way that we could externalize the debugging endpoint from the app so that it isn't impacted by debugging at all?

@timheuer

[captainsafia]

I can take a look at this. I have a pretty firm idea of how we'll accomplish this when debugging from VS Code.

I'll need to do some research into VS's debugging APIs to understand how things work there and how we might unify the two approaches.

[captainsafia]

Removing the Needs Design label from this now that we've got a plan moving forward. This work will happen in the following steps.

• Backport DebugProxy fixes to Mono (Backport DebugProxy fixes to Mono #22578)
• Move Blazor DebugProxy into its own package (Consume DebugProxy package from runtime repo #19827)
  • Update DevServer to reference external package
• Launch DebugProxy from blazorwasm debug type (Add support for launching DebugProxy from blazorwasm debug type in VS Code #22587)
• Launch DebugProxy from VS (Add support for launching DebugProxy from VS #22589, NOTE: This dependents on some work items in VS)

We can approach this implementation incrementally based on the steps above.

During today's sync we also discussed consuming the MonoProxy as a package (#17948). This would be a nice improvement but it doesn't totally block work on this feature so I haven't included it in the list below.

[gp2-gp2]

As this is closed -> #20597 and we were redirected to this issue can I ask what is the solution for issue 20597? Right now there is no way to develop under Linux any Blazor hosted app and successfully debug it.

[captainsafia]

@gp2-gp2 Debugging in Linux (Ubuntu, Mint, etc) should work. Debugging under WSL (Windows Subsystem for Linux) is currently not working. If you're having trouble debugging on Linux, please open another issue with a description of the problem.

[elylv]

Is there a workaround for this? I am currently totally unable to debug the client in Visual Studio 2019 (even after switching back to Anonymous Authentication). Just get timeouts on the debug adapter.

[captainsafia]

@elylv Unfortunately, there's not a workaround.

Based on the details you've given, it looks like you're running into an unrelated issue we've been working through with timeouts during debugging.

I'd recommend opening a new issue with any helpful details you can include (screenshots, error messages, etc) so that we can track it under #23473.

[mkArtakMSFT]

Closing as a dupe of #22589