C#中LibraryImport源生成_C#源生成互操作教程【精通】-C#.Net教程-PHP中文网

libraryimport 在 .net 7+ 中是 aot 编译、il 剪裁和调试封送逻辑的必要前提，而非可选优化；若仍用 dllimport 构建本机 aot 应用（如 macos arm64、linux 容器），将直接编译报错或运行时崩溃。

c#中libraryimport源生成_c#源生成互操作教程【精通】

LibraryImport 在 .NET 7+ 中不是“可选优化”，而是 AOT 编译、IL 剪裁、调试封送逻辑的必要前提。如果你还在用 DllImport，且目标是发布本机 AOT 应用（如 macOS ARM64、Linux 容器、Windows 桌面精简包），那它会在编译阶段直接报错或运行时崩溃——不是性能问题，是根本不可用。

为什么 `LibraryImport` 不能简单替换成 `DllImport` 写法？

表面看只是把 extern 换成 partial、DllImport 换成 LibraryImport，但底层行为完全不同：

DllImport 依赖运行时 JIT 生成 IL 存根，而 LibraryImport 在 编译期生成 C# 源码（位于 obj/Debug/net8.0/GeneratedFiles/ 下），你能在调试器里单步进入封送逻辑
StringMarshalling 参数只在 LibraryImport 中有效；DllImport 用 CharSet，但该设置对 string 返回值无效，常导致乱码
SetLastError = true 在 LibraryImport 中必须显式配对 [return: MarshalAs(UnmanagedType.Bool)] 或手动调用 Marshal.GetLastWin32Error()，否则错误码被丢弃
不支持 BestFitMapping、ThrowOnUnmappableChar 等旧式封送选项——它们已被移除，不是“暂时不支持”

`LibraryImport` 中字符串参数怎么写才不崩？

最常见崩溃点：C 函数接收 const char*，C# 传 string 却没指定编码，结果传了 UTF-16 指针给 expecting UTF-8 的函数。

"避开 C# 常见错误——空陷阱、异步陷阱、LINQ 陷阱及资源泄漏。"

下载

明确用 StringMarshalling.Utf8（推荐）：

[LibraryImport("nativelib", StringMarshalling = StringMarshalling.Utf8)]
internal static partial void ProcessText(string text);

若 C 端是 Windows API 风格（LPCWSTR），用 StringMarshalling.Utf16
避免混用：[MarshalAs(UnmanagedType.LPWStr)] + LibraryImport 是合法的，但仅限返回值或参数单独标注；全局 StringMarshalling 优先级更高，会覆盖它
传空字符串 "" 时，Utf8 模式下生成的是 null 指针（符合 C 习惯），不是长度为 0 的缓冲区——这点和 DllImport 行为不同

结构体传参失败，90% 是因为没加 `MarshalUsingAttribute`

当 C 函数原型是 void update_config(config_t* cfg)，且 config_t 含指针字段（如 char* name）或变长数组，LibraryImport 默认只做位拷贝（blittable），不会自动封送嵌套内存。

必须为结构体字段显式指定封送器：

[StructLayout(LayoutKind.Sequential)]
public struct Config
{
    public int version;
    [MarshalUsing(typeof(Utf8StringMarshaller))]
    public string name;
}

Utf8StringMarshaller 不是内置类型，需自己实现或引用 Microsoft.Interop 包中的现成实现

别漏掉 CustomMarshallerAttribute 在 marshaller 类上：

[CustomMarshaller(typeof(string), MarshalMode.ManagedToUnmanagedIn, typeof(Utf8StringMarshaller))]
public static class Utf8StringMarshaller { ... }

如果结构体本身要作为返回值（非指针），且含非 blittable 字段，LibraryImport 直接编译失败——必须改为 ref Config 或指针参数

从 `DllImport` 迁移时最容易忽略的兼容性断点

迁移不是搜索替换。以下三点不处理，编译能过，运行必挂：

CallingConvention：默认从 Winapi（即 StdCall）变成 Cdecl，Linux/macOS 库几乎全是 Cdecl，但 Windows DLL 很多是 StdCall。必须显式写 CallingConvention = CallingConvention.StdCall
EntryPoint 必须写全：C++ 导出函数经 name mangling 后名字已变，LibraryImport 不做修饰名解析，EntryPoint = "?Process@Util@@YA?AVstd::string@@V12@@Z" 这种才有效，而不是靠 ExactSpelling = false
回调函数（delegate*）必须用 UnmanagedCallersOnly 标记，且不能捕获局部变量——这是源生成硬性限制，不是警告

真正麻烦的从来不是“怎么写对”，而是“为什么看起来对却不对”。比如 StringMarshalling.Utf8 在 Linux 上正常，在 Windows 上调用某些系统 DLL 却返回空——那八成是对方内部用了 MultiByteToWideChar 反向转换，你得换回 Utf16。这种细节没有文档，只有跑起来看内存 dump。