[browser] custom boot - Condition not met at mono/metadata/assembly.c:2718

[elringus]

Description

The following error occurs randomly when booting the .NET runtime in browser:

[MONO] * Assertion at /__w/1/s/src/mono/mono/metadata/assembly.c:2718, condition `<disabled>' not met
Error at Fc (http://localhost:3000/_framework/dotnet.runtime.js:3:168644)
  at http://localhost:3000/_framework/dotnet.native.wasm:wasm-function[3748]:0x10334d
  at http://localhost:3000/_framework/dotnet.native.wasm:wasm-function[785]:0x3c089
  at http://localhost:3000/_framework/dotnet.native.wasm:wasm-function[706]:0x3a13c
  at http://localhost:3000/_framework/dotnet.native.wasm:wasm-function[710]:0x3a25d
  at http://localhost:3000/_framework/dotnet.native.wasm:wasm-function[712]:0x3a2a0
  at http://localhost:3000/_framework/dotnet.native.wasm:wasm-function[711]:0x3a273
  at http://localhost:3000/_framework/dotnet.native.wasm:wasm-function[3742]:0x1010a2
  at Module._mono_wasm_load_runtime [as mono_wasm_load_runtime] (http://localhost:3000/_framework/dotnet.native.js:8:91450)
  at http://localhost:3000/_framework/dotnet.runtime.js:3:184650
MONO_WASM: mono_wasm_load_runtime () failed

Reproduction Steps

1. Clone the following minimal repro: https://github.com/elringus/js-interop-test
2. Run dotnet publish under the root directory
3. Run npx serve (or other HTTP server) under JSInteropTest/bin/Release/net9.0/browser-wasm/AppBundle
4. Open the served URL with a browser and start refreshing the page

Expected behavior

The app is booted and prints the debug statements on each page refresh.

Actual behavior

The app is sometimes booted and sometimes not, with the aforementioned error.

Example screen recording below:

vid.mp4

Regression?

This is a regression in .NET 9. This behavior was not observed in .NET 8.

Known Workarounds

None.

Configuration

.NET SDK:
 Version:           9.0.100
 Commit:            59db016f11
 Workload version:  9.0.100-manifests.174c237d
 MSBuild version:   17.12.7+5b8665660

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.19045
 OS Platform: Windows
 RID:         win-x64

Other information

No response

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

[pavelsavara]

Is this possibly because [ModuleInitializer] ?

[elringus]

I've worked around this by using buffer instead of resolvedUrl in config.assets and manually fetching the binaries content, so I guess it has something to do with the resource fetching on JS side.

[pavelsavara]

I see now, this is the custom boot sequence.

https://github.com/elringus/js-interop-test/blob/69c531912bdec3acf49496e8a3202e94dfb7f377/JSInteropTest/Frontend/boot.js#L7

[pavelsavara]

We are probably going to disrupt this anyway, right @maraf ?

[elringus]

probably going to disrupt this anyway

You mean removing assets from the runtime config? I suspected this might happen when the property was removed from the MonoConfig type definition. I assume resources should be used instead?

Could you please consider adding a way to specify a resource's buffer for cases where end-users fetch the content themselves (similar to asset.buffer)? Maybe something like:

type ResourceList = {
    [name: string]: string | null | "" | ArrayBuffer;
};

— where an ArrayBuffer, when specified instead of a hash, would indicate that the resource is already loaded and the provided content should be used by the runtime.

[pavelsavara]

@elringus if I remember it right, you are doing this in order to webpack it ? Or what's the real use case and motivation for this extension point ?

[elringus]

The main one is embedding WASM inside JavaScript module, so that we can have a single .js file with the C# library inside, which can be directly imported to a web project.

But this is also important to abstract the WASM delivery mechanism. It's not like fetch covers all possible scenarios. For example, we may have an electron or tauri app, where the binary is embedded in app resources—simple fetch won't work here.

[pavelsavara]

BTW: you can also monkey-patch fetch

[elringus]

you can also monkey-patch fetch

Not really, as I don't want to break base dotnet JS features for end-users of my library. If someone would like to use the default resource fetching mechanism, they should be able to.

[maraf]

The main one is embedding WASM inside JavaScript module

How are you doing it? Are you embedding the wasm binary as text in JS?

Could you please consider adding a way to specify a resource's buffer for cases where end-users fetch the content themselves (similar to asset.buffer)?

I'm not sure about the final schema, whether it will be resources-based or assets-based, but we are looking at being able to generate boot config compatible with bundlers (webpack, rollup). With this config dotnet/aspnetcore#59456 (comment) (and #77191) babel was able to do it's job, merge all JS files together and process wasm files. Would that be sufficient for your goals? I would like to hear your input

[elringus]

How are you doing it? Are you embedding the wasm binary as test in JS text?

As base64-encoded text.

we are looking at being able to generate boot config compatible with bundlers

I've maintained that kind of boot config since .NET 6 in my library: https://github.com/elringus/bootsharp/blob/main/src/js/src/config.ts. It works with bundlers (webpack, Vite) and runtimes (Node, Deno, Bun) alike. The one you've shared looks similar, so I guess it'll work as well. Just be aware of bundler warnings due to unresolved imports in the JS runtime and Emscripten-generated files. On my end, I'm patching them during the dotnet build. I created an issue about this a while ago: #80045 (though the title is about web extensions, the core issue is with the imports). Here is the patcher I'm using: https://github.com/elringus/bootsharp/blob/main/src/cs/Bootsharp.Publish/Pack/ModulePatcher/InternalPatcher.cs.

That said, this particular bundler/boot config scenario is not directly related to the issue of customizing the binaries delivery mechanism. We still need an option to provide the content directly to the dotnet JS runtime when it initializes—so it's a runtime issue rather than a build/bundle-time one.

Would that be sufficient for your goals?

As long as the dotnet JS runtime allows providing binary content for the boot resources, it'll work. The assets model with the buffer property is working perfectly. The resources model in its current form doesn't work, because it doesn't have a way to specify the binary content.