Running WebAssembly and WASI with .Net | Hacker News Reader

Running WebAssembly and WASI with .Net

ericsink.com

65 pointsmouldysammich20 comments

This is super exciting for me, as a C# developer. I'm fed up of needing (to learn how) to compile C++ projects for each platform so that I can reference them from .NET Core. The idea of just compiling them once for WebAssembly/WASI and only needing to ship one copy of each binary dependency is quite freeing and makes cross plat functionality easier.

You're in luck- MS released a WASM GUI kit- Blazor

I think this is about c++-in-wasm-in-C# rather than c#-in-wasm. It's an (arguably) better way of doing FFI without having to worry about compiling the C++ dependency.

Presumably you have to compile the C++ once to wasm though?

Yeah you would, though having a common compile to target would hopefully make it easier to find pre compiled wasm binaries.

Right, some libraries are already getting official and semi-official wasm targets for the Node JS ecosystem. It would be interesting to "borrow" an existing wasm binary from npm and simply rehost it on the .NET CLR or JVM.

Absolutely... I have a suspicion that Node may actually expand its' presence as a defacto runtime for wasm outside the browser.

Not to mention, cross platform (think x86, arm AND linux, mac, windows) from a single compile target.

You can compile C++ directly to MSIL if you want...

Ooh, instructions as to how would be super, please :)

is it somehow related to "mixed mode assemblies"[1]?

[1]: https://github.com/dotnet/coreclr/issues/18013

Visual studio compiler option "/clr": https://www.visualcplusdotnet.com/visualcplusdotnet1.html

There's a bunch of language extensions which let you access C# heap, string types etc from C++. You may want to define a "shim" layer to do the translation, but the bulk of your existing C++ can just compile straight across.

Eric Sink is a great developer and blogger. If you have a bit of time, do yourself a favor and go through his entire archive ;)

-> https://ericsink.com/tocs/topics.html

Yep. One of my all-time favorite blog posts anywhere is his 2003 post "The .NET Abstraction Pile", where he lists 40-some different abstraction layers involved in clicking the "Check In" button in a networked version control system:

https://ericsink.com/Abstraction_Pile.html

A particularly good quote:

> I stop whenever I get to Physics or Chemistry. For my purposes, light is real, not an abstraction.

This reminds me of the early days of .NET when COM objects could be used with a shim that allowed .NET applications to consume existing COM components... but the lifecycle and memory management of those objects were beyond the ability of .NET to control and an error in the COM object could still crash your .NET app even though the loading and unloading of the COM component was wrapped in a try/catch... such frightful memories! I'm curious how the GC/exception handling story will be different by going through WASM to MSIL as opposed to the days prior to framework 2.0 and COM components.

From the article:

> Whatever you call it, what this project does is take a WebAssembly module and convert it into a .NET assembly on disk.

So running such code should be no different than any other .Net code in that regard.

yeah, assuming that I've not got the wrong end of the stick, you could still have all the usual C/C++ issues take down your process. Although, seriously...pinvoke and the like are a PAIN. This is really interesting. Cheers.

As far as I understood, this project emits CIL (MSIL), and does not rely on PInvoke.

As such I don't see how it wouldn't play nice, unlike PInvoke/COM stuff, which is native code doing whatever native code feels like.

A cool project indeed!

I wonder thought if one could just build CIL backend for LLVM.

This is madness ... awesome madness

Reply on news.ycombinator.com