工业软件中C#与C/C++交互实战：P/Invoke、C++/CLI与COM技术详解

1. 项目概述：为什么工业软件离不开C#与C/C++的“混搭”？

干了这么多年工业软件，从最早的工控机到现在所谓的工业4.0、数字孪生，有一个技术组合始终绕不开，那就是C#和C/C++的交互。项目标题里提到的“10年实战案例”，一点不夸张，这几乎是工业软件架构里的“定式”。很多刚入行的朋友可能会问，现在C#性能也不差，.NET生态这么丰富，为什么非得去碰“古老”的C/C++？直接用C#从头写到尾不香吗？

这里面的核心矛盾，在于工业软件这个特殊领域对性能确定性和生态继承性的极致要求。C#（或者说.NET平台）的优势在于快速构建复杂、美观的用户界面，处理业务逻辑，以及高效的数据库操作。它的生产力极高，一个熟练的开发者用WPF或WinForms能很快搭出一个功能强大的上位机软件。但是，工业现场有大量“硬骨头”要啃：可能是需要微秒级响应的运动控制算法，可能是要直接操作某块特定内存地址的硬件驱动，也可能是已经存在了十几年、用C语言写的核心算法库（比如各种FFT变换、PID控制、机器视觉库）。这些任务，C#的托管环境（垃圾回收、运行时检查）会带来不可预测的延迟，或者根本无从下手。

而C/C++，恰恰是啃这些“硬骨头”的利器。它直接、高效，能进行精细的内存控制和硬件操作，拥有海量经过工业现场几十年验证的成熟库。所以，一个典型的工业软件架构往往是：用C#构建应用层（UI、网络通信、数据管理、报表），用C/C++构建核心层（实时计算、硬件驱动、专用算法）。两者之间，就需要一座坚固、高效的“桥梁”来通信。这座桥搭得好，软件就稳定高效；搭得不好，就是崩溃、内存泄漏、性能瓶颈的根源。接下来，我就结合这些年踩过的坑和总结的经验，把这套“搭桥”的实战技巧系统地拆解一遍。

2. 交互方案全景图：P/Invoke、C++/CLI与COM的选型博弈

当你决定要让C#和C/C++“握手”时，面前主要有三条大路：Platform Invoke (P/Invoke)、C++/CLI和COM。每条路都有自己的风景和坑洼，没有绝对的好坏，只有是否适合你的场景。

2.1 P/Invoke：轻量灵活的“外交官”

P/Invoke是.NET框架自带的功能，允许托管代码（C#）调用非托管DLL（通常是C语言接口的DLL）中的函数。你可以把它想象成一个精通两国语言的“外交官”，负责在托管世界和非托管世界之间传递消息。

它的使用非常简单，一个典型的例子是调用Windows API，但同样适用于你自己的C DLL：

using System; using System.Runtime.InteropServices; public class NativeInterop { // 关键：使用DllImport特性声明外部函数 [DllImport("MyIndustrialAlgo.dll", EntryPoint = "calculate_pid", CallingConvention = CallingConvention.Cdecl)] public static extern double CalculatePID(double setpoint, double pv, ref double integral, double kp, double ki, double kd); [DllImport("kernel32.dll", SetLastError = true)] public static extern IntPtr LoadLibrary(string dllPath); [DllImport("kernel32.dll", SetLastError = true)] [return: MarshalAs(UnmanagedType.Bool)] public static extern bool FreeLibrary(IntPtr hModule); }

为什么选择P/Invoke？

• 零依赖：除了.NET框架，不需要任何额外的运行时或编译器支持。
• 部署简单：只需要你的C#程序和对应的原生DLL文件。
• 适合C语言接口：如果你的C/C++代码主要以extern "C"方式导出纯C函数，这是最直接的选择。

实操心得与巨坑预警：

1. 数据封送（Marshaling）是头号杀手：P/Invoke在调用前后，会自动在托管堆和非托管堆之间转换数据类型。这个过程如果没配置好，轻则数据错乱，重则程序崩溃。
   • 结构体对齐：C/C++的结构体有内存对齐（如#pragma pack(1)），必须用[StructLayout(LayoutKind.Sequential, Pack = 1)]精确匹配，否则字段对不上。
   • 字符串传递：C#的string是Unicode，C端可能是char*(ANSI)。要用[MarshalAs(UnmanagedType.LPStr)]指定。更复杂的情况，如C端负责分配内存并返回char*，C#端要用IntPtr接收，并用Marshal.PtrToStringAnsi()手动转换和释放，否则百分百内存泄漏。

   [DllImport("MyLib.dll")] private static extern IntPtr get_error_message(); public static string GetErrorMessage() { IntPtr ptr = get_error_message(); string msg = Marshal.PtrToStringAnsi(ptr); // 关键！如果C端是用malloc分配的，这里必须调用C端的free函数来释放 // 通常DLL会配套提供一个 free_error_message(IntPtr ptr) 函数 free_error_message(ptr); return msg; }

2. 调用约定（Calling Convention）必须匹配：CallingConvention.Cdecl和CallingConvention.StdCall是天差地别的。通常，C/C++编译器默认的C函数调用约定是Cdecl（调用者清理栈），而很多Windows API是StdCall（被调用者清理栈）。不匹配直接导致栈损坏，崩溃都算轻的，有时会诡异地在别处出错。
3. DLL加载路径问题：DllImport里的DLL名，系统会按特定顺序搜索（程序目录、System32等）。在工业环境，我强烈建议使用绝对路径，或者先用LoadLibraryAPI动态加载，这样能明确控制版本和加载失败的处理。

   IntPtr dllHandle = LoadLibrary(@"C:\Program Files\MyApp\Drivers\plc_driver_v2.1.dll"); if (dllHandle == IntPtr.Zero) { int error = Marshal.GetLastWin32Error(); throw new Exception($"加载驱动失败，错误代码: {error}"); } // ... 之后使用P/Invoke调用该DLL中的函数 ... // 程序退出前，确保调用 FreeLibrary(dllHandle);

2.2 C++/CLI：深度集成的“特派员”

如果P/Invoke是“外交官”，那C++/CLI就是派驻在非托管世界的“特派员”。它本身是一种.NET语言，但能直接编写和编译包含原生C++代码的托管程序集（.dll）。这意味着你可以在一个项目里，同时写原生C++代码和托管C++/CLI代码，无缝互操作。

为什么选择C++/CLI？

• 无缝对象传递：可以直接在C#和C++之间传递复杂的C++对象指针，而无需费力地拆解成P/Invoke能理解的简单类型。
• 异常跨越边界：可以将C++异常转换为.NET异常，让错误处理逻辑统一。
• 性能更高：对于频繁调用或需要传递大量复杂数据的场景，C++/CLI避免了P/Invoke每次调用时的数据封送开销。
• 封装遗留C++类库的理想选择：如果你有一个庞大的、基于类的C++遗产代码库，用C++/CLI写一层薄薄的包装层，暴露给C#使用，是最优雅的方式。

一个简单的C++/CLI包装器示例：

// NativeClass.h - 纯原生C++类 #pragma once class NativeCalculator { public: NativeCalculator(); double Add(double a, double b); double* ProcessArray(const double* input, int length); private: double someInternalState_; }; // ManagedWrapper.h - C++/CLI包装类 #pragma once #include "NativeClass.h" namespace MyMixedLib { public ref class ManagedCalculator // ref class 表示托管类 { public: ManagedCalculator(); ~ManagedCalculator(); // 析构函数 (Dispose模式) !ManagedCalculator(); // 终结器 (Finalizer) double Add(double a, double b); array<double>^ ProcessArray(array<double>^ input); // 使用托管数组 private: NativeCalculator* nativeInstance; // 持有原生C++对象指针 }; } // ManagedWrapper.cpp #include "ManagedWrapper.h" namespace MyMixedLib { ManagedCalculator::ManagedCalculator() { nativeInstance = new NativeCalculator(); } ManagedCalculator::~ManagedCalculator() { this->!ManagedCalculator(); } ManagedCalculator::!ManagedCalculator() { delete nativeInstance; nativeInstance = nullptr; } double ManagedCalculator::Add(double a, double b) { // 直接调用原生方法，毫无开销 return nativeInstance->Add(a, b); } array<double>^ ManagedCalculator::ProcessArray(array<double>^ input) { pin_ptr<double> pinnedInput = &input[0]; // 关键：固定托管数组，防止GC移动 double* nativeInput = pinnedInput; double* nativeOutput = nativeInstance->ProcessArray(nativeInput, input->Length); // 将结果拷贝回新的托管数组 array<double>^ result = gcnew array<double>(input->Length); Marshal::Copy(IntPtr(nativeOutput), result, 0, input->Length); // 假设原生方法内部用new分配了内存，我们需要释放它 delete[] nativeOutput; return result; } }

然后在C#项目中，直接引用编译出的MyMixedLib.dll，就可以像使用普通.NET类一样使用ManagedCalculator。

实操心得与巨坑预警：

1. 内存管理是核心：C++/CLI混合了托管堆和原生堆。包装类里的原生指针（如NativeCalculator*）必须手动管理生命周期。标准的做法是实现IDisposable模式（即析构函数和终结器），确保原生资源能被及时释放，避免内存泄漏。
2. “固定”（Pinning）操作：当需要将托管对象（如数组）的指针传递给原生代码时，必须使用pin_ptr。这告诉垃圾回收器（GC）：“别动这块内存，我有用”。操作完成后，pin_ptr离开作用域会自动解除固定。切记，固定时间要尽可能短，长时间固定大块内存会严重阻碍GC，导致程序性能下降甚至卡顿。
3. 部署复杂性：C++/CLI项目编译出的DLL，依赖于特定版本的VC++运行时和.NET框架。在目标机器部署时，必须确保这些依赖项都已安装，比纯P/Invoke方案要复杂一些。

2.3 COM Interop：稳定但古老的“协议”

COM（Component Object Model）是微软上古时期提出的二进制组件标准。很多工业硬件（如某些品牌的PLC通信库、数据采集卡驱动）至今仍只提供COM接口。.NET通过COM Interop技术与之交互。

为什么（被迫）选择COM Interop？

• 别无选择：当第三方供应商只提供了COM组件（.tlb类型库或.dll）时。
• 二进制兼容性：COM的ABI（应用二进制接口）是稳定的，不同编译器、不同年代生成的COM组件可以互操作。

在Visual Studio中，你只需要添加对COM组件的引用，IDE会自动生成一个“互操作程序集”（Interop Assembly），里面包含了所有接口和类的托管包装。之后你就可以像使用.NET对象一样使用它们。

实操心得与巨坑预警：

1. 引用计数与释放：COM对象使用引用计数。在C#中，虽然运行时库（CLR）会通过RCW（Runtime Callable Wrapper）帮你管理，但如果你频繁创建大量COM对象，或者涉及循环引用，仍需小心。对于明确需要立即释放的资源（如打开的文件句柄），可以调用Marshal.ReleaseComObject(object)来强制减少引用计数。

   var plc = new PLCComLib.PLCClass(); try { plc.Connect(); // ... 操作 } finally { // 确保COM对象被释放，特别是长时间运行的服务程序 System.Runtime.InteropServices.Marshal.ReleaseComObject(plc); }

2. 线程公寓（Thread Apartment）：COM有STA（单线程单元）和MTA（多线程单元）的区分。很多老的、带UI的COM控件是STA的。在C#中，如果你的程序入口（Main方法）标记了[STAThread]，那么主线程就是STA线程，可以安全调用这些COM组件。但如果你在后台线程（默认为MTA）中调用STA组件，就会报错。这时可能需要使用Control.Invoke（WinForms）或Dispatcher.Invoke（WPF）将调用封送到UI线程，或者使用Thread.SetApartmentState()设置线程单元状态，非常麻烦。
3. 性能开销：COM Interop的调用开销比P/Invoke和C++/CLI都要大。对于高性能、高频调用的场景，这可能是瓶颈。

方案选型速查表：

3. 工业软件场景下的深度优化与实战技巧

选好了交互方案，只是万里长征第一步。在真实的工业环境中，稳定性、实时性和资源管理的要求，会把实验室里跑通的小demo逼到墙角。下面分享几个关键场景下的深度技巧。

3.1 高频数据交换：如何绕过GC实现“零拷贝”？

工业软件经常需要处理来自数据采集卡、传感器网络的实时数据流，可能是每秒数万甚至数百万个采样点。如果每个数据点都通过P/Invoke封送一次，或者用C++/CLI在托管数组和原生数组间来回拷贝，性能瓶颈立现。

解决方案：使用非托管内存和Span<T>/Memory<T>。

核心思想是，在非托管堆（C++侧）分配一块固定的、大的内存缓冲区，用于存放实时数据。C#端通过System.Runtime.InteropServices.MemoryMappedFile（内存映射文件）或直接通过指针访问这块内存，实现“零拷贝”共享。

步骤详解：

1. C++侧创建共享内存：

   // 创建一个共享内存区域 #include <windows.h> #include <iostream> class SharedDataBuffer { public: SharedDataBuffer(const char* name, size_t size) { hMapFile = CreateFileMappingA( INVALID_HANDLE_VALUE, // 使用物理内存 NULL, // 默认安全属性 PAGE_READWRITE, // 可读可写 0, // 高32位文件大小 (DWORD)size, // 低32位文件大小 name); // 共享内存名称 if (hMapFile == NULL) { throw std::runtime_error("Could not create file mapping object."); } pBuffer = (double*)MapViewOfFile( hMapFile, // 映射对象句柄 FILE_MAP_ALL_ACCESS, // 可读可写 0, 0, size); if (pBuffer == NULL) { CloseHandle(hMapFile); throw std::runtime_error("Could not map view of file."); } bufferSize = size / sizeof(double); } ~SharedDataBuffer() { if (pBuffer) UnmapViewOfFile(pBuffer); if (hMapFile) CloseHandle(hMapFile); } double* GetBuffer() { return pBuffer; } size_t GetBufferSize() { return bufferSize; } private: HANDLE hMapFile; double* pBuffer; size_t bufferSize; }; // 导出C接口供P/Invoke调用 extern "C" __declspec(dllexport) SharedDataBuffer* CreateBuffer(const char* name, int dataCount) { return new SharedDataBuffer(name, dataCount * sizeof(double)); } extern "C" __declspec(dllexport) void DestroyBuffer(SharedDataBuffer* buffer) { delete buffer; }

2. C#侧通过MemoryMappedFile访问：

   using System; using System.IO.MemoryMappedFiles; using System.Runtime.InteropServices; public unsafe class HighSpeedDataReader { private MemoryMappedFile mmf; private MemoryMappedViewAccessor accessor; private byte* pointer; private int dataCount; public HighSpeedDataReader(string mapName, int dataCount) { this.dataCount = dataCount; // 打开已存在的内存映射文件（由C++进程创建） mmf = MemoryMappedFile.OpenExisting(mapName); accessor = mmf.CreateViewAccessor(); accessor.SafeMemoryMappedViewHandle.AcquirePointer(ref pointer); } public Span<double> GetDataSpan() { // 关键：将非托管内存指针转换为Span<double>，实现零拷贝访问 var span = new Span<double>(pointer, dataCount); return span; } public void Dispose() { if (accessor != null) { accessor.SafeMemoryMappedViewHandle.ReleasePointer(); accessor.Dispose(); } mmf?.Dispose(); } // 使用示例 public void ProcessData() { Span<double> data = GetDataSpan(); // 直接对data进行操作，没有任何拷贝开销！ double sum = 0; for (int i = 0; i < data.Length; i++) { sum += data[i]; } // 甚至可以调用接受Span的现代API，如 System.Numerics.TensorPrimitives } }

注意：使用unsafe代码和指针需要项目启用“允许不安全代码”。Span<T>在.NET Core/.NET 5+中才能提供对非托管内存的安全、高性能访问。在工业场景，这能极大提升实时数据处理的吞吐量。

3.2 回调函数（Callback）与事件传递：如何让C++主动通知C#？

很多硬件驱动或算法库采用异步模式：C#发起一个操作，C++在后台执行，完成后通过回调函数通知C#。这就需要将C#的函数指针（委托）传递给C++。

步骤与关键点：

1. 在C#中定义与C回调函数签名匹配的委托。注意调用约定必须一致（通常是Cdecl）。

   // 假设C++回调函数签名：void (*DataReadyCallback)(const double* data, int length); [UnmanagedFunctionPointer(CallingConvention.Cdecl)] // 必须指定！ public delegate void DataReadyCallback(IntPtr data, int length);

2. 将委托实例传递给C++函数。委托本身是一个托管对象，需要将其转换为函数指针，并保持其不被GC回收。

   public class DataAcquisition { // 声明外部函数，接受一个回调函数指针 [DllImport("DataAcq.dll", CallingConvention = CallingConvention.Cdecl)] public static extern void start_acquisition(DataReadyCallback callback); // 必须将委托保存为类成员变量！防止被GC回收。 private DataReadyCallback _callbackInstance; public void Start() { _callbackInstance = new DataReadyCallback(OnDataReady); start_acquisition(_callbackInstance); } // 回调函数的具体实现 private void OnDataReady(IntPtr dataPtr, int length) { // 将IntPtr转换为可读的数据 double[] data = new double[length]; Marshal.Copy(dataPtr, data, 0, length); // 处理数据，注意：此方法在非托管线程调用，不能直接更新UI！ ProcessData(data); } private void ProcessData(double[] data) { // 数据处理逻辑 // 如果需要更新UI，必须封送到UI线程 // Application.Current.Dispatcher.Invoke(() => { ... }); } }

巨坑预警：

• 线程安全：C++端的回调通常发生在它自己的线程（非托管线程）上。在OnDataReady方法中，绝对不能直接访问或修改UI控件，否则会导致跨线程访问异常。必须使用Dispatcher.Invoke或Control.Invoke将操作封送到UI线程。
• 委托生命周期：必须将委托实例（_callbackInstance）保存在一个不会被GC回收的长期存活的对象中（如类的成员变量）。如果委托被GC回收了，C++端持有的函数指针就成了“野指针”，调用时必然导致崩溃。
• 在回调中避免耗时操作：回调函数应尽快返回，以免阻塞C++端的执行线程。如果需要复杂处理，应该将数据快速拷贝到托管内存（如Queue），然后由另一个托管工作线程去处理。

3.3 结构化数据传递：从简单结构体到复杂类层次

传递单个整数或字符串很简单，但工业软件中经常需要传递复杂的配置参数、状态信息等。这需要精心设计双方都能理解的数据结构。

对于简单结构体，使用P/Invoke和[StructLayout]特性即可，如前所述，关键是保证内存布局一致。

对于复杂的、嵌套的或动态的数据结构，P/Invoke就力不从心了。这时有两种主流策略：

1. 序列化/反序列化：将C#端的复杂对象序列化为字节流（如使用JSON、MessagePack或Protobuf），将字节流指针和长度传递给C++端，C++端用对应的库解析。这种方式松耦合，但每次调用都有序列化开销。

   // C#端 var config = new DeviceConfig { Id = 1, Name = "Motor", Params = new List<double> { 1.0, 2.0 } }; byte[] bytes = MessagePackSerializer.Serialize(config); IntPtr unmanagedPtr = Marshal.AllocHGlobal(bytes.Length); Marshal.Copy(bytes, 0, unmanagedPtr, bytes.Length); // 将 unmanagedPtr 和 bytes.Length 传给C++函数 // ... Marshal.FreeHGlobal(unmanagedPtr); // 别忘了释放！

2. 使用C++/CLI封装：这是更高效、更面向对象的方式。在C++/CLI层，为每一个需要暴露的复杂C++类，定义一个对应的托管包装类（ref class）。包装类内部持有原生对象的指针，并将公有方法、属性一一转发。这样在C#端，你就可以像操作普通.NET对象一样操作这些“伪”C++对象，享受完整的面向对象特性（继承、多态等），同时性能损失最小。

4. 调试、部署与维护的“血泪”经验

交互代码写完了，能跑通，这才是考验的开始。工业现场的环境远比开发机复杂。

4.1 混合模式调试：让崩溃有迹可循

最让人头疼的问题莫过于程序在非托管代码中崩溃，Visual Studio只给你一个AccessViolationException，没有任何C#堆栈信息。

必须启用混合模式调试：

1. 在Visual Studio中，右键点击你的C#启动项目 -> “属性”。
2. 选择“调试”选项卡。
3. 在“调试器类型”或“启用调试器”部分，勾选“启用本机代码调试”。 这样，当崩溃发生在C/C++ DLL中时，调试器会加载对应的符号文件（.pdb），你就能看到C/C++的调用堆栈，甚至能下断点到C++源码中（如果你有源码和pdb）。

生成有用的调试信息：

• 在编译C/C++ DLL时，务必生成调试符号（.pdb文件），并和DLL一起发布到调试目录。
• 在C/C++代码中，使用__FILE__和__LINE__宏记录日志，方便定位问题。

4.2 依赖管理与部署清单

“在我机器上好好的，怎么到客户那儿就运行不了？”——这是经典问题。

1. VC++运行时：如果你的C/C++ DLL是用Visual Studio编译的，并且不是静态链接运行时库（/MT），那么目标机器上必须安装对应版本的VC++ Redistributable。使用Dependency Walker或dumpbin /dependents YourDll.dll命令查看依赖。在安装包中捆绑对应的VC++运行时安装程序是标准操作。
2. DLL地狱：确保部署的是你编译时链接的完全相同版本的第三方依赖DLL。特别是像OpenCV、Boost这样的库，不同版本间接口可能不兼容。将所有依赖DLL放在你的程序目录下，并考虑修改PATH或使用SetDllDirectoryAPI来优先加载本地目录的DLL，避免加载系统目录下的旧版本。
3. 位数匹配：x86还是x64？这是必查项。你的C#项目平台目标（Any CPU, x86, x64）必须和你的C/C++ DLL编译的位数一致。一个64位进程无法加载32位DLL，反之亦然。在“解决方案配置管理器”中统一所有项目的平台为x86或x64。

4.3 内存泄漏排查：托管与非托管的“双线作战”

在混合编程中，内存泄漏可能发生在两边。

• 托管侧（C#）：主要关注大对象（如数组、图片）是否被及时释放，事件订阅是否取消，静态集合是否无限增长。可以使用.NET Memory Profiler、dotMemory等工具。
• 非托管侧（C/C++）：这是重灾区。每一个malloc/new都必须有对应的free/delete。在C++/CLI中，包装类的析构函数和终结器必须正确释放原生指针。在P/Invoke中，C端分配的内存，必须由C端提供的函数释放，或者用Marshal类中的特定方法（如Marshal.FreeCoTaskMem）释放，绝不能用C#的delete或不管不顾。

一个实用的技巧是，在C/C++代码的调试版本中，重载new和delete运算符，加入内存分配跟踪，记录分配的文件和行号。发布版本再关掉此功能。

4.4 性能分析与优化

当交互成为性能瓶颈时，你需要知道时间花在哪里了。

• 使用Stopwatch进行粗粒度测量：在C#调用前后计时，判断一次P/Invoke调用的开销。
• 使用性能剖析器：Visual Studio自带的性能剖析器（Performance Profiler）非常好用。选择“检测”模式，它可以同时分析托管代码和非托管代码的性能热点，清晰地展示出每次P/Invoke调用的开销、托管到非托管转换的成本。
• 优化策略：
  • 批处理：避免在循环中频繁进行P/Invoke单点调用。设计接口时，尽量让一次调用处理一批数据。
  • 减少封送：使用blittable类型（如int,double,byte，其在托管和非托管内存中具有相同的位表示）作为参数，可以避免封送开销。对于结构体，确保它只包含blittable类型。
  • 升级到C++/CLI：如果P/Invoke调用是热点，考虑将这部分频繁交互的代码用C++/CLI重写，消除封送边界。

5. 面向未来的考量：.NET Core/.NET 5+与跨平台

传统的工业软件大多基于.NET Framework和WinForms/WPF，绑定在Windows上。但现在，越来越多的场景要求跨平台（Linux工控机、嵌入式设备）或云端部署。.NET Core及其后继者.NET 5/6/7/8带来了新的可能和挑战。

好消息是：P/Invoke在.NET Core上得到了更好的支持，并且是跨平台的。你可以在Linux上通过P/Invoke调用.so动态库，在macOS上调用.dylib库，语法基本一致。

挑战在于：

1. C++/CLI的终结：.NET Core及以后版本不再支持C++/CLI。这是最大的技术断代。如果你的架构重度依赖C++/CLI，向.NET Core迁移将是一个巨大的挑战。
2. 替代方案：
   • 源生成器与函数指针：对于新的开发，可以考虑使用C# 9.0引入的函数指针和源生成器，配合UnmanagedCallersOnly特性，来更高效地与非托管代码交互，但这需要C端提供非常规整的C API。
   • SWIG或CppSharp：使用第三方工具（如SWIG、CppSharp）自动将C++库包装成C#可调用的P/Invoke接口或安全的托管包装。这适用于大型遗产库的迁移，但工具链本身需要学习和配置。
   • 将核心模块重构为独立服务：将C/C++核心模块编译为独立的可执行文件或服务（如gRPC服务），通过进程间通信（IPC）或网络（如TCP、gRPC）与C#主进程交互。这种方式解耦彻底，甚至可以用不同语言重写服务端，但引入了通信延迟和复杂性。

我的个人建议是：对于新项目，如果确定要跨平台，应尽量避免使用C++/CLI，优先设计清晰的C语言接口（extern "C"）供P/Invoke调用。对于已有的、基于C++/CLI的大型项目，迁移需要谨慎评估，或许维持.NET Framework框架在Windows上运行，同时为新的跨平台模块采用新的技术栈，是一种更务实的策略。

十年下来，我感觉C#与C/C++的交互就像一场精心编排的双人舞。C#负责展现优美的舞姿（UI/业务），C/C++负责提供稳定的托举和力量（核心算法/驱动）。舞跳得好不好，关键在于对两者边界的清晰划分，以及对连接处（数据转换、内存管理、异常处理）每一个细节的精准把控。这套技术没有过时，在可见的未来，只要工业领域对性能和确定性的追求不变，它就会一直活跃在关键岗位上。希望这些从实战中摔打出来的经验，能帮你少走些弯路，更稳健地搭建起属于你自己的工业软件大厦。