Dotnet native compiled js file referencing wrong function in blazor web assembly file

[Victorolu]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

My team have been reliant on the blazor-error-ui banner for when we have errors we need to check and after upgrading our project from dotnet 7 to dotnet 8 and updating our packages, we have noticed the banner doesn't show up as often as we want it to.

Delving deeper and running the project, I noticed that within the compiled dotnet native file, dotnet.native.8.0.3.9nm7bajy7e.js, there were references to functions within the compiled blazor web assembly, blazor.webassembly.js. The references is

var out = **Module["print"]** || console.log.bind(console);
var err = **Module["printErr"]** || console.warn.bind(console);

However, checking the blazor wasm file, I couldn't find those functions. Checking through the same on the dotnet 7 version of our project, I found those functions which the names print and printErr.

After some cross checking, I found out that the names of those functions on dotnet 8 had change to out and err.

FYI
These are the package references we have for WebAssembly in our project on dotnet 8:

<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly" Version="8.0.3" />
<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.Authentication" Version="8.0.3" />
<PackageReference Include="Microsoft.AspNetCore.Components.WebAssembly.DevServer" Version="8.0.3" PrivateAssets="all" /

Expected Behavior

The error and out functions should point to the correct functions

Steps To Reproduce

Run any Blazor Client project on dotnet 8 with the aim of generating an unhandled error. It shouldn't show up if the error banner is enabled.

Exceptions (if any)

No response

.NET Version

dotnet 8

Anything else?

No response

[javiercn]

@maraf @pavelsavara do you know what's going on here?

Seems that these functions aren't available in the net8.0 version of the dotnet.js file? Feel free to send it back if that's not the case. I don't recall us changing anything in this area.

[pavelsavara]

@Victorolu do I understand it right that you are using globalThis.Module.err to call into Blazor's showErrorNotification ?

https://github.com/dotnet/aspnetcore/blob/3c667b29965c4b552d890ba08ae34a76adf4d00e/src/Components/Web.JS/src/BootErrors.ts#L6

That should be still there in Net8 and event in Net9, but I would not consider that public API

https://github.com/dotnet/aspnetcore/blob/3c667b29965c4b552d890ba08ae34a76adf4d00e/src/Components/Web.JS/src/Platform/Mono/MonoPlatform.ts#L235

https://github.com/dotnet/aspnetcore/blob/3c667b29965c4b552d890ba08ae34a76adf4d00e/src/Components/Web.JS/src/Platform/Mono/MonoPlatform.ts#L166-L167

Updated links

[pavelsavara]

@javiercn I don't mind leaving it here for now

but this is Blazor's error notification bar we are talking about. Runtime's Module.err is just way how they touch internals Should there be public API for the same ? Perhaps on globalThis.Blazor object ? Do we still consider multiple independent instances of wasm runtime in same page ?

[Victorolu]

Hi @pavelsavara thanks for your response. The files you referenced are correct, however, it looks different in the complied js file on my browser.

These are the function names on blazor.webassembly.js which are out and err

But what is being referenced is different, print and printErr

This causes the code to only perform a console log because it can't find print and printErr

Also, we have been getting this warning about mono disabling

Not too sure what has caused that as we have looked for solutions everywhere, might be connected to this. Not sure

[BrownishMonster]

Hi all,

@Victorolu and I were comparing our release before and after the dotnet 8 upgrade, and the JS files in the framework were different.

dotnet 7:

dotnet 8:

A new dotnet 8 blazor project would contain blazor.web.js whereas our project contains blazor.webassembly.js. This is because we have not migrated to a Blazor Web App.

[pavelsavara]

Oh, this is interesting. You are saying that we don't configure the right thing anymore!

I think this is the related change emscripten-core/emscripten#17955