简介：面向需要在C++与C#之间搭建互操作桥接的开发者，这份工程实例以C++/CLI（CLR）作为中间层，系统演示了从C++原生类封装、托管包装类生成，到C#项目引用与调用的完整流程。资源包共包含117个文件，压缩包大小约17.53MB，文件类型涵盖C++/CLI中间层工程文件、C++源码、C#调用工程文件，以及编译生成的动态库、调试文件、可执行文件等，目录结构清晰，便于对照学习跨语言调用的代码组织。工程源码完整保留，可在本地直接编译运行，并借助调试文件进行断点跟踪。目前已有159人浏览学习。通过本实例，可以逐一掌握gcroot包装、托管类与非托管类映射、#pragma managed指令的用法，并重点理解异常处理、数据类型转换、编译平台配置等互操作中的易错环节。对于有一定C++或C#基础、希望实现两种语言混编的中高级开发者而言，这是一份可直接参考或套用的完整工程模板。 很多项目跑到最后都会撞上同一堵墙：核心算法和底层采集是用 C++ 写的，业务逻辑和界面却是 C# 的项目，两边必须互相调用。我第一次做这种混编需求时，也想偷懒用 C# 重写一遍 C++ 算法，结果被现实教育了——几万行老代码、各种第三方原生库、实时采集线程，哪是说重写就能重写的。后来老老实实走了一条微软官方早就铺好的路：用 C++/CLI（CLR）做中间层，把 C# 类库桥接给 C++ 调用。这条路我完整走过一遍，踩过的坑比坑还多，今天把整个工程实例拆开讲清楚，代码可以直接抄，配置可以直接用，重点是让后来的人少熬几个夜。
我要分享的是三层结构：C# 类库负责业务实现，C++/CLI 桥接 DLL 做翻译官，纯 C++ 程序负责调用。你不用把 C# 代码改成 C++，也不用搞 COM、更不用开进程间通信，所有类型转换都集中在桥接层完成，业务代码两边都不污染。这个方案适合谁？适合手里有存量 C++ 代码、又需要引入 C# 组件或 SDK 的开发者，也适合第一次接触混编、想在工程里验证 C++/CLI 可行性的朋友。
1. 为什么 C++ 和 C# 之间必须有一座桥
1.1 两种语言天生不在一个世界里
C++ 默认编译成原生机器码，自己管理内存，对象活在原生堆上；C# 编译成 IL，由 CLR 在托管堆上分配对象，内存由垃圾回收器统一管。这两套运行时各有各的规矩，直接互相调用对方的对象是不可能的——你甚至没法在 C++ 代码里写一个new 一个C#对象，因为编译器根本不知道 CLR 的存在。
有人会问：那 C# 不也提供了 P/Invoke，可以直接调 C++ 的 DLL 吗？没错，C# 调 C++ 可以用 DllImport，但那解决的是“C++ 函数暴露成 C 接口”的问题。反过来，C++ 要调 C# 的类、事件、泛型、异步方法，P/Invoke 完全使不上劲，因为 C# 那头没有一个对应的 C 接口可以给你导入。COM 也能互通，但你得给 C# 类写 COM 注册、处理 GUID、接口定义，维护成本非常高，一个项目里 COM 和 CLR 混在一起调试，那酸爽谁试谁知道。
说到底就是两个运行时之间缺一个翻译层。微软给这个翻译层起了个很直白的名字：C++/CLI，也常写成 C++/CLR。它原本叫 Managed C++，是 C++ 在微软平台上的一种方言，编译出来的程序集既包含原生代码，又包含托管代码，可以在同一个 DLL 里同时操作原生对象和托管对象。
1.2 桥接层到底解决了什么问题
C++/CLI 最大的价值就是它允许你在一个源文件里同时写两套语法：用^声明托管句柄，用*声明原生指针；用gcnew创建托管对象，用new创建原生对象；托管类用ref class声明，原生类用class声明。两边对象的转换、方法的调用、事件和回调的转发，全都由这层代码完成。
这其实就是设计模式里的桥接模式思想：C++ 是抽象，C# 是实现，桥接层把变化隔离开。业务逻辑如果变了，只改 C# 类库；调用方式变了，只改 C++ 侧调用代码。桥接层只做翻译，不写业务。我在实际项目里踩过一个反面教材：图省事把一些计算逻辑直接写在桥接层，后来要复用 C# 计算结果，桥接层反而成了逻辑黑洞，改一处要重新编三个项目。桥接层薄，系统才好维护。
2. 工程搭建：VS 解决方案与项目结构
2.1 三层结构怎么划分
这一节直接给出工程骨架。在 Visual Studio 里建一个解决方案，里面放三个项目：
| 项目 | 语言 | 输出类型 | 作用 |
|---|---|---|---|
| CsLibrary | C# | 类库 | 业务实现、算法封装、事件定义 |
| BridgeLibrary | C++/CLI | DLL | 引用 C# 类库，把托管类型包装成原生类供 C++ 调用 |
| NativeApp | C++ | 控制台/桌面程序 | 原生 C++ 入口，调用桥接层导出的原生类 |
为什么要单独建一个 BridgeLibrary 而不是在 NativeApp 里直接开/clr？因为纯 C++ 项目里一旦开启/clr编译，整个项目的代码都要受 CLR 约束，很多第三方 C++ 库根本没法用/clr编译，会产生一堆链接错误。更难受的是，你项目里所有的原生代码都会被扯进托管生态，哪天想剥离出来就晚了。桥接层独立成 DLL 之后，原生程序只需要链接一个普通导入库，程序本身不开/clr，对原有 C++ 工程几乎是零侵入。
2.2 关键配置：/clr 与平台一致性
BridgeLibrary 项目属性里必须设置“公共语言运行时支持”为“公共语言运行时支持 (/clr)”。这个选项在“配置属性 -> 常规”下面。要注意的是，C++/CLI 项目和 C# 类库有一个不太直观的坑：平台目标必须一致。
C# 项目默认是 AnyCPU，在 64 位操作系统上跑的时候，JIT 会把它编译成 64 位；而 C++/CLI 的 DLL 是混合程序集，平台必须明确指定。如果 C++/CLI 桥接层选 x64，C# 那边还是 AnyCPU，运行时经常会出现“试图加载格式不正确的程序”这个经典错误。我的做法是：解决方案里所有项目，包括 C# 和桥接层，平台都统一设成 x64 或 x86，绝不在一个混合方案里混用。如果你建的 C# 项目只有 AnyCPU，可以打开“配置管理器”，手动添加 x64 平台。
还有 Visual Studio 的 C++ 工程默认开启/RTC1（运行时错误检查），这个选项和/clr是不兼容的。遇到编译错误 C4793 或链接报错，去“配置属性 -> C/C++ -> 代码生成 -> 基本运行时检查”把它设成“默认值”即可。我当时第一次编译 BridgeLibrary，被这个选项折腾了大半天，后来凡是建 C++/CLI 项目，第一步就关掉它。
CMake 用户也可以配，本质就是加/clr编译选项，比如target_compile_options(BridgeLibrary PRIVATE "/clr")。但我个人建议混编工程直接用 VS 解决方案管理，因为 C++/CLI 项目涉及引用、部署、调试，VS 的可视化配置会省心很多。你要是平时用 vscode 写 C++，建议这个混合工程回到 VS 里编译调试，vscode 对 C++/CLI 的 IntelliSense 和调试支持非常弱。
3. 桥接层实现：从 C# 类到 C++ 类的完整过程
3.1 C# 端：一个带事件的计算器类
先用一个经典的计算器类做演示，这个类包含一个普通方法、一个返回字符串的方法、一个事件，基本覆盖了日常混编场景里的三种调用形态。
namespace CsLibrary { public delegate void ResultHandler(double value); public class Calculator { public event ResultHandler? OnResult; public double Add(double a, double b) { double result = a + b; OnResult?.Invoke(result); return result; } public string GetVersion() { return "1.0.0"; } } }为什么这个类要特意加一个事件？因为在真实项目里，C# 库往往会通过事件上报进度、扫码枪触发、心跳通知等异步消息，C++ 侧如果只能调方法不能收事件，那等于被砍了一条腿。事件转发是桥接层里最容易被轻视、也最容易写崩的环节，后面我会专门讲。
3.2 C++/CLI 桥接：用 gcroot 包住托管对象
桥接层是重头戏。这里的关键是：你最终想暴露给原生 C++ 的，是一个普普通通的 C++ 类，而不是托管类。因为原生 C++ 项目不开/clr，代码里不能出现^和gcnew。那桥接层怎么在内部保存托管对象？答案是gcroot<T>。
gcroot<T>是微软提供的一个模板类，它内部封装了一个GCHandle，让原生类可以安全地持有一个托管对象的引用。你可以把它理解成一根“锚链”，把托管对象钉在原生对象上，垃圾回收器不会随便回收它。演示代码如下。
头文件CalculatorBridge.h：
#pragma once #include <vcclr.h> #include <string> #ifdef BRIDGE_EXPORTS #define BRIDGE_API __declspec(dllexport) #else #define BRIDGE_API __declspec(dllimport) #endif class CalculatorBridge { public: CalculatorBridge(); ~CalculatorBridge(); double Add(double a, double b); std::string GetVersion(); private: gcroot<CsLibrary::Calculator^> _calc; };实现文件CalculatorBridge.cpp：
#include "CalculatorBridge.h" #using "CsLibrary.dll" CalculatorBridge::CalculatorBridge() { _calc = gcnew CsLibrary::Calculator(); } CalculatorBridge::~CalculatorBridge() { // gcroot 析构时会自动释放托管句柄，这里不需要手动 delete } double CalculatorBridge::Add(double a, double b) { return _calc->Add(a, b); } std::string CalculatorBridge::GetVersion() { System::String^ version = _calc->GetVersion(); return std::string( (const char*)System::Runtime::InteropServices::Marshal::StringToHGlobalAnsi(version).ToPointer() ); }这里有三个需要重点解释的细节。
第一，#using "CsLibrary.dll"是 C++/CLI 引用托管程序集的方式，相当于 C# 里的“添加引用”。在实现文件里写#using只是兜底，更规范的做法是在 VS 项目引用里添加对 CsLibrary 的引用，VS 会替你处理程序集路径。
第二，在 C++/CLI 项目里，你可以直接用CsLibrary::Calculator^这样的托管句柄，不用写gcnew的时候加命名空间限定。但要注意，gcroot模板的头文件是<vcclr.h>，很多刚入坑的人漏了这个头文件，编译报“gcroot 未定义”还一脸懵。
第三，字符串返回是必须处理的。C# 的string是 UTF-16 的托管字符串，C++ 的std::string是字节串，桥接层必须做编组转换。上面代码用了Marshal::StringToHGlobalAnsi转成 ANSI 字节串再拷贝到std::string，用完之后要记得Marshal::FreeHGlobal释放非托管内存，上面示例为了简洁没写，实际工程里必须补上，否则每次调用都泄漏一块非托管内存。
3.3 事件与回调怎么传到 C++
要让 C++ 侧收到 C# 事件，最合理的办法是把事件转成原生回调函数指针。C++/CLI 里可以用Marshal::GetFunctionPointerForDelegate把一个托管委托转成函数指针，转发给原生代码。但这里面有一个大坑：委托对象如果不保持引用，垃圾回收器会随时回收它，回收之后再调用函数指针，程序直接崩溃，而且崩溃现场非常诡异，往往是几百毫秒之后在完全不相干的地方崩掉。
所以桥接层的做法是：聚合一个托管委托，把它和原生回调绑定起来。
// 托管回调转发类 public delegate void NativeCallback(double value); public ref class CallbackWrapper { private: CsLibrary::ResultHandler^ _csHandler; NativeCallback^ _nativeCallback; public: CallbackWrapper(NativeCallback^ callback) { _nativeCallback = callback; _csHandler = gcnew CsLibrary::ResultHandler(this, &CallbackWrapper::FireEvent); } void FireEvent(double value) { _nativeCallback(value); } CsLibrary::ResultHandler^ GetHandler() { return _csHandler; } };然后在CalculatorBridge里持有一个gcroot<CallbackWrapper^>的成员，在构造函数里创建它，并把原生函数指针保存到原生成员变量里。这样委托链始终有引用，不会被 GC 回收，C++ 侧拿到的函数指针也永远是有效的。这个方法我强烈建议直接背下来，它是我在多个工程里验证过最稳的事件桥接方案。
4. 原生 C++ 侧接入与验证
4.1 在纯 C++ 程序里调用桥接类
桥接层完成后，原生 C++ 程序的使用方式非常简单，它看不到任何 C# 的影子，就是一个普通 C++ 类调用。注意 NativeApp 项目不需要开启/clr。
#include <iostream> #include "CalculatorBridge.h" int main() { CalculatorBridge bridge; double sum = bridge.Add(1.2, 3.4); std::cout << "sum = " << sum << std::endl; std::cout << "version = " << bridge.GetVersion() << std::endl; return 0; }在项目配置上，需要告诉 NativeApp 去哪找桥接 DLL 的头文件和导入库.lib。一个是“C/C++ -> 常规 -> 附加包含目录”，把 BridgeLibrary 的头文件目录加进去；另一个是“链接器 -> 常规 -> 附加库目录”和“链接器 -> 输入 -> 附加依赖项”，把 BridgeLibrary 的.lib加进去。运行时，把 BridgeLibrary.dll 和 CsLibrary.dll 复制到 NativeApp 的输出目录，我一般通过“生成事件 -> 后期生成事件”写一条copy命令搞定，省得手动丢文件。
这一步之所以顺畅，正是因为桥接层对外暴露的是原生导出类。如果你的桥接层走托管类暴露，原生项目就必须开/clr才能用，那前面说的低侵入优势就全没了。
4.2 验证要点：从编译到跑通
工程搭建完第一件事不是写业务，而是验证整条链路能不能通。我的验证顺序是这样的：
- 先编译 CsLibrary，确认 C# 类库能正常生成 DLL。
- 再编译 BridgeLibrary，确认
#using能找到 CsLibrary，确认编译没有/clr相关报错。 - 最后编译 NativeApp，确认链接器能找到导入库，运行起来没有“找不到 DLL”的弹窗。
- 运行程序，先测普通方法返回，再测事件回调有没有触发。
只要你第二步里的 BridgeLibrary 能编过，基本就成功了一大半。混编工程最怕的不是代码写不对，而是编译链断掉，所以一定要按这个顺序逐层排查。
4.3 调试技巧：两个调试器同时工作
调试这种混编工程有个非常实用的技巧：把 NativeApp 设为启动项目，然后在 VS 里同时打开 BridgeLibrary.cpp 和 CsLibrary.cs，分别在各层代码里打断点。只要项目属性里“调试 -> 调试器类型”设置为“混合”，VS 会同时启用原生调试器和托管调试器，C++、C++/CLI、C# 代码之间可以无缝断点跟踪。这个功能我第一次用的时候简直惊了，从 C++ 调用点一路步进到 C# 的 Add 方法里，再步进回来，整个调用链看得清清楚楚。排查混编问题，这个必须会用。
5. 实战中绕不开的坑
这一节把我在工程实践里踩过的典型问题整理成速查表，不一定覆盖所有情况，但每一条都是真实 debug 出来的。
| 常见问题 | 根本原因 | 解决方式 |
|---|---|---|
| 编译报 C4793 错误 | /clr与/RTC1不兼容 | 代码生成 -> 基本运行时检查设为默认值 |
| 运行时出现“试图加载格式不正确的程序” | C++/CLI 与 C# 平台目标不一致 | 所有项目统一 x64 或 x86 |
| 找不到 CsLibrary.dll | C# 程序集没有复制到桥接层输出目录 | 通过项目引用并设置“复制本地”，或后期生成事件 copy |
| 调用委托时程序随机崩溃 | 委托被垃圾回收器回收 | 用 GCHandle 或类成员持有委托引用 |
| std::string 中文乱码 | 托管字符串编组编码不对 | 用 StringToHGlobalUTF8 或显式指定编码 |
| 在非托管线程里访问托管对象 | 线程未附加到 CLR | 用System::Threading::Thread或手动附加运行时 |
有几个点要特别说明。
第一，关于字符串编组，我上面示例用StringToHGlobalAnsi只是为了演示简单。实际项目里如果涉及中文，推荐用StringToHGlobalUTF8，因为 UTF-8 在 C++ 侧处理字符串更通用，不容易踩本地代码页的坑。转换完记得用Marshal::FreeHGlobal释放，我习惯用一个 RAII 封装类自动管理，避免每处手动释放。
第二，关于非托管线程调用托管代码，这个坑最隐蔽。如果你在 C++ 侧自己开了一个std::thread，在回调里直接调桥接层方法，首次调用时 CLR 可能还没有在当前线程上初始化，程序会直接崩溃。解决办法是尽量所有线程都从托管侧启动，或者在线程入口处用System::Threading::Thread::CurrentThread触发 CLR 初始化。最稳妥的做法：所有桥接调用都发生在同一个主线程上，或者把任务通过队列投递到主线程执行，这样能规避一整套线程附加问题。
第三，不要在桥接层写业务逻辑。这算是我个人最有体会的一条经验。桥接层最有价值的形态是“薄”，只做类型转换和调用转发。一旦你开始把算法判断、日志拼接、数据缓存写进桥接层，后面 C# 侧改了逻辑，你得重新编译两个项目，而且 C++/CLI 代码的调试体验永远比不上纯 C# 或纯 C++，自己坑自己。我后来新项目的桥接层代码量压缩到全部工程代码的 15% 以内，每个方法基本就是“取参数 -> 调 C# -> 转类型 -> 返回”四行，非常舒服。
C++/CLI 这条桥虽然在微软的官方推荐列表里有点“冷门”，但在 Windows 平台混编方案里，它能做到的事情其他方案很难取代。你在 Native C++ 的项目里加一个桥接 DLL，就像给两个不同语言的团队配了一个专职翻译，两边各干各的，翻译管好翻译，这才是干净的架构。我个人现在做这类需求，已经形成固定路径了，C# 只写实现，C++ 只写场景，桥接层只写转换，十年内这套思路我觉得都不过时。
本文还有配套的精品资源，点击获取
