You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is for teams to highlight work for the community that will release .NET 7 RC 2
To add content, use a new conversation entry. The entry should include the team name and feature title as the first line shown in the template below.
## Team Name: Feature title
[link to the tracking issue or epic item for the work]
Tell the story of the feature and anything the community should pay particular attention
to be successful using the feature.
The wasm-experimental workload supports multi-threaded .NET apps using JavaScript Web Workers. This support is only implemented for the wasmbrowser template, Blazor apps do not support threading at this time.
Threaded WebAssembly support is experimental in .NET 7 and this is an opportunity for you to provide early feedback on the feature for a future release of .NET.
To get started, install .NET 7 RC2 and the wasm-experimental workload:
Optionally if you use platform-guard attributes like SupportedOSPlatform/UnsupportedOSPlatformin your code, add the .NET 7 package feed to your NuGet.config and add a reference to the threading package:
<!-- in NuGet.config -->
<configuration>
<packageSources>
<addkey="dotnet7"value="https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet7/nuget/v3/index.json" />
</packageSources>
</configuration>
<!-- your .csproj -->
<ItemGroup>
<PackageReferenceInclude="Microsoft.NET.WebAssembly.Threading"Version="7.0.0-rc.2.*" />
</ItemGroup>
Create and run a new thread.
usingSystem;usingSystem.Threading;usingSystem.Runtime.Versioning;usingSystem.Runtime.InteropServices.JavaScript;[assembly:SupportedOSPlatform("browser")]newThread(SecondThread).Start();Console.WriteLine($"Hello, Browser from the main thread {Thread.CurrentThread.ManagedThreadId}");staticvoidSecondThread(){Console.WriteLine($"Hello from Thread {Thread.CurrentThread.ManagedThreadId}");for(inti=0;i<5;++i){Console.WriteLine($"Ping {i}");Thread.Sleep(100);}}
build the app and run with the .NET app host
dotnet build
dotnet run
or publish and serve the app with another static server such as dotnet-serve. Note that cross origin isolation must be enabled by serving the COOP and COEP headers
Open the served URL in a browser (note: Chrome, Edge or Safari; at this time Firefox is not supported until Mozilla #1540913 is fixed) open developer tools, and the console should include the following output:
Hello from Thread 2
Hello, Browser from the main thread 1
Ping 0
Ping 1
Ping 2
Ping 3
Ping 4
Many properties that control the build such as WasmBuildNative, RunAOTCompilation, WasmEnableSIMD, etc are supported with threading.
Notes and known issues:
JSImport and JSExport work from the browser thread, only
WebSocket operations are only supported on the main thread
A SynchronizationContext is installed 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.
By default the app will create 4 Web Workers that will be used to execute .NET Threads. The runtime will reuse Web Workers to run multiple .NET threads (that is, after one thread stops, the Worker will be pooled and reused for a subsequent Thread.Start call). To control the number of workers that are created at app startup, configure the _WasmPThreadPoolSize property (note the property is experimental and may change in a future release).
Note that we build the runtime with the Emscripten PTHREAD_POOL_SIZE_STRICT set to 2 (see Emscripten settings.js documentation which means that creating additional workers after the initial pool of workers is exhausted will be a hard error that will stop the app. The maximum parallelism of your app must not exceed the _WasmPThreadPoolSize. Please open an issue in dotnet/runtime if this policy is too restrictive.
Debugging multithreaded WASM is not supported yet
Threading does not work in Firefox due to Bugzilla #1540913. We currently compile .NET to ES6 modules, which causes Emscripten to use the dynamic import(uri).then(callback) module import that doesn't work in Web Workers in Firefox.
System.Text.Json AppContext switch re-enabling reflection fallback in source generation dotnet/runtime#75615
.NET 7 introduced an intentional breaking change which removes silent fallback to reflection-based serialization in System.Text.Json source generators. Based on early feedback we have been receiving from customers , it appears that quite a few users have (mostly accidentally) taken a dependency on the fallback behavior.
Even though a workaround for the breaking change has been documented, it still requires a code change which might not be possible in certain scenaria. Starting in .NET 7 RC 2, you can re-enable reflection fallback globally using the provided AppContext compatibility switch. Add the following entry to your application's project file to re-enable reflection fallback for all source-generated contexts in your app. For more information on using AppContext switches, see the article on .NET runtime configuration settings.
We have added 2 new analyzers for correct usage of new APIs:
Implement Generic Math interfaces correctly - Ensures the .NET Generic Math interfaces that uses Curiously Recurring Template Pattern (CRTP) are implemented correctly in user code. In particular it warns if a type that implements the .NET Generic Math interfaces (that implements CRTP pattern) do NOT fill the generic type parameter with the type itself.
Example:
publicreadonlystructDateOnly:IParsable<DateOnly>// correct implementation of IParsable<TSelf> interface{ ...}publicreadonlystructMyDate:IParsable<DateOnly>// Warns: "The 'IParsable<TSelf>' requires the 'TSelf' type parameter to be filled with the derived type 'MyDate' " the type parameter TSelf { ...}
Prevent behavioral change in built-in operators for IntPtr and UIntPtr - Some built in operators added in .NET 7 for System.IntPtr and System.UIntPtr behave differently than the user defined operators in .NET 6 and below. Some operators that used to throw in unchecked context while overflowing now no longer throw unless wrapped within checked context, and some operators that not used to throw in checked context now would throw when overflow unless wrapped within unchecked context. The analyzer detects the code that could cause those behavioral changes and informs it.
Examples:
checked{intPtr2=intPtr1+2;// Warns: "Starting with .NET 7 the operator '+' will throw when overflowing in a checked context. Wrap the expression with an 'unchecked' statement to restore the .NET 6 behavior."intPtr2=intPtr1-2;// Warns: "Starting with .NET 7 the operator '-' will throw when overflowing in a checked context. Wrap the expression with an 'unchecked' statement to restore the .NET 6 behavior."void*ptr=(void*)intPtr1;// Warns: "Starting with .NET 7 the explicit conversion '(void*)IntPtr' will throw when overflowing in a checked context. Wrap the expression with an 'unchecked' statement to restore the .NET 6 behavior."intPtr2=(IntPtr)ptr;// Warns: "Starting with .NET 7 the explicit conversion '(IntPtr)void*' will throw when overflowing in a checked context. Wrap the expression with an 'unchecked' statement to restore the .NET 6 behavior."}intPtr1=(IntPtr)longValue;// Warns: "Starting with .NET 7 the explicit conversion '(IntPtr)Int64' will not throw when overflowing in an unchecked context. Wrap the expression with a 'checked' statement to restore the .NET 6 behavior."inta=(int)intPtr1;// Warns: "Starting with .NET 7 the explicit conversion '(Int32)IntPtr' will not throw when overflowing in an unchecked context. Wrap the expression with a 'checked' statement to restore the .NET 6 behavior."
Activity
lambdageek commentedon Sep 15, 2022
wasm-experimental: Experimental support for WebAssembly multithreading
dotnet/runtime#68162
The
wasm-experimentalworkload supports multi-threaded .NET apps using JavaScript Web Workers. This support is only implemented for thewasmbrowsertemplate, Blazor apps do not support threading at this time.Threaded WebAssembly support is experimental in .NET 7 and this is an opportunity for you to provide early feedback on the feature for a future release of .NET.
To get started, install .NET 7 RC2 and the
wasm-experimentalworkload:Create a new
wasmbrowserapp:The full example below is available at https://github.com/lambdageek/hithread
To enable threading, add the
WasmEnableThreadsproperty to the project file:Optionally if you use platform-guard attributes like
SupportedOSPlatform/UnsupportedOSPlatformin your code, add the .NET 7 package feed to yourNuGet.configand add a reference to the threading package:Create and run a new thread.
build the app and run with the .NET app host
or publish and serve the app with another static server such as dotnet-serve. Note that cross origin isolation must be enabled by serving the COOP and COEP headers
Open the served URL in a browser (note: Chrome, Edge or Safari; at this time Firefox is not supported until Mozilla #1540913 is fixed) open developer tools, and the console should include the following output:
Many properties that control the build such as
WasmBuildNative,RunAOTCompilation,WasmEnableSIMD, etc are supported with threading.Notes and known issues:
JSImportandJSExportwork from the browser thread, onlySynchronizationContextis installed on the browser thread by default. If you do not useConfigureAwait(false)when awaiting asynchronous operations, they will be scheduled on the browser thread. Conversely, not usingConfigureAwaitallows 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.Thread.Startcall). To control the number of workers that are created at app startup, configure the_WasmPThreadPoolSizeproperty (note the property is experimental and may change in a future release).Note that we build the runtime with the Emscripten
PTHREAD_POOL_SIZE_STRICTset to 2 (see Emscriptensettings.jsdocumentation which means that creating additional workers after the initial pool of workers is exhausted will be a hard error that will stop the app. The maximum parallelism of your app must not exceed the_WasmPThreadPoolSize. Please open an issue in dotnet/runtime if this policy is too restrictive.import(uri).then(callback)module import that doesn't work in Web Workers in Firefox.danmoseley commentedon Sep 19, 2022
@ericstj @karelz @jeffhandley @eerhardt for any RC2 stuff
JonDouglas commentedon Sep 19, 2022
@JeremyLikness @AngelosP FYI
eiriktsarpalis commentedon Sep 21, 2022
System.Text.Json AppContext switch re-enabling reflection fallback in source generation dotnet/runtime#75615
.NET 7 introduced an intentional breaking change which removes silent fallback to reflection-based serialization in System.Text.Json source generators. Based on early feedback we have been receiving from customers , it appears that quite a few users have (mostly accidentally) taken a dependency on the fallback behavior.
Even though a workaround for the breaking change has been documented, it still requires a code change which might not be possible in certain scenaria. Starting in .NET 7 RC 2, you can re-enable reflection fallback globally using the provided AppContext compatibility switch. Add the following entry to your application's project file to re-enable reflection fallback for all source-generated contexts in your app. For more information on using AppContext switches, see the article on .NET runtime configuration settings.
buyaa-n commentedon Sep 23, 2022
We have added 2 new analyzers for correct usage of new APIs:
Example:
Examples:
danroth27 commentedon Oct 5, 2022
@JonDouglas I spoke with @lambdageek and the plan is to include the WebAssembly multithreading content in the ASP.NET Core post.
leecow commentedon Jan 24, 2023
.NET 7 GA is available. Closing these pre-release issues.