Run the .NET WebAssembly runtime in release mode in published Blazor apps about aspnetcore

[danroth27]

I created a Blazor Web App with WebAssembly interactivity enabled globally using .NET 9 Preview 3 and then published the app. It looks like debugging is correctly disabled:

[kg]

In my testing, Release builds (non-published) run the interpreter in debug mode, which does increase startup overhead. I'm not sure about publish, because right now my published builds are crashing during jsexport startup.

[mkArtakMSFT]

@MackinnonBuck parking this on your plate to follow up and understand what may be causing this.

[mkArtakMSFT]

@lewing it seems that all this is now controlled by the runtime and we just pass parameters to the runtime during Blazor startup. If there are specific flags to set, etc. we can verify if they are being set or not. Other than that, it's not clear how we can address this.

[lewing]

@maraf knows the details here

[halter73]

We also don't know how to detect whether the WebAssembly runtime is in debug or release mode. What's the easiest way?

[maraf]

• Any "build" (Debug, Release or any user defined) by default results in "debugging enabled", disabling interpreter optimizations etc.
• Any "publish" results in "debugging disabled", enabling interpreter optimizations etc.
• This default behavior can be overriden by WasmDebugLevel=0 (disable debugging) or WasmDebugLevel=-1/1 (enable debugging).

More details in dotnet/runtime#96239 (comment)

We also don't know how to detect whether the WebAssembly runtime is in debug or release mode. What's the easiest way?

The actual value on runtime can be obtained by getConfig().debugLevel, in Blazor by Blazor.runtime.getConfig().debugLevel