简介面向需要在 .NET 环境中使用 OpenDDS 的 C# 开发者这份 1.0 版封装资料围绕发布/订阅通信展开覆盖主题、发布者、订阅者等核心对象在 C# 中的类封装以及基于 UDP 的配置与 QoS 参数设置可帮助读者在实时数据分发项目中减少底层适配工作快速理解发布端与订阅端的组织方式。压缩包共 142 个文件约 12.89MB以 cs 源码、dll 类库、exe 示例及 config、ini 配置为主并含 pdb、cache 等编译辅助文件便于查看接口调用、运行示例和调整通信参数。已有 1085 人学习下载。资源包含封装库、订阅端与发布端工程等模块适合用来梳理 OpenDDS 在 C# 下的工程结构、依赖关系和数据收发流程也可作为搭建分布式实时通信原型的参考使用中可结合自身环境核对引用并按业务需求调整服务质量策略。1. 别人都在 C 里跑 DDSC# 上位机怎么接进去有个场景挺典型设备侧、中间件侧的同事早就把 OpenDDS 的发布订阅跑通了Topic 和 IDL 文件都定死了轮到你做上位机或者管理端技术栈是 .NET一打开工程就发现官方只给了 C、Java 的绑定C# 这边连个像样的门都摸不着。要么说服全组换技术栈要么自己搭一座桥。这份 OpenDDS 订阅发布 C# 封装 1.0 做的就是后面这件事把 OpenDDS 的 DomainParticipant、Topic、DataWriter、DataReader 这一套包成 C# 侧能直接 new 出来的对象让托管代码专注业务原生层的那堆句柄、QoS、监听器交给封装层消化。适合两类人手里已有 OpenDDS 总线、需要 C# 端接入的以及想搞清楚 P/Invoke 跨原生 DDS 这条链路怎么走通的。2. 架构拆解原生 DDS 内核和托管层之间的三层拼装2.1 为什么纯托管实现绕不开原生层OpenDDS 的核心是 C 实现的 DDS 规范落地从DomainParticipantFactory到DataWriterImpl整条链路上全是模板、引用计数和 TAO 的 CORBA 基础设施。它不像某些轻量协议那样有纯 C 的 ABI 可以随便绑IDL 编译器tao_idl和opendds_idl生成的是 C 类层次里面还有TAO_SYNCH_MUTEX、CORBA::String_var这些 C 特有的东西。想在 C# 里重新实现一遍 DDS等于把整个规范重写不现实。所以常见的做法只有两条路。一条是 C/CLI 混合模式程序集把 C 对象直接包进ref class语法上最自然但混合模式程序集对目标框架有要求.NET Core / .NET 5 之后的 64 位环境下编译和加载都比较别扭nuget 打包也难受。另一条就是这份封装走的路在 C 侧写一层extern C的导出函数只暴露裸指针和不透明句柄C# 侧用DllImport做 P/Invoke。这条路多写一点胶水代码但边界极窄只有void*、int、char*和回调函数指针四种东西在跨语言传递出问题的时候好定位也不挑运行时版本。提示如果你的团队只在 Windows 上跑、框架锁死 .NET Framework 4.xC/CLI 也不是不能选一旦要跨平台或者上 .NET 8老老实实走 C 导出层。2.2 三层结构IDL 类型层、C 桥接层、托管 API 层整个封装我习惯按三层来理解从下往上说。最底下是IDL 类型层也就是项目里那个idl/目录。DDS 是强类型的发布订阅双方必须对同一个 Topic 的样本结构有完全一致的理解这个理解就写在.idl文件里。比如一个传感器读数// idl/Sensor.idl module Demo { struct SensorReading { long id; // 设备编号同时作为 key double value; // 采样值 string64 tag; // 变长字符串上限 64 字节 }; #pragma DCPS_DATA_TYPE Demo::SensorReading #pragma DCPS_DATA_KEY Demo::SensorReading id };DCPS_DATA_TYPE告诉编译器这个结构是一个 DDS 可发布类型DCPS_DATA_KEY指定 key 字段——key 决定了实例instance的划分同一个 key 的样本在 DDS 里属于同一个实例历史策略、生命周期都按实例算。这个 key 的定义一旦上线就不好改了两边不一致会导致订阅端把同类数据当成不同实例行为会很怪。中间是C 桥接层一个纯 C 的 DLL内部持有DomainParticipant、Publisher、DataWriter这些对象对外只吐出不透明句柄和几个函数。它负责所有和 DDS 有关的脏活QoS 设置、TypeSupport 注册、样本的内存管理、监听器回调的线程切换。最上面是托管 API 层一个 C# 类库把句柄包成DdsParticipant、DdsPublisher、DdsSubscriber这样的类实现IDisposable用SafeHandle兜住资源释放。业务代码只写publisher.Publish(new SensorReading{...})这样一行不用知道下面是 DDS 还是别的消息中间件。2.3 线程模型DDS 内部线程如何把数据送进 C# 回调这一块是踩坑最集中的地方得单独说。OpenDDS 的DataReaderListener::on_data_available不是在你自己创建的线程上执行的而是由 DDS 内部的接收线程池回调。OpenDDS 默认会起若干接收线程具体数量受[DomainParticipant]配置里的线程池参数影响数据到达后在接收线程里完成反序列化然后同步调用 listener。这意味着跨语言回调发生时栈上同时压着 C 的接收线程帧和 C# 的托管帧。C# 侧注册的委托如果在某一刻被 GC 回收了原生侧再调这个函数指针就是野指针表现为进程直接退出、没有托管异常、也没有 dump非常难查。封装的 1.0 版本在订阅端专门维护了一个静态的委托字典把回调委托强引用住配合GCHandle.Alloc固定住 userData才算把这个问题按住。另一个约束是回调线程是 DDS 的公共资源多个 DataReader 可能共用同一条接收线程在回调里做阻塞操作读数据库、发 HTTP、弹窗会拖慢甚至堵死其它 Topic 的接收。稳妥的写法是回调里只做一次内存拷贝把数据丢进BlockingCollection或者ChannelT业务逻辑放到独立线程消费。3. 目录与构建链这套封装是怎么从 IDL 一路编到 DLL 的3.1 源码目录逐层看解压之后目录大致是这样每个位置的作用都比较明确opendds-csharp-1.0/ ├── idl/ # DDS 类型定义发布订阅双方共享 │ └── Sensor.idl ├── native/ # C 桥接层 │ ├── include/ │ │ ├── bridge_api.h # extern C 导出声明C# 侧对照它写 DllImport │ │ └── bridge_types.h │ ├── src/ │ │ ├── participant.cpp # Participant / Topic 的创建与销毁 │ │ ├── writer.cpp # DataWriter 封装与 write 调用 │ │ ├── reader.cpp # DataReader 封装与监听器 │ │ └── dds_config.cpp # ini 解析、QoS 默认值 │ ├── generated/ # IDL 编译产物构建时生成不入库 │ └── bridge.mpc # MPC 工程文件 ├── managed/ # C# 托管层 │ ├── OpenDdsSharp/ │ │ ├── NativeMethods.cs # 所有 DllImport 集中在这一个文件 │ │ ├── DdsParticipant.cs │ │ ├── DdsDataWriter.cs │ │ ├── DdsDataReader.cs │ │ ├── QosProfile.cs │ │ └── SafeHandles.cs │ └── OpenDdsSharp.sln ├── samples/ # 一个发布端 Demo、一个订阅端 Demo └── config/ └── rtps.ini # 运行期发现配置generated/目录是构建时产物不要提交到版本库。NativeMethods.cs用一个文件集中放所有DllImport原因是 P/Invoke 签名写错时比如CallingConvention不一致、参数类型宽度不对往往表现为栈不平衡或者返回值变成垃圾值集中管理便于对照bridge_api.h逐行核对。3.2 三步构建静态库、桥接 DLL、托管程序集构建顺序是死的跳步一定失败。第一步用opendds_idl和tao_idl处理Sensor.idl生成 TypeSupport 相关的 C 代码。手工执行的命令大致是这样# 1. 先跑 tao_idl生成结构体本身的 C 映射 tao_idl -I$DDS_ROOT -Ssi -o native/generated idl/Sensor.idl # 2. 跑 opendds_idl生成 TypeSupport 接口定义 opendds_idl -I$DDS_ROOT -o native/generated idl/Sensor.idl # 3. 再对生成的 SensorTypeSupport.idl 跑一遍得到 TypeSupport 的 C 实现 tao_idl -I$DDS_ROOT -Ssi -o native/generated native/generated/SensorTypeSupport.idl opendds_idl -I$DDS_ROOT -o native/generated native/generated/SensorTypeSupport.idl第一条命令生成SensorC.cpp/h里面是Demo::SensorReading这个 C 结构体和它的序列化操作符。第二条生成SensorTypeSupport.idl描述类型支持接口。第三、四条把类型支持接口也编译成 C 代码。少跑任何一步链接阶段都会报TypeSupportImpl未定义。第二步编译 C 桥接层。原项目用的是 MPC 构建mwc.pl -type vs2019生成解决方案也可以用 CMake 自己重写。链接时要带上OpenDDS_Dcps.lib、TAO.lib、TAO_PortableServer.lib还有OpenDDS_Rtps.lib走 RTPS 发现的话。注意运行时库要统一——/MD和/MT混用会导致跨 DLL 传std::string或ACE_String时堆不一致直接崩在析构里。第三步编译 C# 类库。托管层只依赖opendds_bridge.dll编译期完全不需要 OpenDDS 的头文件这是分层带来的直接好处C# 开发者机器上不装 OpenDDS 也能编译。3.3 运行期配置发现方式决定能不能互相看见DDS 最玄学的地方在于代码全对、日志全绿就是收不到数据八成是发现discovery没配上。OpenDDS 提供两种方式。集中式用DCPSInfoRepo需要单独起一个进程当目录服务所有 Participant 连到它上面注册。启动命令形如# 单独一个终端跑目录服务 DCPSInfoRepo -o repo.ior -DCPSDebugLevel 2 # 发布端和订阅端都要指定同一个 ior ./publisher -DCPSInfoRepo file://repo.ior分布式走 RTPS不需要中心节点靠组播或配置好的对端列表互相发现适合跨网段或者不想多维护一个进程的场景。配置文件长这样# config/rtps.ini [domain/42] DiscoveryConfigrtps_discovery ParticipantIndex0 MaxAutoParticipantIndex10 [rtps_discovery/rtps_discovery] SedpMulticast0 SpdpMulticast0 # 组播不通时直接写死对端省掉排查时间 SpdpPeers192.168.1.10:7400,192.168.1.11:7400SedpMulticast0和SpdpMulticast0关掉组播改用点对点。这个配置我一般会提前写好因为很多现场网络禁组播开着组播发现会一直静默失败日志里什么都看不到纯靠猜。ParticipantIndex在同一台机器上跑多个进程时必须各不相同否则 RTPS 的端口会撞。C# 侧不用关心这些细节封装把配置文件名透传下去就行var participant DdsParticipant.Create( domainId: 42, configFile: Path.Combine(AppContext.BaseDirectory, config, rtps.ini));domainId对应 ini 里的[domain/42]段两边不对应的话配置不会生效但也不会报错只是默默用了默认值。这个设计算不上友好排查时先确认 domain 号对得上。4. 核心链路拆解一条消息从 Publish 到 OnDataAvailable4.1 托管层的发布接口长什么样先看业务代码最终的样子再往里剥// samples/PublisherDemo/Program.cs using var participant DdsParticipant.Create(domainId: 42, configFile: config/rtps.ini); using var writer participant.CreateWriterSensorReading( topicName: SensorTopic, qos: QosProfile.Reliable); for (int i 0; i 100; i) { writer.Write(new SensorReading { Id 1001, Value 23.5 i * 0.1, Tag ch-01 }); Thread.Sleep(100); }CreateWriterT是泛型方法T必须带一个IDdsType约束由代码生成或者手写的 partial 类实现里面提供TypeName和序列化逻辑。这样做的好处是类型安全写错字段编译期就能发现而不是等到运行期订阅端解析失败。QosProfile.Reliable是个静态预设内部打包了一组 QoS 策略下面 4.5 节会展开。Write方法内部做三件事把托管对象序列化成字节数组、调原生dds_publish、检查返回码。返回码非零时抛DdsException带原生错误码和描述。4.2 P/Invoke 边界句柄、缓冲区和回调NativeMethods.cs是整个托管层的基石签名必须和bridge_api.h一模一样// managed/OpenDdsSharp/NativeMethods.cs internal static class NativeMethods { private const string Dll opendds_bridge.dll; // 回调签名topic 名、数据指针、长度、用户上下文 [UnmanagedFunctionPointer(CallingConvention.StdCall, CharSet CharSet.Ansi)] internal delegate void DataArrivedCallback( IntPtr topicName, IntPtr data, int length, IntPtr userData); [DllImport(Dll, CallingConvention CallingConvention.Cdecl)] internal static extern IntPtr dds_create_participant( int domainId, string configFile); [DllImport(Dll, CallingConvention CallingConvention.Cdecl)] internal static extern IntPtr dds_create_writer( IntPtr participant, string topicName, string typeName); [DllImport(Dll, CallingConvention CallingConvention.Cdecl)] internal static extern int dds_publish( IntPtr writer, byte[] buffer, int length); [DllImport(Dll, CallingConvention CallingConvention.Cdecl)] internal static extern IntPtr dds_create_reader( IntPtr participant, string topicName, string typeName, DataArrivedCallback callback, IntPtr userData); [DllImport(Dll, CallingConvention CallingConvention.Cdecl)] internal static extern void dds_destroy(IntPtr handle); }几个参数值得说清楚。CallingConvention.Cdecl必须和 C 侧的extern C默认调用约定一致写成StdCall在 x64 下恰好不报错x64 只有一种约定一到 x86 就栈失衡弹「运行时已损坏」的框。回调委托上标StdCall是因为 C 侧显式声明了__stdcall两边要对齐。dds_publish收byte[]封送时 CLR 会把托管数组钉住pin再传指针。这里有个隐含前提byte[]在封送期间不能被动过所以不要在多线程里共用同一个数组实例。我在封装里每次Write都新分配缓冲区虽然多一点 GC 压力但省掉了一类难查的错乱。userData用来在回调里区分是哪个 reader 触发的。常见做法是把GCHandle转成IntPtr传下去回调里再GCHandle.FromIntPtr取回托管对象。这个 handle 必须在 reader 销毁时Free漏了就是内存泄漏。4.3 订阅端监听器注册与数据回调订阅侧的托管封装核心是委托保活和异常隔离// managed/OpenDdsSharp/DdsDataReader.cs public sealed class DdsDataReaderT : IDisposable where T : IDdsType, new() { private readonly IntPtr _handle; private readonly GCHandle _selfHandle; // 关键委托必须被强引用住否则 GC 回收后原生回调就是野指针 private readonly NativeMethods.DataArrivedCallback _callback; public event EventHandlerT DataArrived; internal DdsDataReader(IntPtr participant, string topicName) { _selfHandle GCHandle.Alloc(this, GCHandleType.Normal); _callback OnNativeData; // 字段持有生命周期跟随 reader _handle NativeMethods.dds_create_reader( participant, topicName, new T().TypeName, _callback, GCHandle.ToIntPtr(_selfHandle)); } private void OnNativeData(IntPtr topic, IntPtr data, int len, IntPtr userData) { try { var self (DdsDataReaderT)GCHandle.FromIntPtr(userData).Target!; var bytes new byte[len]; Marshal.Copy(data, bytes, 0, len); var sample self.Deserialize(bytes); // 反序列化在回调线程里做 self.DataArrived?.Invoke(self, sample); } catch (Exception ex) { // 异常绝对不能穿透回原生栈否则进程直接没了 Trace.TraceError($[DDS] 回调异常: {ex}); } } public void Dispose() { NativeMethods.dds_destroy(_handle); _selfHandle.Free(); GC.SuppressFinalize(this); } }_callback声明成字段而不是局部变量是整个类里最重要的一行。早期版本写在构造函数里临时 new 一个委托传下去平时跑得好好的压测十几分钟后进程无声退出dump 一看栈在 DDS 接收线程上跳到了一个已释放的地址——就是委托被回收了。Marshal.Copy把原生缓冲区拷进托管数组这一步不能省。原生缓冲区的所有权在 C 侧回调返回后可能立刻被复用直接拿IntPtr用迟早读到脏数据。try/catch包住整个回调体也是硬性要求。托管异常跨 P/Invoke 边界传播是未定义行为.NET Framework 下直接让进程挂掉。这里统一 catch 住记日志代价是错误被吞了所以要配日志不然出问题连个线索都没有。Dispose的顺序也要注意先销毁原生句柄再释放GCHandle。反过来的话原生层还在回调托管对象已经没了一样是野指针。4.4 C 桥接层对应实现原生侧对应订阅创建和回调派发的部分大致如下// native/src/reader.cpp extern C BRIDGE_API void* dds_create_reader( void* participant, const char* topicName, const char* typeName, DataArrivedCallback cb, void* userData) { auto* dp static_castDDS::DomainParticipant*(participant); auto* ts TheTypeSupportRegistry::Find(typeName); // 按类型名找回 TypeSupport if (!ts) { SetLastError(ERR_TYPE_NOT_REGISTERED); return nullptr; } DDS::Topic* topic dp-create_topic( topicName, ts-get_type_name(), TOPIC_QOS_DEFAULT, nullptr, 0); if (!topic) { SetLastError(ERR_TOPIC_FAILED); return nullptr; } DDS::Subscriber* sub dp-create_subscriber(SUBSCRIBER_QOS_DEFAULT, nullptr, 0); // 监听器持有 cb 和 userDataon_data_available 里把样本序列化后回调出去 auto* listener new BridgeDataReaderListener(cb, userData); DDS::DataReader* dr sub-create_datareader( topic, DATAREADER_QOS_DEFAULT, listener, DDS::DATA_AVAILABLE_STATUS | DDS::SUBSCRIPTION_MATCHED_STATUS); return new ReaderContext{ dp, sub, topic, dr, listener }; }TheTypeSupportRegistry是桥接层里的一个静态注册表在 DLL 加载时把编译期生成的每种 TypeSupport 注册进去key 是类型名字符串。C# 传下来的typeName必须和 IDL 里DCPS_DATA_TYPE声明的完全一致包括Demo::前缀大小写敏感。错一个字符就是ERR_TYPE_NOT_REGISTERED而这个错误码在托管层表现为DdsException信息里会带上类型名排查的时候直接对比 IDL 就行。create_datareader最后一个参数指定了要监听的状态掩码。只监听DATA_AVAILABLE_STATUS的话订阅端和发布端匹配成功时不会有任何通知做联调时容易误以为没连上。加上SUBSCRIPTION_MATCHED_STATUSon_subscription_matched里打一条日志能立刻确认两端是否握手成功——这个日志我在每个项目里都会加上省下大量「到底连没连上」的猜测。4.5 QoS 在 C# 侧怎么映射QoS 是 DDS 里最容易配错又最难查的部分。封装把常用的几种组合预置成QosProfile静态属性同时留出属性让你单独改托管侧属性对应 DDS 策略可选值影响ReliabilityReliabilityQosPolicyBestEffort / Reliable丢包时是否重传DurabilityDurabilityQosPolicyVolatile / TransientLocal后启动的订阅端能否补到历史数据HistoryHistoryQosPolicyKeepLast(n) / KeepAll每实例缓存多少样本ResourceLimitResourceLimitsQosPolicyMaxSamples / MaxInstances缓存上限超了会阻塞或丢DeadlineDeadlineQosPolicyTimeSpan期望的更新周期超时触发回调配 QoS 有条铁律发布端和订阅端的 Reliability、Durability 必须兼容。订阅端要Reliable而发布端给BestEffortDDS 直接判定两边不匹配on_offered_incompatible_qos回调触发但数据一条都不通。这个回调在封装的 1.0 版本里只打日志很容易被忽略。Durability 也一样订阅端要TransientLocal而发布端是Volatile同样是静默不通。提示新接一个 Topic 时先把两端都设成BestEffort Volatile跑通再逐项往上加可靠性要求一次只改一项。全都要最强的配置反而是最容易不通的。5. 避坑与排查这套封装上线前必须过的几道坎5.1 现象发布端日志一切正常订阅端一条都收不到原因通常是发现没配上或者 domain 号不一致。OpenDDS 的发现过程是静默的Participant 创建成功不代表它发现了对端。集中式模式下DCPSInfoRepo没起、ior 文件路径不对、或者两端连的不是同一个 repo都会表现为「代码没错但就是不通」。RTPS 模式下如果网络禁组播默认配置会一直发现不了。解决分三步走先在订阅端加上SUBSCRIPTION_MATCHED_STATUS监听确认有没有匹配成功事件再用-DCPSDebugLevel 4起一次看发现阶段的日志里有没有对端的 Participant 信息最后确认两端的 domainId、配置文件路径、ParticipantIndex三样东西。我一般还会在同机器上先跑一遍自环发布订阅同进程自环不通说明是代码问题自环通了对端不通说明是网络或配置问题这样能把范围砍一半。5.2 现象程序运行十几分钟后无声退出没有异常也没有 dump原因基本可以锁定在回调委托被 GC 回收。C# 的委托对象只要没有强引用随时可能被回收而原生侧保存的函数指针不知道这件事。压测时触发 GC 的概率高所以表现是「跑一会儿就崩」。解决办法是把委托存成类的实例字段并且保证这个类的实例本身也被强引用通常在 reader 存活期间它自然活着。如果委托是动态创建的配合GCHandle.Alloc(del)固定住销毁时Free。检查方法在回调注册前后各打一条 GC 相关的日志配合GC.Collect()强制触发一次回收再发数据能复现就是这个问题。5.3 现象中文内容到对面变成乱码或者被截断原因有两层。第一层是编码string64里的 64 是字节数不是字符数一个中文字符 UTF-8 占 3 字节21 个汉字就满了超了会被截断。第二层是CharSet.Ansi的封送默认走系统 ANSI 代码页在非中文 locale 的机器上直接变问号。稳妥的做法是IDL 里长度按字节算留够余量C# 侧序列化统一用Encoding.UTF8显式转换不依赖默认封送P/Invoke 里所有字符串参数标注CharSet.Ansi并用[MarshalAs(UnmanagedType.LPUTF8Str)]指明 UTF-8。别指望CharSet.Auto它在不同平台行为不一样。5.4 现象在数据回调里直接调用发布接口整个进程卡死原因是死锁。回调运行在 DDS 的接收线程上而这个线程可能正持有 DDS 内部的锁在回调里同步调用write又去申请同一把锁自己等自己。表现是进程不崩但完全不动CPU 占用为 0用调试器挂上去看主线程和接收线程都停在等锁。解决方式是回调里绝不做任何 DDS 调用。把数据丢进ChannelT业务线程消费完再发布。封装的 1.0 版本没有做这层隔离得自己加。同类的坑还有在回调里Thread.Sleep、同步 IO、Dispatcher.Invoke到 UI 线程后者在 UI 线程忙的时候会阻塞接收线程。5.5 现象IDL 加了字段C# 侧收到的还是老结构原因是generated/目录没重新生成或者桥接 DLL 没有重新编译。IDL 编译产物是构建时生成的增量构建有时候认不出.idl变了直接跳过。表现是两端字段对不上反序列化出来的值错位但因为长度差异不大不会报错只是数据看着莫名其妙。解决是把generated/整个删掉强制全量重编构建脚本里加一条rm -rf的清理步骤。另外要保证发布端和订阅端用的是同一份 IDL 文件各自维护一份副本迟早会分叉。我一般把 idl 目录做成共享引用而不是复制粘贴。6. 二次开发把 1.0 封装改成业务能直接用的通信层拿到这套东西之后真正要改的地方通常不在 DDS 本身而在「怎么让它贴合你的业务模型」。1.0 版本给的是通用封装泛型参数T加IDdsType约束这种方式业务侧用起来还是得手写一堆结构体。我一般会先做两件事。第一件是把 Topic 定义收敛到一处。建一个Topics静态类把每个 Topic 名、类型、QoS 预设绑在一起业务代码只引用常量避免字符串散落各处// 业务侧统一入口改 Topic 名只改这一处 public static class Topics { public static readonly TopicDefSensorReading Sensor new(SensorTopic, QosProfile.ReliableWithHistory(10)); public static readonly TopicDefDeviceStatus Status new(StatusTopic, QosProfile.BestEffort); } // 使用 using var reader participant.CreateReader(Topics.Sensor); reader.DataArrived (_, sample) Console.WriteLine(${sample.Id} {sample.Value});QosProfile.ReliableWithHistory(10)是我在 1.0 基础上加的方法把「可靠传输 保留最近 10 条」这个常见组合封装成一个调用。业务侧配 QoS 的机会越少配错的概率越低。第二件是把序列化从「手写」换成「生成」。1.0 版里IDdsType的实现要手写序列化和反序列化字段一多容易出错。改造方向是用源生成器Source Generator读 IDL 的中间产物自动生成 partial 类和序列化代码业务侧只维护 IDL 一份真源。这一步改动量大但收益明显——IDL 加字段之后C# 侧重新编译就同步了不用再手工对齐。几个改造时的边界要守住。原生桥接层的 ABI 尽量别动加功能优先在托管层做因为 ABI 一改就得同步更新两边的构建产物很容易出现版本错配。回调线程的约束不能破任何新加的处理逻辑都要保证「回调里只拷贝处理放后台」。Dispose 的链路要顺着检查一遍每新增一个GCHandle或者原生句柄都要在对应的Dispose里配对释放。验证方式我习惯用三步同进程自环跑通排除网络和发现因素、跨进程同机跑通验证发现配置、跨机跑通验证网络和时钟。每步之间改动的只有环境一旦某步失败问题范围是明确的。血泪经验是版本号。这套封装 1.0 的托管层和桥接 DLL 之间有隐式契约——导出函数签名、错误码含义、类型名格式任何一项变了旧 DLL 配新 C# 就会以各种奇怪的方式失败包括但不限于访问冲突、返回垃圾值、静默不工作。从那以后我每次发版都强制走一遍「删干净 generated 目录 全量重编两边 三步验证」并且把桥接 DLL 的版本号写进dds_create_participant的返回值里做握手校验不匹配直接抛异常。多花十分钟省掉一整天的黑匣子排查。希望帮到你。本文还有配套的精品资源点击获取
简介面向需要在 .NET 环境中使用 OpenDDS 的 C# 开发者这份 1.0 版封装资料围绕发布/订阅通信展开覆盖主题、发布者、订阅者等核心对象在 C# 中的类封装以及基于 UDP 的配置与 QoS 参数设置可帮助读者在实时数据分发项目中减少底层适配工作快速理解发布端与订阅端的组织方式。压缩包共 142 个文件约 12.89MB以 cs 源码、dll 类库、exe 示例及 config、ini 配置为主并含 pdb、cache 等编译辅助文件便于查看接口调用、运行示例和调整通信参数。已有 1085 人学习下载。资源包含封装库、订阅端与发布端工程等模块适合用来梳理 OpenDDS 在 C# 下的工程结构、依赖关系和数据收发流程也可作为搭建分布式实时通信原型的参考使用中可结合自身环境核对引用并按业务需求调整服务质量策略。1. 别人都在 C 里跑 DDSC# 上位机怎么接进去有个场景挺典型设备侧、中间件侧的同事早就把 OpenDDS 的发布订阅跑通了Topic 和 IDL 文件都定死了轮到你做上位机或者管理端技术栈是 .NET一打开工程就发现官方只给了 C、Java 的绑定C# 这边连个像样的门都摸不着。要么说服全组换技术栈要么自己搭一座桥。这份 OpenDDS 订阅发布 C# 封装 1.0 做的就是后面这件事把 OpenDDS 的 DomainParticipant、Topic、DataWriter、DataReader 这一套包成 C# 侧能直接 new 出来的对象让托管代码专注业务原生层的那堆句柄、QoS、监听器交给封装层消化。适合两类人手里已有 OpenDDS 总线、需要 C# 端接入的以及想搞清楚 P/Invoke 跨原生 DDS 这条链路怎么走通的。2. 架构拆解原生 DDS 内核和托管层之间的三层拼装2.1 为什么纯托管实现绕不开原生层OpenDDS 的核心是 C 实现的 DDS 规范落地从DomainParticipantFactory到DataWriterImpl整条链路上全是模板、引用计数和 TAO 的 CORBA 基础设施。它不像某些轻量协议那样有纯 C 的 ABI 可以随便绑IDL 编译器tao_idl和opendds_idl生成的是 C 类层次里面还有TAO_SYNCH_MUTEX、CORBA::String_var这些 C 特有的东西。想在 C# 里重新实现一遍 DDS等于把整个规范重写不现实。所以常见的做法只有两条路。一条是 C/CLI 混合模式程序集把 C 对象直接包进ref class语法上最自然但混合模式程序集对目标框架有要求.NET Core / .NET 5 之后的 64 位环境下编译和加载都比较别扭nuget 打包也难受。另一条就是这份封装走的路在 C 侧写一层extern C的导出函数只暴露裸指针和不透明句柄C# 侧用DllImport做 P/Invoke。这条路多写一点胶水代码但边界极窄只有void*、int、char*和回调函数指针四种东西在跨语言传递出问题的时候好定位也不挑运行时版本。提示如果你的团队只在 Windows 上跑、框架锁死 .NET Framework 4.xC/CLI 也不是不能选一旦要跨平台或者上 .NET 8老老实实走 C 导出层。2.2 三层结构IDL 类型层、C 桥接层、托管 API 层整个封装我习惯按三层来理解从下往上说。最底下是IDL 类型层也就是项目里那个idl/目录。DDS 是强类型的发布订阅双方必须对同一个 Topic 的样本结构有完全一致的理解这个理解就写在.idl文件里。比如一个传感器读数// idl/Sensor.idl module Demo { struct SensorReading { long id; // 设备编号同时作为 key double value; // 采样值 string64 tag; // 变长字符串上限 64 字节 }; #pragma DCPS_DATA_TYPE Demo::SensorReading #pragma DCPS_DATA_KEY Demo::SensorReading id };DCPS_DATA_TYPE告诉编译器这个结构是一个 DDS 可发布类型DCPS_DATA_KEY指定 key 字段——key 决定了实例instance的划分同一个 key 的样本在 DDS 里属于同一个实例历史策略、生命周期都按实例算。这个 key 的定义一旦上线就不好改了两边不一致会导致订阅端把同类数据当成不同实例行为会很怪。中间是C 桥接层一个纯 C 的 DLL内部持有DomainParticipant、Publisher、DataWriter这些对象对外只吐出不透明句柄和几个函数。它负责所有和 DDS 有关的脏活QoS 设置、TypeSupport 注册、样本的内存管理、监听器回调的线程切换。最上面是托管 API 层一个 C# 类库把句柄包成DdsParticipant、DdsPublisher、DdsSubscriber这样的类实现IDisposable用SafeHandle兜住资源释放。业务代码只写publisher.Publish(new SensorReading{...})这样一行不用知道下面是 DDS 还是别的消息中间件。2.3 线程模型DDS 内部线程如何把数据送进 C# 回调这一块是踩坑最集中的地方得单独说。OpenDDS 的DataReaderListener::on_data_available不是在你自己创建的线程上执行的而是由 DDS 内部的接收线程池回调。OpenDDS 默认会起若干接收线程具体数量受[DomainParticipant]配置里的线程池参数影响数据到达后在接收线程里完成反序列化然后同步调用 listener。这意味着跨语言回调发生时栈上同时压着 C 的接收线程帧和 C# 的托管帧。C# 侧注册的委托如果在某一刻被 GC 回收了原生侧再调这个函数指针就是野指针表现为进程直接退出、没有托管异常、也没有 dump非常难查。封装的 1.0 版本在订阅端专门维护了一个静态的委托字典把回调委托强引用住配合GCHandle.Alloc固定住 userData才算把这个问题按住。另一个约束是回调线程是 DDS 的公共资源多个 DataReader 可能共用同一条接收线程在回调里做阻塞操作读数据库、发 HTTP、弹窗会拖慢甚至堵死其它 Topic 的接收。稳妥的写法是回调里只做一次内存拷贝把数据丢进BlockingCollection或者ChannelT业务逻辑放到独立线程消费。3. 目录与构建链这套封装是怎么从 IDL 一路编到 DLL 的3.1 源码目录逐层看解压之后目录大致是这样每个位置的作用都比较明确opendds-csharp-1.0/ ├── idl/ # DDS 类型定义发布订阅双方共享 │ └── Sensor.idl ├── native/ # C 桥接层 │ ├── include/ │ │ ├── bridge_api.h # extern C 导出声明C# 侧对照它写 DllImport │ │ └── bridge_types.h │ ├── src/ │ │ ├── participant.cpp # Participant / Topic 的创建与销毁 │ │ ├── writer.cpp # DataWriter 封装与 write 调用 │ │ ├── reader.cpp # DataReader 封装与监听器 │ │ └── dds_config.cpp # ini 解析、QoS 默认值 │ ├── generated/ # IDL 编译产物构建时生成不入库 │ └── bridge.mpc # MPC 工程文件 ├── managed/ # C# 托管层 │ ├── OpenDdsSharp/ │ │ ├── NativeMethods.cs # 所有 DllImport 集中在这一个文件 │ │ ├── DdsParticipant.cs │ │ ├── DdsDataWriter.cs │ │ ├── DdsDataReader.cs │ │ ├── QosProfile.cs │ │ └── SafeHandles.cs │ └── OpenDdsSharp.sln ├── samples/ # 一个发布端 Demo、一个订阅端 Demo └── config/ └── rtps.ini # 运行期发现配置generated/目录是构建时产物不要提交到版本库。NativeMethods.cs用一个文件集中放所有DllImport原因是 P/Invoke 签名写错时比如CallingConvention不一致、参数类型宽度不对往往表现为栈不平衡或者返回值变成垃圾值集中管理便于对照bridge_api.h逐行核对。3.2 三步构建静态库、桥接 DLL、托管程序集构建顺序是死的跳步一定失败。第一步用opendds_idl和tao_idl处理Sensor.idl生成 TypeSupport 相关的 C 代码。手工执行的命令大致是这样# 1. 先跑 tao_idl生成结构体本身的 C 映射 tao_idl -I$DDS_ROOT -Ssi -o native/generated idl/Sensor.idl # 2. 跑 opendds_idl生成 TypeSupport 接口定义 opendds_idl -I$DDS_ROOT -o native/generated idl/Sensor.idl # 3. 再对生成的 SensorTypeSupport.idl 跑一遍得到 TypeSupport 的 C 实现 tao_idl -I$DDS_ROOT -Ssi -o native/generated native/generated/SensorTypeSupport.idl opendds_idl -I$DDS_ROOT -o native/generated native/generated/SensorTypeSupport.idl第一条命令生成SensorC.cpp/h里面是Demo::SensorReading这个 C 结构体和它的序列化操作符。第二条生成SensorTypeSupport.idl描述类型支持接口。第三、四条把类型支持接口也编译成 C 代码。少跑任何一步链接阶段都会报TypeSupportImpl未定义。第二步编译 C 桥接层。原项目用的是 MPC 构建mwc.pl -type vs2019生成解决方案也可以用 CMake 自己重写。链接时要带上OpenDDS_Dcps.lib、TAO.lib、TAO_PortableServer.lib还有OpenDDS_Rtps.lib走 RTPS 发现的话。注意运行时库要统一——/MD和/MT混用会导致跨 DLL 传std::string或ACE_String时堆不一致直接崩在析构里。第三步编译 C# 类库。托管层只依赖opendds_bridge.dll编译期完全不需要 OpenDDS 的头文件这是分层带来的直接好处C# 开发者机器上不装 OpenDDS 也能编译。3.3 运行期配置发现方式决定能不能互相看见DDS 最玄学的地方在于代码全对、日志全绿就是收不到数据八成是发现discovery没配上。OpenDDS 提供两种方式。集中式用DCPSInfoRepo需要单独起一个进程当目录服务所有 Participant 连到它上面注册。启动命令形如# 单独一个终端跑目录服务 DCPSInfoRepo -o repo.ior -DCPSDebugLevel 2 # 发布端和订阅端都要指定同一个 ior ./publisher -DCPSInfoRepo file://repo.ior分布式走 RTPS不需要中心节点靠组播或配置好的对端列表互相发现适合跨网段或者不想多维护一个进程的场景。配置文件长这样# config/rtps.ini [domain/42] DiscoveryConfigrtps_discovery ParticipantIndex0 MaxAutoParticipantIndex10 [rtps_discovery/rtps_discovery] SedpMulticast0 SpdpMulticast0 # 组播不通时直接写死对端省掉排查时间 SpdpPeers192.168.1.10:7400,192.168.1.11:7400SedpMulticast0和SpdpMulticast0关掉组播改用点对点。这个配置我一般会提前写好因为很多现场网络禁组播开着组播发现会一直静默失败日志里什么都看不到纯靠猜。ParticipantIndex在同一台机器上跑多个进程时必须各不相同否则 RTPS 的端口会撞。C# 侧不用关心这些细节封装把配置文件名透传下去就行var participant DdsParticipant.Create( domainId: 42, configFile: Path.Combine(AppContext.BaseDirectory, config, rtps.ini));domainId对应 ini 里的[domain/42]段两边不对应的话配置不会生效但也不会报错只是默默用了默认值。这个设计算不上友好排查时先确认 domain 号对得上。4. 核心链路拆解一条消息从 Publish 到 OnDataAvailable4.1 托管层的发布接口长什么样先看业务代码最终的样子再往里剥// samples/PublisherDemo/Program.cs using var participant DdsParticipant.Create(domainId: 42, configFile: config/rtps.ini); using var writer participant.CreateWriterSensorReading( topicName: SensorTopic, qos: QosProfile.Reliable); for (int i 0; i 100; i) { writer.Write(new SensorReading { Id 1001, Value 23.5 i * 0.1, Tag ch-01 }); Thread.Sleep(100); }CreateWriterT是泛型方法T必须带一个IDdsType约束由代码生成或者手写的 partial 类实现里面提供TypeName和序列化逻辑。这样做的好处是类型安全写错字段编译期就能发现而不是等到运行期订阅端解析失败。QosProfile.Reliable是个静态预设内部打包了一组 QoS 策略下面 4.5 节会展开。Write方法内部做三件事把托管对象序列化成字节数组、调原生dds_publish、检查返回码。返回码非零时抛DdsException带原生错误码和描述。4.2 P/Invoke 边界句柄、缓冲区和回调NativeMethods.cs是整个托管层的基石签名必须和bridge_api.h一模一样// managed/OpenDdsSharp/NativeMethods.cs internal static class NativeMethods { private const string Dll opendds_bridge.dll; // 回调签名topic 名、数据指针、长度、用户上下文 [UnmanagedFunctionPointer(CallingConvention.StdCall, CharSet CharSet.Ansi)] internal delegate void DataArrivedCallback( IntPtr topicName, IntPtr data, int length, IntPtr userData); [DllImport(Dll, CallingConvention CallingConvention.Cdecl)] internal static extern IntPtr dds_create_participant( int domainId, string configFile); [DllImport(Dll, CallingConvention CallingConvention.Cdecl)] internal static extern IntPtr dds_create_writer( IntPtr participant, string topicName, string typeName); [DllImport(Dll, CallingConvention CallingConvention.Cdecl)] internal static extern int dds_publish( IntPtr writer, byte[] buffer, int length); [DllImport(Dll, CallingConvention CallingConvention.Cdecl)] internal static extern IntPtr dds_create_reader( IntPtr participant, string topicName, string typeName, DataArrivedCallback callback, IntPtr userData); [DllImport(Dll, CallingConvention CallingConvention.Cdecl)] internal static extern void dds_destroy(IntPtr handle); }几个参数值得说清楚。CallingConvention.Cdecl必须和 C 侧的extern C默认调用约定一致写成StdCall在 x64 下恰好不报错x64 只有一种约定一到 x86 就栈失衡弹「运行时已损坏」的框。回调委托上标StdCall是因为 C 侧显式声明了__stdcall两边要对齐。dds_publish收byte[]封送时 CLR 会把托管数组钉住pin再传指针。这里有个隐含前提byte[]在封送期间不能被动过所以不要在多线程里共用同一个数组实例。我在封装里每次Write都新分配缓冲区虽然多一点 GC 压力但省掉了一类难查的错乱。userData用来在回调里区分是哪个 reader 触发的。常见做法是把GCHandle转成IntPtr传下去回调里再GCHandle.FromIntPtr取回托管对象。这个 handle 必须在 reader 销毁时Free漏了就是内存泄漏。4.3 订阅端监听器注册与数据回调订阅侧的托管封装核心是委托保活和异常隔离// managed/OpenDdsSharp/DdsDataReader.cs public sealed class DdsDataReaderT : IDisposable where T : IDdsType, new() { private readonly IntPtr _handle; private readonly GCHandle _selfHandle; // 关键委托必须被强引用住否则 GC 回收后原生回调就是野指针 private readonly NativeMethods.DataArrivedCallback _callback; public event EventHandlerT DataArrived; internal DdsDataReader(IntPtr participant, string topicName) { _selfHandle GCHandle.Alloc(this, GCHandleType.Normal); _callback OnNativeData; // 字段持有生命周期跟随 reader _handle NativeMethods.dds_create_reader( participant, topicName, new T().TypeName, _callback, GCHandle.ToIntPtr(_selfHandle)); } private void OnNativeData(IntPtr topic, IntPtr data, int len, IntPtr userData) { try { var self (DdsDataReaderT)GCHandle.FromIntPtr(userData).Target!; var bytes new byte[len]; Marshal.Copy(data, bytes, 0, len); var sample self.Deserialize(bytes); // 反序列化在回调线程里做 self.DataArrived?.Invoke(self, sample); } catch (Exception ex) { // 异常绝对不能穿透回原生栈否则进程直接没了 Trace.TraceError($[DDS] 回调异常: {ex}); } } public void Dispose() { NativeMethods.dds_destroy(_handle); _selfHandle.Free(); GC.SuppressFinalize(this); } }_callback声明成字段而不是局部变量是整个类里最重要的一行。早期版本写在构造函数里临时 new 一个委托传下去平时跑得好好的压测十几分钟后进程无声退出dump 一看栈在 DDS 接收线程上跳到了一个已释放的地址——就是委托被回收了。Marshal.Copy把原生缓冲区拷进托管数组这一步不能省。原生缓冲区的所有权在 C 侧回调返回后可能立刻被复用直接拿IntPtr用迟早读到脏数据。try/catch包住整个回调体也是硬性要求。托管异常跨 P/Invoke 边界传播是未定义行为.NET Framework 下直接让进程挂掉。这里统一 catch 住记日志代价是错误被吞了所以要配日志不然出问题连个线索都没有。Dispose的顺序也要注意先销毁原生句柄再释放GCHandle。反过来的话原生层还在回调托管对象已经没了一样是野指针。4.4 C 桥接层对应实现原生侧对应订阅创建和回调派发的部分大致如下// native/src/reader.cpp extern C BRIDGE_API void* dds_create_reader( void* participant, const char* topicName, const char* typeName, DataArrivedCallback cb, void* userData) { auto* dp static_castDDS::DomainParticipant*(participant); auto* ts TheTypeSupportRegistry::Find(typeName); // 按类型名找回 TypeSupport if (!ts) { SetLastError(ERR_TYPE_NOT_REGISTERED); return nullptr; } DDS::Topic* topic dp-create_topic( topicName, ts-get_type_name(), TOPIC_QOS_DEFAULT, nullptr, 0); if (!topic) { SetLastError(ERR_TOPIC_FAILED); return nullptr; } DDS::Subscriber* sub dp-create_subscriber(SUBSCRIBER_QOS_DEFAULT, nullptr, 0); // 监听器持有 cb 和 userDataon_data_available 里把样本序列化后回调出去 auto* listener new BridgeDataReaderListener(cb, userData); DDS::DataReader* dr sub-create_datareader( topic, DATAREADER_QOS_DEFAULT, listener, DDS::DATA_AVAILABLE_STATUS | DDS::SUBSCRIPTION_MATCHED_STATUS); return new ReaderContext{ dp, sub, topic, dr, listener }; }TheTypeSupportRegistry是桥接层里的一个静态注册表在 DLL 加载时把编译期生成的每种 TypeSupport 注册进去key 是类型名字符串。C# 传下来的typeName必须和 IDL 里DCPS_DATA_TYPE声明的完全一致包括Demo::前缀大小写敏感。错一个字符就是ERR_TYPE_NOT_REGISTERED而这个错误码在托管层表现为DdsException信息里会带上类型名排查的时候直接对比 IDL 就行。create_datareader最后一个参数指定了要监听的状态掩码。只监听DATA_AVAILABLE_STATUS的话订阅端和发布端匹配成功时不会有任何通知做联调时容易误以为没连上。加上SUBSCRIPTION_MATCHED_STATUSon_subscription_matched里打一条日志能立刻确认两端是否握手成功——这个日志我在每个项目里都会加上省下大量「到底连没连上」的猜测。4.5 QoS 在 C# 侧怎么映射QoS 是 DDS 里最容易配错又最难查的部分。封装把常用的几种组合预置成QosProfile静态属性同时留出属性让你单独改托管侧属性对应 DDS 策略可选值影响ReliabilityReliabilityQosPolicyBestEffort / Reliable丢包时是否重传DurabilityDurabilityQosPolicyVolatile / TransientLocal后启动的订阅端能否补到历史数据HistoryHistoryQosPolicyKeepLast(n) / KeepAll每实例缓存多少样本ResourceLimitResourceLimitsQosPolicyMaxSamples / MaxInstances缓存上限超了会阻塞或丢DeadlineDeadlineQosPolicyTimeSpan期望的更新周期超时触发回调配 QoS 有条铁律发布端和订阅端的 Reliability、Durability 必须兼容。订阅端要Reliable而发布端给BestEffortDDS 直接判定两边不匹配on_offered_incompatible_qos回调触发但数据一条都不通。这个回调在封装的 1.0 版本里只打日志很容易被忽略。Durability 也一样订阅端要TransientLocal而发布端是Volatile同样是静默不通。提示新接一个 Topic 时先把两端都设成BestEffort Volatile跑通再逐项往上加可靠性要求一次只改一项。全都要最强的配置反而是最容易不通的。5. 避坑与排查这套封装上线前必须过的几道坎5.1 现象发布端日志一切正常订阅端一条都收不到原因通常是发现没配上或者 domain 号不一致。OpenDDS 的发现过程是静默的Participant 创建成功不代表它发现了对端。集中式模式下DCPSInfoRepo没起、ior 文件路径不对、或者两端连的不是同一个 repo都会表现为「代码没错但就是不通」。RTPS 模式下如果网络禁组播默认配置会一直发现不了。解决分三步走先在订阅端加上SUBSCRIPTION_MATCHED_STATUS监听确认有没有匹配成功事件再用-DCPSDebugLevel 4起一次看发现阶段的日志里有没有对端的 Participant 信息最后确认两端的 domainId、配置文件路径、ParticipantIndex三样东西。我一般还会在同机器上先跑一遍自环发布订阅同进程自环不通说明是代码问题自环通了对端不通说明是网络或配置问题这样能把范围砍一半。5.2 现象程序运行十几分钟后无声退出没有异常也没有 dump原因基本可以锁定在回调委托被 GC 回收。C# 的委托对象只要没有强引用随时可能被回收而原生侧保存的函数指针不知道这件事。压测时触发 GC 的概率高所以表现是「跑一会儿就崩」。解决办法是把委托存成类的实例字段并且保证这个类的实例本身也被强引用通常在 reader 存活期间它自然活着。如果委托是动态创建的配合GCHandle.Alloc(del)固定住销毁时Free。检查方法在回调注册前后各打一条 GC 相关的日志配合GC.Collect()强制触发一次回收再发数据能复现就是这个问题。5.3 现象中文内容到对面变成乱码或者被截断原因有两层。第一层是编码string64里的 64 是字节数不是字符数一个中文字符 UTF-8 占 3 字节21 个汉字就满了超了会被截断。第二层是CharSet.Ansi的封送默认走系统 ANSI 代码页在非中文 locale 的机器上直接变问号。稳妥的做法是IDL 里长度按字节算留够余量C# 侧序列化统一用Encoding.UTF8显式转换不依赖默认封送P/Invoke 里所有字符串参数标注CharSet.Ansi并用[MarshalAs(UnmanagedType.LPUTF8Str)]指明 UTF-8。别指望CharSet.Auto它在不同平台行为不一样。5.4 现象在数据回调里直接调用发布接口整个进程卡死原因是死锁。回调运行在 DDS 的接收线程上而这个线程可能正持有 DDS 内部的锁在回调里同步调用write又去申请同一把锁自己等自己。表现是进程不崩但完全不动CPU 占用为 0用调试器挂上去看主线程和接收线程都停在等锁。解决方式是回调里绝不做任何 DDS 调用。把数据丢进ChannelT业务线程消费完再发布。封装的 1.0 版本没有做这层隔离得自己加。同类的坑还有在回调里Thread.Sleep、同步 IO、Dispatcher.Invoke到 UI 线程后者在 UI 线程忙的时候会阻塞接收线程。5.5 现象IDL 加了字段C# 侧收到的还是老结构原因是generated/目录没重新生成或者桥接 DLL 没有重新编译。IDL 编译产物是构建时生成的增量构建有时候认不出.idl变了直接跳过。表现是两端字段对不上反序列化出来的值错位但因为长度差异不大不会报错只是数据看着莫名其妙。解决是把generated/整个删掉强制全量重编构建脚本里加一条rm -rf的清理步骤。另外要保证发布端和订阅端用的是同一份 IDL 文件各自维护一份副本迟早会分叉。我一般把 idl 目录做成共享引用而不是复制粘贴。6. 二次开发把 1.0 封装改成业务能直接用的通信层拿到这套东西之后真正要改的地方通常不在 DDS 本身而在「怎么让它贴合你的业务模型」。1.0 版本给的是通用封装泛型参数T加IDdsType约束这种方式业务侧用起来还是得手写一堆结构体。我一般会先做两件事。第一件是把 Topic 定义收敛到一处。建一个Topics静态类把每个 Topic 名、类型、QoS 预设绑在一起业务代码只引用常量避免字符串散落各处// 业务侧统一入口改 Topic 名只改这一处 public static class Topics { public static readonly TopicDefSensorReading Sensor new(SensorTopic, QosProfile.ReliableWithHistory(10)); public static readonly TopicDefDeviceStatus Status new(StatusTopic, QosProfile.BestEffort); } // 使用 using var reader participant.CreateReader(Topics.Sensor); reader.DataArrived (_, sample) Console.WriteLine(${sample.Id} {sample.Value});QosProfile.ReliableWithHistory(10)是我在 1.0 基础上加的方法把「可靠传输 保留最近 10 条」这个常见组合封装成一个调用。业务侧配 QoS 的机会越少配错的概率越低。第二件是把序列化从「手写」换成「生成」。1.0 版里IDdsType的实现要手写序列化和反序列化字段一多容易出错。改造方向是用源生成器Source Generator读 IDL 的中间产物自动生成 partial 类和序列化代码业务侧只维护 IDL 一份真源。这一步改动量大但收益明显——IDL 加字段之后C# 侧重新编译就同步了不用再手工对齐。几个改造时的边界要守住。原生桥接层的 ABI 尽量别动加功能优先在托管层做因为 ABI 一改就得同步更新两边的构建产物很容易出现版本错配。回调线程的约束不能破任何新加的处理逻辑都要保证「回调里只拷贝处理放后台」。Dispose 的链路要顺着检查一遍每新增一个GCHandle或者原生句柄都要在对应的Dispose里配对释放。验证方式我习惯用三步同进程自环跑通排除网络和发现因素、跨进程同机跑通验证发现配置、跨机跑通验证网络和时钟。每步之间改动的只有环境一旦某步失败问题范围是明确的。血泪经验是版本号。这套封装 1.0 的托管层和桥接 DLL 之间有隐式契约——导出函数签名、错误码含义、类型名格式任何一项变了旧 DLL 配新 C# 就会以各种奇怪的方式失败包括但不限于访问冲突、返回垃圾值、静默不工作。从那以后我每次发版都强制走一遍「删干净 generated 目录 全量重编两边 三步验证」并且把桥接 DLL 的版本号写进dds_create_participant的返回值里做握手校验不匹配直接抛异常。多花十分钟省掉一整天的黑匣子排查。希望帮到你。本文还有配套的精品资源点击获取
