// the take
A thin .NET binding over Wasmer's C API that lets you run WASM modules in-process from C#, built by Miguel de Icaza. It's for .NET devs who want to embed a WASM sandbox directly in their app without shelling out to a separate runtime process.
The P/Invoke layer is written by someone with a long track record in native interop (Mono, Xamarin), so the marshaling code around WasmerValue, memory, and function imports/exports is solid, not a hobby wrapper. It's a single-file binding (Wasmer.cs) targeting .NET Standard 2.0, so it runs on .NET Framework, .NET Core, and Mono without separate builds. Execution is genuinely in-process — no subprocess, no IPC overhead to call into WASM. Ships with real working samples (StandaloneSample, DesktopSample) instead of just API reference docs.
Pinned to a specific pre-1.0 Wasmer commit (ab5f288, from the old wasmer-runtime-c-api) and hasn't been touched since September 2022 — Wasmer has since done multiple breaking API revisions and moved to a different C API surface, so this binds a runtime version that's effectively frozen in time with whatever bugs and CVEs it had back then. The native runtime library isn't bundled in a usable way via NuGet: you manually download platform-specific .dylib/.so/.dll files and copy them into bin/Debug or bin/Release yourself, which is a rough fit for CI pipelines or containerized deployment. No WASI support exposed in the API, so anything needing filesystem or env access from the guest module is out of scope. With no commits in over four years and a single maintainer, don't expect fixes if you hit a bug in the binding or want a newer Wasmer runtime.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →