1. 项目概述为什么我们需要跨越C与.NET的边界在软件开发的江湖里C和.NET尤其是C#常常被视为两个泾渭分明的世界。C以其无与伦比的性能、对硬件的直接操控能力以及跨平台的潜力牢牢占据着系统底层、游戏引擎、高频交易、嵌入式设备等领域的核心地位。而C#与.NET平台则以其优雅的语法、强大的生产力、丰富的类库和稳健的内存管理成为企业级应用、桌面GUI、Web后端和快速业务原型开发的首选。但现实项目往往不是非此即彼的单选题。你可能会遇到一个用C写了十几年的核心算法库性能经过千锤百炼现在需要用C#开发一个新的前端界面来调用它或者你有一个成熟的C#业务系统但其中某个计算密集型模块遇到了性能瓶颈需要用C重写来榨干硬件性能。这时“C与.NET之间的互相调用”就不再是一个纸上谈兵的技术话题而是实实在在的项目需求是连接两个强大生态的桥梁。这个“互相调用”的示例项目其核心价值在于打通性能与效率之间的任督二脉。它解决的不仅仅是技术上的“能不能调用”更是工程上的“如何高效、稳定、安全地调用”。这涉及到数据如何在托管内存.NET的GC管理和非托管内存C的堆栈之间安全传递复杂对象如何映射异常如何跨越边界不丢失信息以及调用本身带来的性能开销如何最小化。理解并掌握这套技术意味着你能够站在巨人的肩膀上灵活组合最佳工具而不是被单一技术栈所束缚。无论是希望复用遗留C代码的.NET开发者还是需要为C模块提供现代化接口或界面的C工程师这都是必须掌握的进阶技能。2. 核心思路与方案选型四种桥梁的优劣之辩要实现C与.NET的互操作主流有四种技术路径每一种都有其特定的适用场景和代价。选择哪种取决于你的具体需求是追求极致性能还是开发效率是单向调用还是需要复杂的双向回调2.1 Platform Invoke (PInvoke)轻量级的单向通道PInvoke是.NET框架提供的最基础、最直接的调用非托管代码主要是C风格DLL的机制。它的工作模式非常直观在C#侧使用[DllImport]特性声明一个外部函数指定DLL路径和函数签名然后就可以像调用普通C#方法一样使用它。适用场景调用成熟的、稳定的、以C接口extern “C”暴露的第三方库或遗留库。例如调用一个用于图像处理的OpenCV的C接口DLL或者调用操作系统本身的API如Win32 API。优势简单直接声明即用无需额外的中间层或包装。零依赖除了.NET框架本身不需要引入任何其他运行时或组件。对C侧侵入性小C侧只需要编译成标准的、导出C风格函数的DLL即可。劣势与挑战“平板”结构限制只能很好地传递基本数据类型int, double、指针和简单的结构体。对于复杂的C类对象尤其是包含虚函数表、STL容器的需要“展平”为C风格接口过程繁琐且易错。内存管理责任清晰如果传递了指针谁分配内存、谁释放内存必须约定清楚否则极易导致内存泄漏或访问冲突。仅限于函数调用难以实现C对象生命周期的托管以及复杂的回调机制。注意使用PInvoke时字符串的传递需要特别小心。C#的string是UnicodeUTF-16而C的char*通常是ANSI或UTF-8。需要使用Marshal.PtrToStringAnsi或指定CharSet特性来正确编组Marshaling。2.2 C/CLI血脉相连的混血儿C/CLI是微软提供的一种特殊的C方言它允许你在同一个项目、甚至同一个源文件里编写托管代码.NET和非托管代码原生C。编译器会生成一种特殊的程序集其中既包含IL中间语言元数据也包含原生机器码。适用场景需要创建高度集成、性能关键且需要复杂对象互操作的桥梁层。它是包装复杂C类库供.NET使用的黄金标准。优势无缝互操作可以直接在托管代码中声明和使用原生C指针、引用和栈对象反之亦然。编译器负责处理大部分繁琐的编组工作。对象封装自然可以将整个C类包装成一个托管类对.NET使用者完全隐藏其非托管本质提供面向对象的友好接口。性能优异由于编译器的深度支持托管与非托管之间的转换开销在四种方案中通常是最小的。劣势与挑战语言特殊性需要学习一套新的语法如gcrootT模板、^托管指针符号增加了学习成本。部署依赖生成的混合程序集需要目标机器安装对应版本的.NET Framework和VC运行时。平台限制虽然理论上.NET Core/5有有限支持但C/CLI与完整的.NET Framework绑定最紧密在跨平台Linux, macOS场景下支持不佳。2.3 COM Interop经久不衰的企业级标准组件对象模型COM是一种古老的二进制接口标准。.NET通过运行时可调用包装RCW和COM可调用包装CCW提供了与COM组件互操作的完整支持。适用场景集成那些已经以COM组件形式存在的、非常成熟的C代码库例如一些老的工业控制软件组件、Office自动化库。优势标准化接口COM定义了一套严格的二进制标准稳定性极高。语言中立不仅限于C和C#任何支持COM的语言如VB6, Delphi都可以调用。.NET工具链支持好Visual Studio可以很方便地为COM类型库生成互操作程序集Interop Assembly。劣势与挑战复杂性高COM本身的概念IUnknown, IDL, GUID, 引用计数就非常复杂。开发繁琐让一个C库支持COM需要编写大量的样板代码IDL文件、实现QueryInterface,AddRef,Release等。“过时”感对于全新的项目引入COM显得过于沉重和古老。2.4 基于Socket/进程间通信(IPC)的松耦合调用当上述三种基于本地模块集成的方案都不适用时例如需要跨进程、跨机器或者双方进程生命周期独立可以考虑基于网络Socket或IPC如命名管道、内存映射文件的通信方式。C端作为服务端.NET端作为客户端通过预定义的协议如JSON-RPC、gRPC、或自定义二进制协议进行通信。适用场景大型系统解耦、跨语言微服务、需要独立部署和更新的模块。优势完全解耦双方进程独立语言、技术栈、部署方式互不影响。跨机器与跨平台潜力可以轻松扩展到分布式系统。容错性高一方崩溃不一定导致另一方崩溃。劣势与挑战性能开销大序列化、反序列化、网络传输带来的延迟远高于本地调用。复杂度转移需要设计通信协议、处理连接管理、超时、重试等分布式系统问题。开发量激增需要实现完整的客户端/服务器逻辑。方案选型速查表特性/方案PInvokeC/CLICOM InteropSocket/IPC耦合度紧DLL极紧混合程序集紧COM组件松进程/网络性能高非常高中高低相对本地开发复杂度低-中中-高高高对象支持差需展平优秀可直接包装类好基于接口依赖协议跨平台支持.NET Core/5 好.NET Framework 好 .NET Core 有限Windows 好优秀适用阶段集成稳定C库新建高性能桥梁层集成遗留COM组件系统解耦/分布式对于大多数需要深度集成、且性能要求较高的全新项目C/CLI通常是首选。而对于简单的函数调用或集成现有C库PInvoke则更轻快。本项目示例将重点深入讲解最具代表性的前两种方案PInvoke和C/CLI并提供一个完整的、可运行的实例。3. 实战一使用PInvoke调用C DLL让我们从一个相对简单的场景开始我们有一个用C编写的数学计算库它导出了几个C风格的函数。我们现在需要一个C#的WPF或WinForms桌面应用来使用这个库。3.1 C侧创建与导出DLL首先在Visual Studio中创建一个“动态链接库(DLL)”项目命名为NativeMathLib。关键步骤1定义头文件使用extern “C”为了防止C编译器对函数名进行修饰Name Mangling我们必须使用extern “C”来声明需要导出的函数。同时使用__declspec(dllexport)来指定导出。// NativeMathLib.h #pragma once #ifdef NATIVEMATHLIB_EXPORTS #define NATIVEMATHLIB_API __declspec(dllexport) #else #define NATIVEMATHLIB_API __declspec(dllimport) #endif extern C { // 导出函数计算两个整数的和 NATIVEMATHLIB_API int Add(int a, int b); // 导出函数计算点到原点的距离演示结构体传递 struct Point { double x; double y; }; NATIVEMATHLIB_API double DistanceToOrigin(const Point* p); // 导出函数反转字符串演示字符串/指针内存管理 // 注意调用者负责分配和释放输出缓冲区 NATIVEMATHLIB_API void ReverseString(const char* input, char* output, int bufferSize); }关键步骤2实现源文件// NativeMathLib.cpp #include pch.h #include NativeMathLib.h #include cstring // for strlen, strcpy_s #include algorithm // for std::reverse int Add(int a, int b) { return a b; } double DistanceToOrigin(const Point* p) { if (p nullptr) return 0.0; return sqrt(p-x * p-x p-y * p-y); } void ReverseString(const char* input, char* output, int bufferSize) { if (input nullptr || output nullptr || bufferSize 0) return; // 计算输入长度确保不超过缓冲区大小-1为\0留空间 size_t len strlen(input); if (len static_castsize_t(bufferSize)) { len bufferSize - 1; } // 拷贝并反转 strcpy_s(output, bufferSize, input); std::reverse(output, output len); // 确保字符串以null结尾 output[len] \0; }编译该项目我们会得到NativeMathLib.dll和NativeMathLib.lib文件。.dll是运行时需要的动态库.lib是编译时需要的导入库。3.2 C#侧使用DllImport进行调用在C#控制台或WPF项目中我们首先需要将NativeMathLib.dll复制到项目的输出目录如bin\Debug。然后我们创建一个静态类来封装这些PInvoke调用。using System; using System.Runtime.InteropServices; namespace CSharpClient { public static class NativeMathWrapper { // 1. 声明DLL路径和函数 // 如果DLL不在系统路径或当前目录需要指定完整路径或使用相对路径。 // CharSet.Ansi 指定字符串编码为ANSI对应C的char* [DllImport(NativeMathLib.dll, CallingConvention CallingConvention.Cdecl, CharSet CharSet.Ansi)] public static extern int Add(int a, int b); // 2. 传递结构体 // 需要定义与C侧内存布局完全一致的结构体 [StructLayout(LayoutKind.Sequential)] // 顺序布局保证字段顺序和内存对齐一致 public struct Point { public double X; public double Y; } [DllImport(NativeMathLib.dll, CallingConvention CallingConvention.Cdecl)] public static extern double DistanceToOrigin(ref Point point); // 使用ref传递指针 // 3. 处理字符串和指针内存管理重点 [DllImport(NativeMathLib.dll, CallingConvention CallingConvention.Cdecl, CharSet CharSet.Ansi)] public static extern void ReverseString(string input, StringBuilder output, int bufferSize); // 注意这里使用StringBuilder作为输出缓冲区它是可变的CLR会为其固定内存。 } class Program { static void Main(string[] args) { // 测试加法 int sum NativeMathWrapper.Add(5, 3); Console.WriteLine($5 3 {sum}); // 测试结构体 NativeMathWrapper.Point p new NativeMathWrapper.Point { X 3.0, Y 4.0 }; double distance NativeMathWrapper.DistanceToOrigin(ref p); Console.WriteLine($Distance from ({p.X}, {p.Y}) to origin is {distance}); // 测试字符串反转 string original Hello, PInvoke!; // 分配足够大的缓冲区通常为输入长度1 StringBuilder outputBuffer new StringBuilder(original.Length 1); NativeMathWrapper.ReverseString(original, outputBuffer, outputBuffer.Capacity); Console.WriteLine($Original: {original}); Console.WriteLine($Reversed: {outputBuffer.ToString()}); } } }3.3 PInvoke关键细节与避坑指南调用约定CallingConvention必须与C侧匹配。C/C默认通常是__cdecl而Windows API常用__stdcall。不匹配会导致栈不平衡程序崩溃。上例中我们使用了CallingConvention.Cdecl。字符串编码CharSet这是最常见的坑之一。C#的string是UnicodeUTF-16而C的char*通常是多字节字符集MBCS或UTF-8。CharSet.Ansi告诉编组器将字符串转换为ANSI格式。如果C侧是wchar_t*则应使用CharSet.Unicode并且C#侧参数类型可以是stringCLR会自动转换。结构体对齐LayoutKind与PackC编译器会对结构体成员进行内存对齐以提升访问速度。[StructLayout(LayoutKind.Sequential)]保证了字段顺序一致但有时还需要指定Pack值来匹配C侧的对齐方式如#pragma pack(1)。可以使用工具如dumpbin /headers YourDll.dll查看C结构体的实际布局或使用Marshal.SizeOf()和Marshal.OffsetOf()在C#侧调试。内存管理责任这是PInvoke中最需要谨慎对待的部分。基本原则是谁分配谁释放。C#分配C使用如传递StringBuilderCLR会固定其内存在调用期间C可以安全写入。调用结束后StringBuilder由C#的GC管理。C分配C#使用如果C函数返回一个new char[]分配的字符串指针C#端必须将其拷贝到托管内存如使用Marshal.PtrToStringAnsi并且C侧必须提供一个对应的释放函数如FreeString(char* ptr)由C#通过PInvoke调用该函数来释放内存。绝对不能用C#的Marshal.FreeHGlobal去释放Cnew出来的内存反之亦然这会导致堆损坏。异常处理PInvoke调用中如果C侧发生未处理的异常如访问违规它通常会直接导致整个.NET进程崩溃而不是转化为一个可捕获的.NETException。因此确保C侧代码的健壮性至关重要或者在C侧使用try-catch(...)捕获所有异常并返回错误码。4. 实战二使用C/CLI构建高性能桥梁当需要包装一个复杂的、面向对象的C类库时PInvoke就显得力不从心了。这时C/CLI是更优雅和强大的选择。我们将创建一个C/CLI类库项目它引用原生C静态库并暴露一个托管的.NET类给C#使用。4.1 项目结构与原生C库假设我们有一个纯粹的原生C库它实现了一个简单的“计数器”类。原生C头文件 (NativeCounter.h):#pragma once class NativeCounter { private: int m_count; public: NativeCounter(int initialValue 0); ~NativeCounter(); void Increment(int step 1); void Decrement(int step 1); int GetCurrent() const; void Reset(); };原生C实现文件 (NativeCounter.cpp):#include pch.h #include NativeCounter.h NativeCounter::NativeCounter(int initialValue) : m_count(initialValue) { printf([Native] Counter created with value: %d\n, m_count); } NativeCounter::~NativeCounter() { printf([Native] Counter destroyed. Final value: %d\n, m_count); } void NativeCounter::Increment(int step) { m_count step; printf([Native] Incremented by %d. New value: %d\n, step, m_count); } void NativeCounter::Decrement(int step) { m_count - step; printf([Native] Decremented by %d. New value: %d\n, step, m_count); } int NativeCounter::GetCurrent() const { return m_count; } void NativeCounter::Reset() { m_count 0; printf([Native] Counter reset to 0.\n); }我们将这个项目编译成一个静态库NativeCounter.lib。4.2 创建C/CLI包装器项目在同一个解决方案中新建一个“CLR类库”项目命名为ManagedCounterWrapper。在项目属性中需要配置属性 - 高级 - 公共语言运行时支持设置为“公共语言运行时支持(/clr)”。链接器 - 输入 - 附加依赖项添加NativeCounter.lib的路径。C/C - 常规 - 附加包含目录添加原生C项目的头文件目录。4.3 编写C/CLI包装类C/CLI的核心思想是在托管类中持有一个原生C对象的指针并在托管类的构造函数、析构函数、Finalizer中管理这个原生对象的生命周期。// ManagedCounter.h #pragma once #include NativeCounter.h // 包含原生C类的头文件 namespace ManagedCounterWrapper { // 这是一个托管类可以被C#等.NET语言引用 public ref class ManagedCounter { private: // 持有原生C对象的指针。使用‘native’关键字声明实际是NativeCounter*。 NativeCounter* m_nativeCounter; public: // 构造函数创建原生对象 ManagedCounter(int initialValue); // 析构函数Deterministic Destructor在Dispose()时调用确定性释放资源。 ~ManagedCounter(); // 终结器Finalizer在GC回收时调用作为资源释放的最后保障。 !ManagedCounter(); // 托管方法包装原生方法 void Increment(int step); void Decrement(int step); int GetCurrent(); void Reset(); }; }// ManagedCounter.cpp #include pch.h #include ManagedCounter.h namespace ManagedCounterWrapper { ManagedCounter::ManagedCounter(int initialValue) { // 在托管堆上创建对象时同时在本机堆上创建原生对象。 m_nativeCounter new NativeCounter(initialValue); printf([C/CLI] ManagedCounter wrapper created.\n); } ManagedCounter::~ManagedCounter() { // 这是析构函数对应Dispose模式。用户调用Dispose()或使用using语句时会执行。 this-!ManagedCounter(); // 调用终结器代码 printf([C/CLI] ManagedCounter deterministic cleanup (Dispose) called.\n); } ManagedCounter::!ManagedCounter() { // 这是终结器。如果用户没有调用DisposeGC会在回收对象前调用它。 if (m_nativeCounter ! nullptr) { delete m_nativeCounter; m_nativeCounter nullptr; printf([C/CLI] Native counter finalized by GC.\n); } } void ManagedCounter::Increment(int step) { if (m_nativeCounter ! nullptr) { m_nativeCounter-Increment(step); } } void ManagedCounter::Decrement(int step) { if (m_nativeCounter ! nullptr) { m_nativeCounter-Decrement(step); } } int ManagedCounter::GetCurrent() { return (m_nativeCounter ! nullptr) ? m_nativeCounter-GetCurrent() : 0; } void ManagedCounter::Reset() { if (m_nativeCounter ! nullptr) { m_nativeCounter-Reset(); } } }关键点解析ref class声明这是一个托管引用类型。NativeCounter*在托管类中存储原生对象的指针。~ManagedCounter()(析构函数)实现了IDisposable模式。当C#中使用using语句或手动调用Dispose()时触发。它应该调用终结器!ManagedCounter()来完成资源清理。!ManagedCounter()(终结器)由垃圾回收器在对象被回收前调用。它是资源不被泄漏的最后保障。重要在终结器中不要访问其他托管对象因为它们可能已经被GC回收了。生命周期管理最佳实践是同时实现析构和终结器提供确定性和非确定性两种清理方式。这遵循了.NET的IDisposable设计模式。4.4 C#端调用与资源管理编译C/CLI项目后会生成一个.dll如ManagedCounterWrapper.dll它是一个纯.NET程序集。在C#项目中像引用任何其他.NET库一样引用它即可。using ManagedCounterWrapper; using System; namespace CSharpClientForCLI { class Program { static void Main(string[] args) { Console.WriteLine( 使用using语句确定性清理); using (var counter1 new ManagedCounter(10)) { counter1.Increment(5); Console.WriteLine($Counter1 value: {counter1.GetCurrent()}); counter1.Decrement(2); Console.WriteLine($Counter1 value: {counter1.GetCurrent()}); } // 离开using范围Dispose()被自动调用原生资源立即释放。 Console.WriteLine(Counter1 has been disposed.\n); Console.WriteLine( 不使用using语句依赖GC非确定性清理); var counter2 new ManagedCounter(20); counter2.Increment(3); Console.WriteLine($Counter2 value: {counter2.GetCurrent()}); // 不调用Dispose()也不设置为null。 // 当counter2离开作用域且GC运行时终结器(!ManagedCounter)会被调用。 // 注意你无法控制GC何时运行所以资源释放是延迟的。 counter2 null; // 移除引用使对象成为GC候选目标 GC.Collect(); // 强制GC仅用于演示生产环境慎用 GC.WaitForPendingFinalizers(); Console.WriteLine(GC has been forced. Check output for finalizer message.\n); Console.WriteLine( 演示结束 ); } } }运行上述程序你会在控制台看到来自原生C、C/CLI包装器和C#的混合输出清晰地展示了对象的创建、方法调用和销毁过程。4.5 C/CLI进阶处理复杂类型与回调C/CLI的强大之处在于它能处理更复杂的场景。例如包装一个返回std::vectorstd::string的C方法。你不能直接将STL容器暴露给C#但可以在C/CLI层进行转换。// 假设原生C方法std::vectorstd::string GetNames(); arraySystem::String^^ ManagedWrapper::GetNames() { std::vectorstd::string nativeNames m_nativeObject-GetNames(); arraySystem::String^^ managedNames gcnew arraySystem::String^(nativeNames.size()); for (size_t i 0; i nativeNames.size(); i) { // 将std::string转换为System::String managedNames[i] gcnew System::String(nativeNames[i].c_str()); } return managedNames; }对于回调C#委托调用C函数指针C/CLI也提供了自然的映射。你可以将C#的Action或Func委托作为参数传递给C/CLI方法然后在C/CLI内部将其转换为原生函数指针或std::function再传递给底层的C代码。这个过程涉及到Marshal::GetFunctionPointerForDelegate需要小心保持委托的引用以防止被GC回收。5. 性能考量与最佳实践互操作是有开销的。每一次从托管代码跳转到非托管代码都会发生“托管/非托管转换”这包括参数编组、调用栈切换等。对于高频调用的简单函数比如一个在循环中调用百万次的加法这个开销可能是不可忽视的。性能优化建议批处理避免在紧密循环中频繁进行互操作调用。尽量设计粗粒度的接口让一次跨边界调用完成更多工作。例如不要在一个渲染循环中每帧调用一次UpdatePosition而是传递整个位置数组让C端批量处理。减少编组编组复杂类型如字符串、数组、结构体比编组基本类型开销大。尽量使用基本类型int, double, bool或指针。对于大型数据考虑使用unsafe代码和固定指针fixed关键字来直接访问内存避免复制。C/CLI优于PInvoke对于复杂的、面向对象的交互C/CLI的编组开销通常低于PInvoke因为编译器能生成更优化的转换代码。测量不要猜测使用性能分析工具如Visual Studio Profiler, dotTrace, PerfView来精确测量互操作调用的开销找到真正的瓶颈。通用最佳实践清晰的接口契约在项目早期就明确约定数据谁分配、谁释放异常如何传递使用哪种字符串编码等。充分的错误处理在边界两侧都进行严格的参数校验。C侧应返回错误码或使用异常并在C/CLI或PInvoke层将其转换为.NET异常。编写单元测试为互操作层编写全面的单元测试覆盖正常路径、边界情况和错误路径。这能极大提升集成代码的可靠性。文档化为暴露的API编写清晰的文档特别是关于内存所有权和线程安全性的说明。6. 常见问题与调试技巧实录在实际开发中你一定会遇到各种奇怪的问题。下面是一些典型问题及其排查思路问题1调用PInvoke函数时程序崩溃或抛出AccessViolationException。可能原因1调用约定不匹配。检查DllImport的CallingConvention是否与DLL导出函数一致。使用dumpbin /exports YourDll.dll查看导出函数名修饰名中包含了调用约定信息如_Add8是__stdcall_Add是__cdecl。可能原因2参数类型或顺序不匹配。仔细核对C函数签名和C#声明。特别是int与long、BOOL与bool在不同平台下的差异。可能原因3内存问题。例如传递了已释放的缓冲区指针或缓冲区大小不足。确保内存分配和释放的配对正确。排查工具使用调试器附加到进程在崩溃时查看调用栈。在C项目设置中启用“仅我的代码”调试并加载符号可以深入到C代码内部。问题2C/CLI项目编译时报错“无法找到PInvoke DLL”。可能原因项目生成事件中复制的DLL路径不对或者DLL依赖的其他动态库如特定版本的VC运行时不存在。解决方案使用Dependency Walker或Visual Studio自带的dumpbin /dependents工具查看DLL的依赖项确保所有依赖库都存在于运行目录或系统路径中。问题3字符串在传递后出现乱码。几乎可以肯定是编码问题。确认C侧是char*ANSI/UTF-8还是wchar_t*UTF-16/UCS-2。相应地在C#的DllImport中设置CharSet CharSet.Ansi或CharSet CharSet.Unicode。对于更复杂的UTF-8场景可能需要手动使用Marshal.StringToHGlobalAnsi和PtrToStringUTF8.NET Core 3.1 / .NET 5来处理。问题4在C/CLI包装器中调用原生对象方法时程序崩溃。可能原因托管包装对象已经被析构或终结m_nativeCounter指针为nullptr或悬垂指针但代码仍试图通过它调用方法。解决方案在每个包装方法开始时检查m_nativeCounter是否为nullptr。确保析构和终结逻辑正确并理解C#中Dispose模式和using语句的用法鼓励调用者及时清理资源。调试技巧在混合模式调试在Visual Studio的C#项目调试属性中勾选“启用本机代码调试”。这样你可以在C#和C代码中设置断点并单步执行跨越托管/非托管边界。使用日志在C和C/CLI代码的关键位置添加日志输出如printf或OutputDebugString这是追踪执行流程和检查参数值的有效方法。检查内存对于内存泄漏可以使用Visual Studio的内存分析器或ValgrindLinux等工具。对于C/CLI要特别注意确保每个new都有对应的delete并且终结器逻辑正确。掌握C与.NET的互操作就像掌握了连接两个强大王国的钥匙。它允许你在保持代码库历史投资的同时拥抱新的开发范式和技术。从简单的PInvoke到复杂的C/CLI包装选择合适的技术路径遵循最佳实践谨慎处理边界问题你就能构建出既高效又稳定的混合系统。
