News

No Need to Wait for .NET 8 to Try Experimental WebAssembly Multithreading

• By David Ramel
• 10/11/2022

Multithreading support for client-side Blazor WebAssembly apps is planned for .NET 8 in November 2023, but developers can try it out now for .NET apps thanks to experimental functionality in the brand-new .NET 7 Release Candidate 2.

Announced today, .NET 7 RC2 is production-ready code that's only one month away from General Availability.

Also today, Microsoft published a blog post explaining ASP.NET Core updates in .NET 7 Release Candidate 2. Just like in .NET 7 RC1, WebAssembly was the star of this ASP.NET Core show.

RC1 received a host of improvements to WebAssembly, the open source tech that powers the client-side part of Blazor -- aptly named Blazor WebAssembly -- and allows for web projects to be coded primarily in C# instead of JavaScript. RC1 featured dynamic authentication requests in Blazor WebAssembly, debugging improvements, .NET WebAssembly build tools for .NET 6 projects and .NET JavaScript interop on WebAssembly.

That latter item comes via a new experimental template, wasm-experimental, with Microsoft stating: ".NET 7 introduces a new low-level mechanism for using .NET in JavaScript-based apps. With this new JavaScript interop capability, you can invoke .NET code from JavaScript using the .NET WebAssembly runtime as well [as] call into JavaScript functionality from .NET without any dependency on the Blazor UI component model."

In RC2, the dev team improved upon the wasm-experimental functionality.

"The wasm-experimental workload now includes support for multithreaded .NET apps on WebAssembly using Web Workers," Microsoft said today. "This is a new .NET runtime capability. Multithreading support hasn't been integrated yet into Blazor WebAssembly apps (planned for .NET 8), but you can still try it out in preview form using the experimental WebAssembly Browser App template."

Other highlights of the post include:

• Output caching improvements: "Output caching was improved in .NET 7 RC2 based on preview feedback from users. In this version, output caching stores the content of the cached entries in a binary format. Previously it was using JSON. This new format is faster and smaller."
• Dynamic authentication requests with msal.js: "In .NET 7 RC1 we introduced support for making dynamic authentication requests with custom parameters in Blazor WebAssembly apps. With .NET 7 RC2, this functionality is now available when using the Microsoft Identity Platform via the built-in msal.js integration. For details on making dynamic authentication requests in Blazor WebAssembly see the Dynamic authentication requests in Blazor WebAssembly section of the .NET 7 RC1 release announcement post."
• Improved diagnostics for authentication in Blazor WebAssembly: "To help diagnose authentication issues in Blazor WebAssembly apps we added detailed logging that you can enable."

However, as the multithreading capability may be of special interest to developers, they might be advised that Microsoft posted a lengthy list of Notes and known issues with .NET multithreading on WebAssembly:

• By default, the app will create a pool of four Web Workers to execute .NET threads. To control the number of workers that are created at app startup, configure the _WasmPThreadPoolSize property (subject to change in a future release). The maximum parallelism of your app must not exceed the worker pool size.
• A SynchronizationContext is used on the browser thread by default. If you do not use ConfigureAwait(false) when awaiting asynchronous operations, they will be scheduled on the browser thread. Conversely, not using ConfigureAwait allows your asynchronous operations to return to the browser thread in order to interact with the DOM or other JS libraries that are only available on the main thread.
• Multithreading requires that cross origin isolation is enabled by serving the COOP and COEP headers. This will restrict the functionality of the site: Enabling cross-origin isolation blocks loading cross-origin resources that you don’t explicitly opt-in, and it will prevent your top-level document from being able to communicate with popup windows.
• The build properties RunAOTCompilation and WasmEnableSIMD are supported with multithreading.
• JSImport and JSExport only work from the main browser thread.
• WebSocket operations are only supported on the main browser thread.
• Debugging multithreaded code on WebAssembly is not yet supported.
• Threading does not work in Firefox yet due to Bugzilla #1540913.

The origin of the experimental effort comes from this GitHub issue, which notes it was completed in .NET 7 RC2 and states: "The wasm-experimental workload supports threading using <WasmEnableThreads>true</WasmEnableThreads> in interp [sic] and AOT configurations when using the wasmbrowser workload. Blazor does not support threading in .NET 7."