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 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.
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 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.