Repository navigation
WasmEnableThreads incrementalism is broken #98502
Description
Activity
Note that a similar problem also happens when switching WasmEnableThreads from
falsetotruewithout deleting bin/obj, which is even more confusing because then you will likely think that further config is required to enable threading, when it isn't.Thanks for pointing this out, we'll make sure it gets resolved
The problem is with conversion to webcil format. The
ConvertDllsToWebCilcompares only file timestamp, but not if the original location has changedThis issue is impacting my application running on Avalonia 11 and .NET 9. As soon as I set this flag 'true', the app stops loading altogether in browser. Any ETA on when this issue will be resolved?
This issue is impacting my application running on Avalonia 11 and .NET 9. As soon as I set this flag 'true', the app stops loading altogether in browser. Any ETA on when this issue will be resolved?
You might be running into a different issue. Is it possible tht you're using the embedded 'devserver'? (This is used by, amongst other things, standalone Blazor WebAssembly apps. It provides a web server that hosts wasm-based apps. I don't know if browser-based Avalonia apps use it but if they're using WebAssembly, it would make sense for them to use this same devserver that Blazor uses.)
In .NET 9.0, when you enable
WasmEnableThreads, the app fails to load due to a CORS issue in WebAssembly devserver. Basically, the browser tries to download a file that will have a name something likehttps://localhost:7209/_framework/dotnet.native.worker.1t59g4t9vs.mjs, and when the devserver reponds to that request, it does not set the necessaryCross-Origin-Embedder-Policyheader. If you open the browser dev tools, go to the console page, then look at the Issues section you may see it reporting this problem.This was actually fixed back in October 2024: dotnet/aspnetcore#58287
However, that fix is for the .NET 10.0 branch. That change has not been backported to the NET 9.0 branch. You can see the line of code that fixes the problem here:
but the
release/9.0branch currently (2025/06/03) has this for that line:Note that on the .NET 9.0 branch (today) it does not look for the
.mjsextension in the path. And that's why Blazor WebAssembly apps simply don't run at all in .NET 9.0 if you set this flag.The confusing thing is that .NET 9.0 did ship with some code in Blazor that knows about WASM threading. (It does set the right headers on some files. And it sets these headers specifically to enable multithreading: they are necessary to enable shared memory use, which is required for multithreading to work.) This initially gave me the impression that this is supposed to work. (When you try to enable threading, it changes its behaviour and you don't get any errors telling you that you're not supposed to do this.)
Nonetheless, as far as I can tell, use of
WasmEnableThreadsin Blazor apps is not in fact supported in .NET 9.0. So If you want to use this setting, I think you have to use .NET 10.0 preview (or wait until .NET 10.0 ships).So although in theory they could backport that one line change to the .NET 9.0 branch, I'm not sure it would help: I suspect it's just one of many changes that are required for multithreading to work in .NET on WASM in the browser.
Description
If you have a Blazor WebAssembly app with WasmEnableThreads=true, and then change it to false, the build output is corrupted and won't work until you delete bin/obj and build again.
Reproduction Steps
Expected behavior
It should work in single-threaded mode
Actual behavior
It fails with:
Regression?
No
Known Workarounds
Delete
bin&objfolders(which unfortunately is not something we can expect developers to do in reality)
Configuration
.NET 9 WebAssembly
Other information
No response