Blazor shouldn't enable debugging when not debugging

[danroth27]

With .NET 8 Preview 3, I’m seeing the following dotnet.generated.invalid node show up in the sources tab of the browser dev tools when running a new Blazor WebAssembly app:

I don't see any other errors in the browser dev console.

Repro steps:

• Install .NET 8 Preview 3 SDK
• dotnet new blazorwasm
• dotnet run
• Open the browser dev tools and look at the Source tab

Expected result:

• No dotnet.generated.invalid node
• Jiterpreter generated wasm modules are shown

Actual result:

• A dotnet.generated.invalid node shows up
• No generated wasm modules shown

[danroth27]

@kg

[kg]

dotnet.generated.invalid is normal, it's the JS interop binding glue. the issue here is jiterpreter being missing.

[kg]

I see "Debugging hotkey: ..." when starting a sample with 'Start Without Debugging' from Visual Studio, which suggests that the interpreter is being launched with debugging enabled. If debugging is enabled that would block the jiterpreter. Examining the jiterpreter configuration indicates that it is still enabled.

[kg]

Looking at the blazor.boot.json sent over the wire when running via this path, i see "debugBuild": true even though VS is set to Release.

[kg]

https://github.com/dotnet/aspnetcore/blob/4038965d69c30f0977e112ba312c68627437ea37/src/Components/Web.JS/src/Platform/Mono/MonoPlatform.ts#L218 appears to suggest that as things are configured by blazor right now, debugging is always active so the jiterpreter will not engaged (this is required for correctness). Let me know if I'm misreading the code and I can dig in further.

[kg]

Editing the boot json to disable debugBuild and remove the pdbs (if there are any pdbs, it forces debugging on) causes the jiterpreter to engage as expected, and this appears to improve performance significantly. 👍

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[mkArtakMSFT]

@lewing now that the runtime will be handling the boot process for Blazor, is this something that you will be taking care of?

[mkArtakMSFT]

@kg has this been addressed as part of the SDK changes?
/cc @pavelsavara, @maraf