Repository navigation
BlazeDb's EF Core provider throws PlatformNotSupportedException on .NET 11 WebAssembly #14217
Description
In a .NET 11 browser app, the first synchronous SaveChanges (or query) of a BlazeDb EF Core context throws:
System.PlatformNotSupportedException: Operation is not supported on this platform.
at System.Runtime.CompilerServices.RuntimeFeature.ThrowIfMultithreadingIsNotSupported()
at System.Threading.SemaphoreSlim.WaitCore(Int64, CancellationToken)
at System.Threading.SemaphoreSlim.Wait(Int32)
at Bit.BlazeDb.EntityFrameworkCore.Infrastructure.BlazeDbEngineCache.GetOrCreate(...)
BlazeDbEngineCache.GetOrCreate tries the store's gate with SemaphoreSlim.Wait(0). On .NET 11 WebAssembly that throws even when the semaphore is free, where .NET 10 returns true. The runtime decides, not the target framework of the package, so BlazeDb's net10.0 build breaks the same way inside a .NET 11 app. The EF Core page of the BlazeDb demo shows it on the bit11 branch.
Metadata
Metadata
Assignees
Labels
No labels
Activity
fix(blazedb): try the store's gate without SemaphoreSlim.Wait(0), whi…
fix(blazedb): try the store's gate without SemaphoreSlim.Wait(0), whi…
fix(blazedb): try the store's gate without SemaphoreSlim.Wait(0), whi…
fix(blazedb): try the store's gate without SemaphoreSlim.Wait(0), whi…
fix(blazedb): try the store's gate without SemaphoreSlim.Wait(0), whi…
fix(blazedb): try the store's gate without SemaphoreSlim.Wait(0), whi…
fix(blazedb): try the store's gate without SemaphoreSlim.Wait(0), whi…
fix(blazedb): try the store's gate without SemaphoreSlim.Wait(0), whi…
fix(blazedb): try the store's gate without SemaphoreSlim.Wait(0), whi…
fix(blazedb): try the store's gate without SemaphoreSlim.Wait(0), whi…
fix(blazedb): try the store's gate without SemaphoreSlim.Wait(0), whi…
msynk commentedon Oct 28, 2026
This was a .NET 11 runtime regression, and the runtime fix is merged for the 11.0 final release.
Two catches: it is not in RC 3, and GA has not shipped yet, so nobody can confirm the shipped build has it.
Evidence from dotnet/runtime:
Cause: [browser][ST] IsSingleThreaded and ThrowIfSingleThreaded dotnet/runtime#123329 (Jan 2026) made SemaphoreSlim.Wait, ManualResetEventSlim.Wait, Monitor.Wait and Task.Wait throw PlatformNotSupportedException on single-threaded runtimes (browser, WASI), even when the wait would not block. Every build from preview 1 onward has it.
Report: SemaphoreSlim.Wait throws on single-threaded runtimes even when the semaphore is available dotnet/runtime#134972, "SemaphoreSlim.Wait throws on single-threaded runtimes even when the semaphore is available". Closed.
Fix: main PR #135413, backported to release/11.0 as #135987 (merged 2026-10-19, milestone 11.0.0). The backport PR says: "Without this fix, .NET 11 ships a breaking change relative to .NET 10." Waits that would not block now succeed. Waits that would really block still throw.
Current release/11.0 code: WaitCore calls ThrowIfMultithreadingIsNotSupported() only when async waiters are queued or the count is 0 with a nonzero timeout. Wait(0) on a free semaphore no longer throws.
RC 3 does not have the fix. Tags v11.0.0-rc.2 and v11.0.0-rc.3 point to the same commit (2026-09-23, release/11.0-rc2 branch). Comparing it with the fix commit gives "diverged", so the fix is not in RC 3.
Note: @yasmoradi merged the changes in #13311 😞