5 ms·

Running WebAssembly and WASI with .Net

65 points by mouldysammich 7y ago

indentit 7y ago
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.
- fxfan 7y ago
  You're in luck- MS released a WASM GUI kit- Blazor
  - nicoburns 7y ago
    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.
    - arethuza 7y ago
      Presumably you have to compile the C++ once to wasm though?
      - tybit 7y ago
        Yeah you would, though having a common compile to target would hopefully make it easier to find pre compiled wasm binaries.
        WorldMaker 7y ago
        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.
        tracker1 7y ago
        Absolutely... I have a suspicion that Node may actually expand its' presence as a defacto runtime for wasm outside the browser.
    - tracker1 7y ago
      Not to mention, cross platform (think x86, arm AND linux, mac, windows) from a single compile target.
- pjc50 7y ago
  You can compile C++ directly to MSIL if you want...
  - indentit 7y ago
    Ooh, instructions as to how would be super, please :)
    - indentit 7y ago
      is it somehow related to "mixed mode assemblies"[1]? [1]: https://github.com/dotnet/coreclr/issues/18013 https://github.com/dotnet/coreclr/issues/18013
    - pjc50 7y ago
      Visual studio compiler option "/clr": https://www.visualcplusdotnet.com/visualcplusdotnet1.html 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.
oblio 7y ago
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 https://ericsink.com/tocs/topics.html
- acemarke 7y ago
  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 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.
mikece 7y ago
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.
- magicalhippo 7y ago
  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.
  - youdontknowtho 7y ago
    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.
    - magicalhippo 7y ago
      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.
CodeCube 7y ago
This is madness ... awesome madness
lostmsu 7y ago
A cool project indeed! I wonder thought if one could just build CIL backend for LLVM.

65 points by mouldysammich 7y ago

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.

fxfan 7y ago
You're in luck- MS released a WASM GUI kit- Blazor
- nicoburns 7y ago
  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.
  - arethuza 7y ago
    Presumably you have to compile the C++ once to wasm though?
    - tybit 7y ago
      Yeah you would, though having a common compile to target would hopefully make it easier to find pre compiled wasm binaries.
      - WorldMaker 7y ago
        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.
        tracker1 7y ago
        Absolutely... I have a suspicion that Node may actually expand its' presence as a defacto runtime for wasm outside the browser.
  - tracker1 7y ago
    Not to mention, cross platform (think x86, arm AND linux, mac, windows) from a single compile target.
pjc50 7y ago
You can compile C++ directly to MSIL if you want...
- indentit 7y ago
  Ooh, instructions as to how would be super, please :)
  - indentit 7y ago
    is it somehow related to "mixed mode assemblies"[1]? [1]: https://github.com/dotnet/coreclr/issues/18013 https://github.com/dotnet/coreclr/issues/18013
  - pjc50 7y ago
    Visual studio compiler option "/clr": https://www.visualcplusdotnet.com/visualcplusdotnet1.html 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.

oblio 7y ago

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 https://ericsink.com/tocs/topics.html

acemarke 7y ago
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 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.

mikece 7y ago

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.

magicalhippo 7y ago
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.
- youdontknowtho 7y ago
  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.
  - magicalhippo 7y ago
    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.

CodeCube 7y ago

This is madness ... awesome madness

lostmsu 7y ago

A cool project indeed! I wonder thought if one could just build CIL backend for LLVM.