3 ms·

Speaking of, today you can use https://gircore.github.io https://gircore.github.io for rich GObject (and GTK4) interop. It is relatively new hence not widely kn

Speaking of, today you can use https://gircore.github.io https://gircore.github.io for rich GObject (and GTK4) interop. It is relatively new hence not widely known but is already used by e.g. https://www.pinta-project.com https://www.pinta-project.com. It's a proper and actively maintained successor to GtkSharp.

giancarlostoro 2y ago
That gives me a messed up idea of using Vala to implement a main GUI and then embedding mono to let users expand your app using this.
- neonsunset 2y ago
  Embedding Mono today might be a mistake. You really do want to embed CoreCLR instead if you can, even though it's a bit more complex. The reason for this is the up-to-date Mono (that keeps up on runtime features and library support) lives here: https://github.com/dotnet/runtime/tree/main/src/mono https://github.com/dotnet/runtime/tree/main/src/mono After .NET became what it is today, many Mono components simply became part of the codebase there. Most notably Mono linker which became ILLink, a critical component of assembly trimming and AOT compilation to native binaries. However, Mono is significantly slower than CoreCLR, frequently does not have the optimizations that performance-oriented code paths expect, only supports 128b SIMD and now serves the purpose of supporting exotic targets like WASM, monoaot for iOS (it will be eventually superseded), ARMv6 or just new platforms in the process of bring-up. In any case, if you still plan to use Mono, it is best to use the one from dotnet/runtime. Alternatively, you can build dynamically linked libraries with NativeAOT (it literally gives you plain .so files) and use that for extensibility instead. Note that they do not support unloading and live throughout the duration of the process.
  - giancarlostoro 2y ago
    Not specifically married to Mono, just what came to mind as I typed it. Regular .NET works just unfamiliar with how commonly it gets embedded.

giancarlostoro 2y ago

That gives me a messed up idea of using Vala to implement a main GUI and then embedding mono to let users expand your app using this.

neonsunset 2y ago
Embedding Mono today might be a mistake. You really do want to embed CoreCLR instead if you can, even though it's a bit more complex. The reason for this is the up-to-date Mono (that keeps up on runtime features and library support) lives here: https://github.com/dotnet/runtime/tree/main/src/mono https://github.com/dotnet/runtime/tree/main/src/mono After .NET became what it is today, many Mono components simply became part of the codebase there. Most notably Mono linker which became ILLink, a critical component of assembly trimming and AOT compilation to native binaries. However, Mono is significantly slower than CoreCLR, frequently does not have the optimizations that performance-oriented code paths expect, only supports 128b SIMD and now serves the purpose of supporting exotic targets like WASM, monoaot for iOS (it will be eventually superseded), ARMv6 or just new platforms in the process of bring-up. In any case, if you still plan to use Mono, it is best to use the one from dotnet/runtime. Alternatively, you can build dynamically linked libraries with NativeAOT (it literally gives you plain .so files) and use that for extensibility instead. Note that they do not support unloading and live throughout the duration of the process.
- giancarlostoro 2y ago
  Not specifically married to Mono, just what came to mind as I typed it. Regular .NET works just unfamiliar with how commonly it gets embedded.