Repository navigation
Dotnet native compiled js file referencing wrong function in blazor web assembly file #100591
Description
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
Activity
javiercn commentedon Apr 3, 2024
@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 commentedon Apr 3, 2024
@Victorolu do I understand it right that you are using
globalThis.Module.errto call into Blazor'sshowErrorNotification?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 commentedon Apr 3, 2024
@javiercn I don't mind leaving it here for now
but this is Blazor's error notification bar we are talking about. Runtime'sModule.erris just way how they touch internals Should there be public API for the same ? Perhaps onglobalThis.Blazorobject ? Do we still consider multiple independent instances of wasm runtime in same page ?Victorolu commentedon Apr 4, 2024
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
outanderrBut what is being referenced is different,
printandprintErrThis causes the code to only perform a console log because it can't find
printandprintErrAlso, 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 commentedon Apr 4, 2024
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.jswhereas our project containsblazor.webassembly.js. This is because we have not migrated to a Blazor Web App.pavelsavara commentedon Apr 4, 2024
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
6 remaining items
maraf commentedon Apr 11, 2024
@Victorolu Please, try to run the app from command line with
dotnet run(in project directory). Getting nightly SDK into VS is more complicatedAlso don't forget to update Blazor PackageReferences to 9 (
9.0.0-*should be working fine)Victorolu commentedon Apr 11, 2024
Hi @maraf, I have tried your suggestion and looks like project can't find some packages associated with the current dotnet9 version which is expected because they are not available nuget.org.
Please how can I access these packages?
maraf commentedon Apr 11, 2024
@Victorolu I'm sorry, I always forgot to mention it. Add to your csproj
Victorolu commentedon Apr 12, 2024
@maraf thanks for that. I was able to get the project to run after encountering some other issues like the missing project runtime config file that was not generated so I had to create mine and specify the framework to be used. Don't know if that is something that needs to be fixed as well.
But yeah, was able to run the project and got the error message. This, however, has led to another problem.
Looks like Blazor has crashed and is related to mono being disabled
This was not the behaviour on dotnet 7 as the application was still running as normal after the error occurred
maraf commentedon Apr 12, 2024
This looks weird. Blazor should be handling mono runtime start and shutdown correctly.
How you start blazor? Are you using just the standard
<script src="blazor.web.js"></script>or do you customize things?One things that comes to my mind is about browser cache, can you please try open the app in an incognito mode, other browser, or use different server port?
pavelsavara commentedon Apr 12, 2024
this is likely Net8blazor.webassembly.jsin the browser cache.This is
abort()of the process. That's expected on critical errors.Victorolu commentedon Apr 12, 2024
@maraf The file being called to start off blazor is referenced as
<script src="_framework/blazor.webassembly.js"></script>as there was no part of the documentation for upgrading from dotnet 7 to 8 that required it being changed.
@pavelsavara Why wasn't this the case with dotnet 7 then?
pavelsavara commentedon Apr 12, 2024
We evolve :)
Why would it be good idea to let the corrupted program to keep running ?
Victorolu commentedon Apr 12, 2024
@pavelsavara
Well, that makes sense but not all errors corrupt programs though. In our case, we would still want to see the errors so we can fix them but we don't want the program to become unresponsive if that makes sense.
Question, does that mean all unhandled errors are classed as critical errors?
maraf commentedon Apr 12, 2024
Yeah, when the runtime aborts, it means that something really bad happened.
Does the app crash in incognito mode (no cache involved)?
Victorolu commentedon Apr 15, 2024
Hi @maraf, yes the app crashes in incognito as well
pavelsavara commentedon Apr 15, 2024
Some assert happened in your native code (or in Mono code) and called
abort().There is no class of "harmless" asserts or aborts.
If you want to recover from such problem, I suggest that you reload the whole page.
pavelsavara commentedon Apr 15, 2024
Fixed by #100818 for next Net8 servicing release