Skip to content

fix(build): compile without Runtime Async so Blazor WebAssembly works (3.0.0-prerelease.6) - #70

Merged
kieronlanning merged 1 commit into
mainfrom
fix/wasm-runtime-async
Nov 12, 2026
Merged

kieronlanning merged 1 commit into
mainfrom
fix/wasm-runtime-async

Conversation

@kieronlanning

Copy link
Copy Markdown
Collaborator

Why

3.0.0-prerelease.5 shipped every net11.0 assembly built with Runtime Async (runtime-async=on, the Purview.BuildSdk 2.0 default). Runtime Async is not supported by Mono, and Mono is the runtime behind Blazor WebAssembly, so a wasm consumer failed at the first await it reached:

System.InvalidProgramException
   at ZodSharp.Blazor.ZodValidator.<>c__DisplayClass49_0.<OnValidationRequested>b__0(CancellationToken)
   at Microsoft.AspNetCore.Components.Forms.EditContext.ValidateAsync(...)

Found by purview-dev/value-objects' packed-consumer gate. Full evidence, including the IL diff between .2/.3 (builder state machine) and .5 (AsyncHelpers::Await), is in #69.

What changed

  • src/Directory.Build.props sets PurviewRuntimeAsync=false, so no net11.0 target is compiled with it. Every package here can be consumed from the browser — the core package, SystemTextJson, Http and Blazor — so a per-project split would still leave the core library unusable on WebAssembly. The C# 15 updated memory-safety rules (MemorySafetyRules=2) are independent and stay on.
  • AGENTS.md records the opt-out and the Mono limitation, so it is not "fixed" back on in a later SDK bump.
  • package.json → 3.0.0-prerelease.6, with a CHANGELOG.md entry.

Verification

  • dotnet build src/ZodSharp.slnx -c Release: succeeds, 0 warnings.
  • No Purview.ZodSharp* net11.0 assembly in the build output references AsyncHelpers any more; ZodValidator.ValidateFormAsync compiles to the classic AsyncTaskMethodBuilder state machine.
  • csharpier check .: clean.
  • Unit tests: Blazor 95/95, ZodSharp 2304/2304, Repository 46/46.
  • dotnet pack produced 3.0.0-prerelease.6 packages on ASP.NET Core 11.0.0 GA (no 11.0.0-rc.3, so no NU1902 on the consumer side).
  • End to end: purview-dev/value-objects' scripts/test-packed-consumers.ps1 -DependencyFeed <local .6 feed> passes — Native AOT console 24 checks, Blazor WebAssembly trimmed + browser self-test, Blazor Server forms, net10.0 console, leak scans.

Release

Merging this bumps to 3.0.0-prerelease.6, so the Release workflow publishes it. purview-dev/value-objects can then move its PurviewZodSharpVersion pin from .5 to .6 and its packed-consumer gate goes green.

Closes #69.

3.0.0-prerelease.5 shipped every net11.0 assembly built with Runtime Async,
which Purview.BuildSdk 2.0 turns on by default. Mono does not support it
(dotnet/aspnetcore#68067), and Mono is the runtime behind Blazor WebAssembly,
so a wasm consumer threw an empty InvalidProgramException from
AsyncHelpers.Await the first time it validated a form through ZodValidator.
Republishing the same consumer untrimmed reproduced it, so this was not ILLink.

Almost every package here can be consumed from the browser - the core package,
SystemTextJson, Http and Blazor - so the repository opts out instead of
carrying a per-project split that would still leave the core library unusable
on WebAssembly. The C# 15 updated memory-safety rules are independent of this
and stay on.

Proven with purview-dev/value-objects' packed-consumer gate: its Blazor
WebAssembly consumer failed on 3.0.0-prerelease.5 and passes on the packages
packed from this commit.
@kieronlanning
kieronlanning merged commit 4aeb042 into main Nov 12, 2026
8 checks passed
@kieronlanning
kieronlanning deleted the fix/wasm-runtime-async branch November 12, 2026 10:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Purview.ZodSharp.Blazor 3.0.0-prerelease.5 throws InvalidProgramException in Blazor WebAssembly (Runtime Async is not supported on Mono)

1 participant