c++ native aot与c#交互 c++如何调用native aot编译的c#库-C++-PHP中文网

native aot编译的c#库需用[unmanagedcallersonly]显式导出c兼容函数，仅支持基本类型参数、指定调用约定，c++须动态加载并手动处理字符串和内存生命周期。

c++ native aot与c#交互 c++如何调用native aot编译的c#库

Native AOT 编译的 C# 库不能直接被 C++ 调用

Native AOT（如 dotnet publish -r win-x64 --self-contained true -p:PublishAot=true）生成的是独立可执行文件或静态库，但不导出标准 C ABI 符号，也没有内置的 DLL 导出表。C++ 的 LoadLibrary + GetProcAddress 或隐式链接会失败——不是找不到 DLL，而是找到后调不到函数。

必须用 C# 显式导出 C 兼容函数（`UnmanagedCallersOnly`）

Native AOT 支持有限的互操作入口：只有标记 [UnmanagedCallersOnly] 的 static 方法才能被外部语言调用。它要求：

方法必须是 static、internal 或 public
参数和返回值只能是基本类型（int、double、IntPtr）、指针或固定大小数组（fixed int arr[10]）
不能用托管对象（string、object、List<t></t>）直接传参
必须指定调用约定：CallingConvention.Cdecl（Windows/Linux 常用）或 StdCall（仅 Windows）

示例 C# 导出函数：

[UnmanagedCallersOnly(CallConvs = new[] { typeof(CallConvCdecl) })]
public static int add(int a, int b)
{
    return a + b;
}

编译后，这个 add 才会在 DLL 的导出表里出现，C++ 才能 GetProcAddress(hDll, "add") 成功。

C++ 侧加载需注意平台与符号修饰

Native AOT 默认生成的是 .dll（Windows）或 .so（Linux），但符号名可能被编译器修饰（mangling）。C# 的 [UnmanagedCallersOnly] 会禁用 C++ 风格修饰，但仍可能受平台 ABI 影响：

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

Windows 上默认是 __cdecl，函数名导出为原名（如 add），但若项目启用了 /Gz（StdCall 默认）等选项，需同步 C# 的 CallConvStdCall
Linux/macOS 上无名称修饰，但必须用 dlopen/dlsym，且确保运行时能找到 .so（LD_LIBRARY_PATH 或 rpath）
不要尝试用 #include <xxx.h></xxx.h> 或 lib 文件链接——Native AOT 不生成 .lib，也不支持隐式链接

C++ 调用片段（Windows）：

HMODULE hDll = LoadLibrary(L"mylib.dll");
if (hDll) {
    typedef int (*add_func)(int, int);
    add_func add = (add_func) GetProcAddress(hDll, "add");
    if (add) {
        int result = add(2, 3); // → 5
    }
}

字符串和复杂数据必须手动 marshal

string、数组、结构体不能直传。C# 侧要转成 char* 或 byte*，C++ 侧负责内存管理或约定生命周期：

C# 用 Marshal.StringToHGlobalAnsi 或 Encoding.UTF8.GetBytes + fixed 拷贝到非托管内存，返回 IntPtr
C++ 接收 const char* 后，若需长期持有，必须 strdup 或自行拷贝
回调函数也得用 [UnmanagedCallersOnly] 导出，C++ 传入函数指针前需用 reinterpret_cast 转换（且确保调用约定一致）
没有 GC 协调：C++ 分配的内存不能交给 C# 自动释放，反之亦然