wasip2-on-dotnet-status.md

State of WASIp2 on .NET (primarily using NativeAOT-LLVM) according to Joel

Note that I've generally been focusing on NativeAOT-LLVM because that's the only thing that worked with the component model when I started working on .NET, plus it's currently the best option from a performance and binary size perspective. Since then, Pavel has moved Mono and its interpreter forward so it's in much better shape, but I haven't played with it myself.

Status

• Basic WASIp2 support is upstreamed into runtime and will ship as part of .NET 9.0
  • But there are a couple of bugs, and it's too late to fix them for .NET 9.0, so you probably don't want to use that anyway
• dotnet/runtimelab#2614 includes all the latest fixes, including Linux and MacOS build fixes, a couple of patches to Microsoft.Extensions used by AspNetCore, etc.
  • Some of that PR needs to be upstreamed to the runtime repo first, then downstreamed to the runtimelab repo; the rest (i.e. the NativeAOT-LLVM parts) can go straight into the runtimelab repo
  • Pavel Savara has been handling the upstream PRs so far
• dotnet/runtimelab#2605 added (partial) CI support for building WASI NativeAOT-LLVM for Linux/x86_64
  • No PR or issue yet for MacOS support (AFAIK), but hopefully straightforward once Linux works
• Grpc.Net.Client works with minor hacks in both the .NET runtime and wasmtime-wasi-http, but WASI spec-level work will be needed to support it officially: WebAssembly/wasi-http#129
• We're currently publishing Windows/x86_64 and Linux/x86_64 packages, but none for other platforms (e.g. MacOS, Linux/ARM64); meanwhile, you can either build from source or use my unofficial builds: https://github.com/dicej/spin-dotnet-sdk/releases/tag/canary
• Just recently got (a patched version of) AspNetCore working. Need to get those patches upstreamed and start publishing official WASI builds of AspNetCore in order to make it ergonmic to use.
  • See https://github.com/dicej/spin-dotnet-sdk?tab=readme-ov-file#aspnet-core-and-json-serialization for a working example
  • See https://github.com/SteveSandersonMS/dotnet-wasi-sdk/blob/dc886fd390a773ad09a49c4a250e5b4a42d4c416/src/Wasi.Sdk/build/Wasi.Sdk.targets#L65-L73 for what needs to happen next

Known issues

• No System.Net.Security.SSLStream support (need e.g. wasi:sockets/tls to advance: WebAssembly/wasi-sockets#100). I've just started working on this.
• No multithreading (idea: add stack-switching-based green thread support to wasi-libc or adjacent library to enable pthread APIs which .NET can use)
  • Pavel is skeptical that non-premptive multithreading will meet .NET developers' needs, though
  • So far, we haven't encountered a library needed by an Important Customer which requires multithreading, so no urgency yet, but I expect we'll hit one eventually
• No System.Net.Sockets support yet (tends to use multithreading internally, even for async functions)
  • Pavel has begun working on this; looks like supporting pure async ops with no multithreading is doable, but non-trivial
• Many APIs that are currently disabled or restricted for the "browser" target should also be disabled or restricted for the "wasi" target. Currently, they either silently fail or error in the wrong place.
  • Pavel has started enumerating these cases and addressing them.
• No exception stack traces for NativeAOT: dotnet/runtimelab#2404 (works fine for the Mono interpeter, though)
  • You can kind of work around this using e.g. GDB and putting a breakpoint on S_P_CoreLib_System_Runtime_EH__RhpThrowEx and then getting a backtrace when it's hit, but in general it's a huge papercut when doing any kind of casual debugging or forensics
  • SingleAccretion has proposed adding a "virtual stack trace" feature to address this without any special WASI or Wasm features
• Reflection is limited with NativeAOT
  • Nothing WASI- or Wasm- specific here, but important to be aware of
  • Stuff that relies heavily on reflection (e.g. MVC, Razor Pages, etc.) not currently supported at all
  • Customers who want both maximum performance and minimum porting effort will find this painful

TODO items

• Merge outstanding PR(s) discussed above
• Update CI to build and publish official Linux and Mac (x86_64 and ARM64) ILCompiler packages
• Release WASI-SDK 25 and update .NET to it. This will include a wasm-component-ld update to resolve a WASI 0.2.0 vs. 0.2.1 compatibility issue.
• Port, test, and (as necessary) fix real-world apps for Important Customers
  • The sooner we know which of the known issues listed above actually matter to Important Customer(s) (and what as-yet-unknown issues may lurk), the sooner we can prioritize and address them.
  • Pay special attention to libraries which require reflection and research and/or develop e.g. source-generation-based workarounds
• Support at least the async APIs of System.Net.Sockets
  • Pavel has a plan for this
• Support System.Net.Security.SslStream via the current draft of wasi:sockets/tls
• Support stack traces on NativeAOT
• Performance optimization (as driven by Important Customer needs and profiling)
  • Wizer-style pre-init support (probably via component-init)
  • Use Spans instead of e.g. byte[] in wit-bindgen-generated code to minimize copies (e.g. here)
• Add support for exporting async functions to wit-bindgen
  • This would reduce application level boilerplate
• Other ergonomic improvements as deemed appropriate by .NET experts (i.e. not me)
• (nice to have) Support wasi:io/poll/pollable cancellation (i.e. discard pollables which the app no longer cares about)
  • Pavel is interested in addressing this, although I don't consider it particularly urgent for serverless workloads