关于在原生应用中嵌入现代.NET Mono的技术咨询

一、构建后必需文件说明 #

你基于.NET Runtime v8.0.4构建Mono时，仅libcoreclr.so和System.Private.CoreLib.dll是不够的——libcoreclr.so是CoreCLR运行时的产物，Mono对应的核心运行时库是libmonosgen-2.0.so（Linux x64平台）。完整的必需文件包括：

• 运行时核心库：libmonosgen-2.0.so（负责Mono的JIT编译、GC等核心运行时功能）
• 基础类库：System.Private.CoreLib.dll（.NET基础类库的私有实现，托管代码的核心依赖）
• 头文件集：include/mono目录下的所有头文件（原生程序编译时需引用这些文件调用Mono API，比如mono/jit/jit.h、mono/metadata/metadata.h等）
• 配置文件：mono-config（可选但建议保留，用于配置程序集搜索路径、GC策略等运行时参数）
• 附加类库：如果托管代码依赖System.dll、System.Core.dll等其他.NET类库，需将对应DLL放置在可执行文件同级目录或指定的程序集搜索路径中

二、旧版独立Mono与.NET Runtime整合版Mono的嵌入区别 #

• 仓库与生态：旧版Mono是独立仓库，自身维护一套类库体系；现代Mono已整合进.NET Runtime仓库，完全共享.NET统一的基础类库和生态，无需单独维护类库分支
• API兼容与演进：核心嵌入API（如mono_jit_init、mono_assembly_load）保持向后兼容，但现代Mono新增了适配.NET新特性的API，同时移除了旧版中过时的API
• 构建流程：旧版Mono需单独构建，依赖自身的构建系统；现代Mono使用.NET Runtime统一的build.sh构建脚本，参数和产物结构与CoreCLR保持一致
• 功能支持：现代Mono支持.NET 8+的新特性（如Native AOT、分层编译优化），而旧版Mono的特性更新滞后，与.NET生态的整合度较低

三、现代Mono的定位与交互方式 #

• 并非CoreCLR精简版：现代Mono和CoreCLR是.NET生态中两个独立的运行时，定位不同——Mono主打跨平台嵌入、小体积、移动/嵌入式场景；CoreCLR主打高性能、服务器端、桌面应用场景。两者共享.NET基础类库，但运行时的JIT编译器、GC实现等核心机制完全不同
• 原生程序交互：原生程序与现代Mono的交互确实通过Mono API实现，从运行时初始化、托管程序集加载到托管方法调用，核心流程与旧版Mono一致，方便现有嵌入代码迁移

四、CoreCLR的静态链接可行性 #

CoreCLR支持静态链接，但存在场景限制：

• 支持场景：仅在Native AOT编译场景下，可将CoreCLR运行时与托管代码静态链接为单一可执行文件；常规的动态加载托管代码的嵌入场景，通常使用动态链接方式
• 平台限制：静态链接仅支持部分主流平台（如Windows x64、Linux x64），且需要使用特定的构建参数，同时需处理系统依赖库的静态链接问题

内容的提问来源于stack exchange，提问作者purepelmen