Blazor hasDebuggingEnabled set when "Start without debugging" in VS

[lewing]

When blazor is started from inside VS with Start without debugging hasDebuggingEnabled is true and load_runtime is passed non zero debug level. This disables most interpreter optimizations (because they would break debugging) leading to substantially slower execution speed (dotnet/runtime#40428). Is this the intended behavior? If not can it be fixed, and if so can it be documented?

https://github.com/dotnet/AspNetCore/blob/master/src/Components/Web.JS/src/Platform/Mono/MonoPlatform.ts#L367

[captainsafia]

Is this the intended behavior?

Nope.

If not can it be fixed,

We can try to fix it. We had briefly discussed this class of issues (passing configurations from the IDE down to the debugger, such as start without debugging) but hadn't talked about the specifics.

The JS debugger sets a noDebug flag in the config. We might be able to figure out a way to read that from the client and configure the MonoProxy correctly.

and if so can it be documented?

@guardrex Let's add a note in the debugging section to let users know that "Start without debugging" doesn't work with Blazor WASM on VS.

@mkArtakMSFT This issue would be a good candidate for RC1 as a perf improvement.

[captainsafia]

It looks like our best option here is to implement a middleware in the debug proxy that checks to see if there is a chrome process with the remote-debugging-port set. I landed on this solution after spiking into a couple of different approaches:

• We can't rely on any client-side checks, including checking navigator.webdriver, because pretty soon that will not be set when debugging is enabled (ref).
• You can figure out if a Chrome browser is running with debugging enabled by checking the command line arguments listed at chrome://version. Of course, there is no way to check this from the JavaScript on a webpage.
• We can try sending a request to http://localhost:9222/json/version and seeing if we get a response. However, there's no way for us to know ahead of time what debugging port (e.g. 9222) is being used by Chrome/Edge, especially if Chrome is launched with any available port (e.g. remote-debugging-port=0).
• We could set a flag from the IDE (VS/VS Code) when Start without debugging is used. However, this change is a little bit more high cost than the timeline we have here. Also, it makes the change less portable across different scenarios.

So, debug proxy + PID scan strikes the balance between being the most portable and requiring us to know the least ahead of time (e.g. what debugging port is used). This approach should also work on remote scenarios without requiring port forwarding/proxying.

Some things to be mindful of with this approach:

• Any Chrome browser running with remote-debugging-enabled on the machine will cause us to enable debugging in the browser (e.g. false positives). This should be rare though since we can assume that most of the time the user is starting the debugging session from the IDE.
  • We might be able to get around this by checking for browsers started with remote-debugging-port and a launch address of http://localhost:{applicationPort}.

[captainsafia]

Orrrrrrrrrrr....alternatively as discussed during today's Blazor engineering sync we can have the user explicitly set whether or not they want to debug via a query parameter.

1. User starts debugging.
2. User navigates tohttps://localhost:5001?debug=true.
3. We parse the query params and set the flag accordingly.

VS Code and VS will need to update the launch URL of the application accordingly.

[captainsafia]

We reverted this change and will put in a more robust fix for 6.0 so re-opening.

[guardrex]

@captainsafia ... Should I close the docs issue 👉 dotnet/AspNetCore.Docs#19545?

[captainsafia]

@guardrex Yes.

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[pranavkm]

@lewing given this is a dev scenario and fixing it seems tedious at best, I'm going to mark this as won't fix. Let me know if you feel very strongly about fixing it.