C# nativeAOT生成C可调用DLL时如何导出函数？

Question

在使用 C# NativeAOT 编译生成可供 C 语言调用的 DLL 时，如何正确导出函数是一个关键问题。由于 C# 默认不支持传统的 `__declspec(dllexport)`，开发者需借助 `UnmanagedCallersOnly` 特性标记方法，并在项目中启用 NativeAOT 发布模式。常见问题是：即使标注了特性，C 代码仍无法通过 `LoadLibrary` 或 `GetProcAddress` 找到函数符号。这通常源于函数未被正确链接、名称修饰问题或缺少入口点配置。此外，字符串和内存管理的跨语言传递也易引发崩溃。如何确保函数符号以 C 兼容方式导出并被正确调用？

Answer 1

使用 C# NativeAOT 导出函数供 C 调用的深度解析

1. 基础概念：从托管到原生的桥梁

C# 作为一门托管语言，默认运行在 .NET 运行时之上，无法直接生成传统意义上的 DLL 函数导出表。然而，随着 NativeAOT（Ahead-of-Time Compilation）的引入，C# 可以编译为完全独立的原生二进制文件，包括可被 C 调用的 DLL。

关键在于：UnmanagedCallersOnly 特性允许标记一个方法，使其能被非托管代码调用。该特性替代了传统的 __declspec(dllexport)，但其行为依赖于编译器和链接器的协同工作。

示例代码如下：

[UnmanagedCallersOnly(EntryPoint = "add")]
public static int Add(int a, int b)
{
    return a + b;
}

此处 EntryPoint = "add" 显式指定导出名称，避免 C++ 名称修饰问题。

项目需启用 NativeAOT 发布模式，在 .csproj 中添加：

<PropertyGroup>
  <PublishAot>true</PublishAot>
  <RuntimeIdentifier>win-x64</RuntimeIdentifier>
</PropertyGroup>

这是实现跨语言调用的第一步，确保编译输出为原生 DLL 而非托管程序集。

2. 符号导出机制与常见陷阱

即使使用了 UnmanagedCallersOnly，函数仍可能未出现在导出表中。原因通常包括：

1. 方法未被“根引用”（rooted），被 AOT 编译器视为无用代码而剥离
2. 缺少显式入口点配置，导致符号名称被修饰或隐藏
3. 目标平台不匹配（如 x86 vs x64）
4. 未正确设置 RuntimeIdentifier

可通过工具如 dumpbin /exports YourLibrary.dll 验证导出符号是否存在。

若输出为空，则说明函数未被链接进最终二进制。解决方案之一是通过 DynamicDependency 或全局入口点防止裁剪：

[DynamicDependency(nameof(Add))]
class EntryPointHolder { }

另一种方式是在 Program.cs 中显式引用该函数，确保其被保留。

此外，建议始终使用 EntryPoint 参数明确命名，避免 C/C++ 端因名称修饰无法定位函数。

3. 字符串与内存管理的跨语言挑战

当涉及字符串传递时，托管与非托管内存模型差异显著。C# 字符串为 UTF-16（char*），而 C 多使用 UTF-8（const char*）。

错误示例如下：

[UnmanagedCallersOnly(EntryPoint = "GetString")]
public static IntPtr GetString()
{
    string managedStr = "Hello from C#";
    // 错误：局部 pinning 生命周期不可控
    var handle = GCHandle.Alloc(managedStr, GCHandleType.Pinned);
    return Marshal.StringToHGlobalAnsi(managedStr); // 潜在内存泄漏
}

正确做法应使用 Marshal.StringToCoTaskMemUTF8 并由 C 端负责释放：

类型	C# 类型	C 类型	转换方式
字符串输入	IntPtr	const char*	Marshal.PtrToStringUTF8(ptr)
字符串输出	IntPtr	char*	Marshal.StringToCoTaskMemUTF8(str)
内存释放	-	CoTaskMemFree	必须由调用方释放

此设计遵循 COM 内存约定，确保跨语言兼容性。

4. 调用流程与调试策略

完整的调用链路如下所示：

graph TD A[C Code: LoadLibrary("MyLib.dll")] --> B{成功?} B -- 是 --> C[GetProcAddress("add")] B -- 否 --> D[GetLastError()] C --> E{函数指针有效?} E -- 是 --> F[调用 Add(2,3)] E -- 否 --> G[检查导出表] F --> H[返回结果]

若 GetProcAddress 返回 NULL，应立即调用 GetLastError() 并结合 dumpbin /exports 分析符号是否存在。

推荐构建脚本自动化验证流程：

dotnet publish -c Release -r win-x64 --self-contained
dumpbin /exports bin/Release/net8.0/win-x64/publish/MyLib.dll

确保输出包含预期的函数名，如 add。

5. 高级配置与最佳实践

为提升稳定性，建议在项目中启用以下配置：

• <IlcGenerateMetadataFile>false</IlcGenerateMetadataFile>：减小体积
• <IlcDisableReflection>true</IlcDisableReflection>：关闭反射以优化性能
• 使用 NativeLibrary API 在 C# 端测试导出函数

还可通过 IL Linker 指令保留特定类型：

<LinkerDescriptor Include="linker.xml" />

其中 linker.xml 内容为：

<linker>
  <assembly fullname="MyLibrary">
    <type fullname="MyLibrary.NativeExports" required="true" />
  </assembly>
</linker>

这确保关键导出类不会被裁剪。