5 ms·
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 th
by mikece 8y 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 8y agoFrom 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 8y agoyeah, 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 8y agoAs 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.