简介这份资源是一套面向PB与C#开发者的跨语言DLL互调示例集适合需要同时掌握PowerBuilder和C#动态库封装、引用及接口对接的初中级工程师参考。包内含PB制作DLL、PB调用自身DLL、PB调用C#生成的DLL以及C#侧生成DLL和调用DLL的完整工程代码覆盖从源码、工程配置到可执行程序与运行依赖的各个关键环节。资源共53个文件涉及8个cs源码、2个csproj项目文件、2个sln解决方案、3个dll库文件、5个exe程序及配套pdb调试符号并包含pbw、pbt、pbl等PB工程文件包体约554KB。目前已有842人学习下载。通过学习这些工程示例可以直观理解DLL导出、引用路径设置、接口参数传递等跨语言调用中的常见问题与对应处理思路适合在项目集成或迁移时作为代码级参考。1. 一次真实的互调需求把两边都逼到了墙角某公司要升级一套安防监控系统底层设备采集用 C# 做的历史业务报表在 PB 里跑了十年。两边都改不动唯一的出路就是把 PB 的 dll 和 C# 的 dll 互相拉通。结果一动手就发现这个标题看着像「文件复制粘贴」实际是两个世界的事PB 的 dll 多数不是 Win32 意义上的 dll而是 PBD/PBX 或 COM 组件C# 的 dll 是 .NET 程序集进程里默认调不了非托管代码。接口互相调用本质上是在 COM 和托管代码之间搭桥桥搭错了编译能过运行必炸。这篇笔记把 PB 做 dll、C# 做 dll、两边互相调用的完整路径和参数规则写清楚适合正在做 PB 系统迁移、C# 和 PB 混部、或者被领导要求「把老报表挂到新平台上」的开发者。写完你会发现真正值钱的不是 dll 本身而是接口的设计边界。2. PB 的 dll 和 C# 的 dll同名同姓两种物种2.1 PB 的 dll 到底是什么PBD、PBX 与 COM 组件PowerBuilder 编译项目时窗口、菜单、用户对象会生成 PBL 库文件但 PBL 不是 dll也不能被其他语言调用。PB 里真正能对外暴露的组件有三种形态一是 PBDPowerBuilder Dynamic Library这玩意只能在 PB 运行时内部加载C# 完全碰不了二是 PBXPB Extension通常是 C/C 写的插件给 PB 调用的不是给 C# 用的三是 PB 生成的 COM 组件用 PB 的 Project 对象把 NVO不可视用户对象包装成 COM 接口这是 PB 能被 C# 调用的唯一常规路径。而 C# 的 dll 是 .NET 程序集里面有托管元数据CLR 才能加载。C# 生成的代码默认没有 COM 接口要想被 PB 调用得主动注册为 COM 组件或者开放 Win32 导出函数。两边互相调用的难点就在这里PB 调 C#本质是让 COM 客户端去调一个 .NET 对象C# 调 PB本质是让托管代码去调一个 COM 服务器。两种调用方向都要走 COM 或等效的互操作层绕不开。我一般会在项目一开始就做一个「组件形态决策表」先确定每个 dll 的消费方是谁再决定产出形态。如果只给 PB 用C# 组件做成 COM如果只给 C# 用PB 组件也做成 COM。两边都做 COM是这套架构里最省心的对称方案。产出方消费方推荐形态额外依赖PBC#PB 生成 COM 组件PB 运行时环境C#PBC# 注册 COM 组件.NET Framework、注册表PBPBPBD不需要 dll无C#C#普通 .NET 程序集无2.2 C# 的 dll 为什么不能直接被 PB 加载托管与非托管的边界C# 程序集依赖 CLR 的垃圾回收、类型系统和异常处理。PB 的运行时是原生代码它在进程里找不到 CLR也就没法直接调用 .NET 方法。想要让 PB 调 C#常见做法是给 C# 项目启用「Register for COM Interop」把托管的类暴露成 COM 可见。这个选项会在编译时生成一个 .tlb 文件PB 端通过 OLEObject 创建实例调用方法。反过来C# 调 PB 也没法直接 Assembly.Load 一个 PBD。PB 的 COM 组件在 Windows 注册表里注册后C# 用 Type.GetTypeFromProgID 或 dynamic 关键字创建实例本质上走的是 COM 通道。写入注册表的 ProgID 和 CLSID 是关键注册掉了或者位数不对调用链直接断开。这里有个初学者最容易踩的认知误区以为「dll 互调」是直接把文件引用一下就完事。实际是 PB 和 C# 之间的每次调用都要经过 COM 封送Marshaling参数会被转换、拷贝、序列化。字符串、数组、结构体这些类型跨边界时开销不小循环调用上万次能感觉到明显的延迟。所以接口设计要遵循一条铁律能一次传入的数据不要拆成一百次传能传基础类型不要传对象。2.3 选择互操作路线的四个判断标准判断走哪条路我通常会问四个问题。第一PB 版本是否还有技术支持PB 12.5 之前的版本做 COM 注册经常出问题建议先用一个小 NVO 验证环境第二C# 的宿主是 .NET Framework 还是 .NET Core/.NET 5后者对 COM 互操作的行为有差异第三目标机器是否方便配置注册表权限如果是普通用户权限运行COM 注册会失败第四是否必须走进程内调用如果两边系统在不同服务器上不如直接上 Web Service 或 REST别用 dll 互调。我见过有些团队用「C# 写 Web APIPB 用 HTTP 客户端调用」来代替 dll 互调这在分布式场景下更稳但代价是每个方法都要做序列化和网络开销还要处理超时。如果是同机部署、数据量中等的场景dll 互调还是有优势的延迟低、调试直观、不需要额外部署服务。判断标准很简单部署拓扑里只有一台机器选 COM 互调跨机器选 Web 服务。这不是技术偏好问题是运维成本问题。3. PB 调用 C# 的 dll把 .NET 类包装成 COM 组件3.1 在 Visual Studio 里配置 COM 可见的最小步骤创建一个 C# 类库项目类名和方法名要尽量简单避免重载。COM 互操作不支持方法重载两个同名方法只能暴露一个。项目属性里勾上「Register for COM Interop」Visual Studio 会在编译后自动注册。但仅靠这个选项还不够我给一个最小化的 C# 代码模板能跑通 PB 调用// C# 类库项目CsMathLib // 目标框架建议选 .NET Framework 4.6.x兼容性最好 using System; using System.Runtime.InteropServices; namespace CsMathLib { // 这个接口给 COM 导出用PB 只认接口不认类 [Guid(B7B4F4C2-8F3E-4B0A-9D2E-3C1D5E6A7B8C)] [ComVisible(true)] public interface ICalc { // COM 互操作不支持重载方法名必须唯一 int Add(int a, int b); string GetMessage(string name); } [Guid(A1A2A3A4-5B6C-7D8E-9F0A-1B2C3D4E5F60)] [ComVisible(true)] [ClassInterface(ClassInterfaceType.None)] public class Calc : ICalc { public int Add(int a, int b) { return a b; } public string GetMessage(string name) { return Hello, name; } } }这段代码里最关键的是[ComVisible(true)]和[ClassInterface(ClassInterfaceType.None)]。前者告诉 .NET 这个类可以导出给 COM后者禁止 CLR 自动生成一个 IDispatch 接口强制使用我们手工定义的 ICalc 接口。如果不加后面这个属性COM 端看到的方法列表会包含一些乱七八糟的辅助成员PB 的 OLEObject 调用时容易绑错方法。编译后打开命令提示符用管理员权限执行一次手动注册确保注册表项写入正确。即使 Visual Studio 已经自动注册过手动注册也值得做一次因为很多部署现场没有 Visual Studio需要靠这个命令。regasm.exe CsMathLib.dll /codebase /tlb参数说明/codebase让 COM 从 dll 所在目录读取代码库避免强名程序集问题/tlb同时生成并注册类型库PB 端有些旧版本 IDE 需要 tlb 才能看到接口定义。如果机器装了多个 .NET Framework 版本记得用对应目录下的 regasm.exe不要用系统 PATH 里随手抓的那个版本不匹配会注册成功但调用失败。3.2 PB 端用 OLEObject 调 C# 组件CreateObject 与外部函数的取舍PB 调 COM 组件有两条路。一条是声明 OLEObject用CreateObject动态创建另一条是声明OLEObject类型后直接ConnectToNewObject。我推荐 OLEObject 方式代码直观报错时能拿到具体的 HRESULT。下面是一个在 PB 窗口按钮里点击计算的示例// PB 代码按钮 clicked 事件 OLEObject lobj_calc long ll_result string ls_msg // 创建 COM 实例ProgID 是 命名空间.类名 lobj_calc CreateObject(CsMathLib.Calc) if IsNull(lobj_calc) or lobj_calc 0 then MessageBox(错误, 无法创建 COM 组件请检查注册表) return end if ll_result lobj_calc.Add(30, 12) ls_msg lobj_calc.GetMessage(PB开发者) MessageBox(返回, Add string(ll_result) ~r~n ls_msg) // 用完后销毁释放 COM 引用 lobj_calc.DisconnectObject() Destroy lobj_calc这段代码有两个细节值得注意。第一CreateObject的参数是 ProgID格式为「命名空间.类名」必须和 C# 端的namespace CsMathLib下的Calc类完全一致大小写也敏感。第二调用完必须DisconnectObject再Destroy否则 COM 对象不会立刻释放CLR 那边会觉得引用计数不对内存被拽住不放。参数类型映射是这一节的重点。C# 的 int 对应 PB 的 longC# 的 string 对应 PB 的 String这些基础类型没问题。但 C# 的 bool 对应 PB 的 boolean两边默认互通只是 PB 侧传true时要写成True而不是1有团队在这里翻过车PB 端lobj_calc.SomeMethod(1)给一个 bool 参数会被当成整数封送C# 收到后抛异常。3.3 数组和结构体跨边界的处理传引用还是传值数组是 PB 调 C# 最常见的翻车点。C# 方法的数组参数如果是int[]COM 封送后 PB 端拿到的是数组对象不能直接用下标访问。我的经验是绕过数组直接传拼接字符串或 JSON 字符串在 C# 端解析。PB 拼字符串是一等公民C# 解析 JSON 用 Newtonsoft.Json 两行代码搞定比处理 COM SAFEARRAY 省事十倍。C# 端的数组参数必然要搭配ref关键字并且标注[MarshalAs(UnmanagedType.LPArray)]否则 PB 传入的数组可能被拷贝而不是引用。如果非得传结构体强烈建议把结构体打平成基础类型参数比如把 Person 对象拆成 name、age、address 三个参数穿透 COM 边界后副作用最少。4. C# 调用 PB 的 dll把 PB 的 NVO 包装成 COM 组件4.1 PB 侧生成 COM 组件Project 对象与 NVO 的设置PB 不是每个对象都能导出成 COM只有继承自不可视用户对象NVO的类可以。新建一个 NVO里面写业务方法然后在 PB 的 Project 里选择「COM/MTS Component」指定对象和类名。这个 Project 会生成一个 dll并在注册表里写入 ProgID 和 CLSID。创建 NVO 时有几个设置必须提前确认。一是 AutoInstantiate 属性要设为 FalseCOM 实例由 C# 端创建并管理生命周期PB 端不要自动实例化否则 ReleaseComObject 时引用计数会混乱。二是方法的访问级别必须是 PublicPB 默认函数是 Public但如果你不小心改成了 ProtectedCOM 导出时会静默跳过这个方法。三是方法参数和返回值尽量用基础类型PB 的 Any、Date、Blob 在 COM 封送时非常不稳定能不用就不用。一个可导出的 PB 方法示例// NVO: n_customer_service // 这个函数会被导出到 COM 接口C# 端可以直接调用 public function string get_customer_name(long al_id) string ls_name // 实际业务逻辑查询数据库 ls_name 客户- string(al_id) return ls_name end function public function long calc_price(long al_qty, long al_unit_price) return al_qty * al_unit_price end function生成 COM 组件后PB IDE 会在输出目录里生成 dll 和一个 .tlb 文件。C# 端的常见做法是直接引用 tlb 作为 COM 引用或者用Type.GetTypeFromProgID动态获取。区别在于强引用 tlb 能在编译期做类型检查但每次 PB 侧改了接口都要重新生成并重新添加引用动态获取则完全绕过编译期检查接口变了也能跑直到运行时才报错。我个人倾向强引用 tlb因为接口变更在生产环境是极其危险的事编译期炸比运行期炸好一百倍。4.2 C# 侧动态调用 PB 组件Type.GetTypeFromProgID 与反射动态调用 PB COM 组件的 C# 代码很短适合快速验证和测试场景using System; using System.Reflection; class Program { static void Main(string[] args) { // ProgID 从 PB 的 Project 属性里查看通常是 PB80.项目名.对象名 Type pbType Type.GetTypeFromProgID(PB80.n_customer_service); if (pbType null) { Console.WriteLine(PB COM 组件未注册); return; } // 创建实例 object pbInstance Activator.CreateInstance(pbType); // 方法名区分大小写参数类型必须精确匹配 object result pbType.InvokeMember( get_customer_name, BindingFlags.InvokeMethod, null, pbInstance, new object[] { 1001 } ); Console.WriteLine(客户名称: result); // 释放 COM 对象 Marshal.ReleaseComObject(pbInstance); } }InvokeMember的第四个参数是 target 对象第五个是参数数组。PB 的 long 类型映射到 C# 是 int这里传 1001 没问题。如果 PB 函数有多个参数按顺序放进 object 数组即可。运行时如果提示「方法未找到」第一反应检查方法名有没有拼错或大小写第二反应用 OleView 或者注册表查看导出的接口定义别瞎猜。从 .NET Framework 4.0 开始还有一条更简洁的路线用dynamic关键字直接调用dynamic pbObj Activator.CreateInstance(pbType); string name pbObj.get_customer_name(1001);这种方式底层还是反射但代码可读性高很多。代价是 dynamic 绑定失败时报错信息比较含糊生产环境建议加 try-catch 并在 catch 里输出完整的异常链。4.3 PB COM 组件的生命周期与线程模型PB 生成的 COM 组件默认是 Apartment 线程模型意味着 C# 端如果同时从多个线程调用同一个实例PB 内部的方法会排队执行性能急速下降。如果业务上确实需要并发调用最好的办法是每个线程创建自己的 COM 实例而不是共享一个。C# 端用ThreadStatic或者手动管理实例池都行但别做「共享对象加锁」因为 PB 组件不是你写的它的内部状态你控制不了。释放顺序也很关键。C# 端显式调用Marshal.ReleaseComObject只能减一次引用计数如果之前有多个变量引用了同一个 COM 实例要循环释放直到引用计数归零或者干脆让垃圾回收器兜底。我在一个报表系统里见过 PB 组件被反复创建然后不释放三天后内存占用 2GB进程直接崩掉。后来统一改成 try-finally 里释放问题消失。5. PB 与 C# dll 互调避坑指南7 个真实踩过的坑5.1 32 位和 64 位混用导致「无法创建 COM 对象」现象C# 项目编译成 AnyCPU 或 x64运行时 CreateObject 失败错误提示「没有注册类」。原因PB 生成的 COM 组件可能是 32 位而 C# 的进程是 64 位两个位数不匹配COM 注册表里按位数分了两个视图。解决C# 项目强制编译为 x86或者在 64 位测试机上确认 PB 的组件是否有 64 位版本。检查方法是任务管理器里看进程位数注册表用 regedit 分别看WOW6432Node和正常路径里的 CLSID 是否存在。5.2 C# 组件编出来了但 PB 端 CreateObject 返回空现象regasm 成功tlb 也见了PB 端 CreateObject 后对象为空。原因C# 类没有无参构造函数COM 创建实例时找不到入口点。解决给 C# 类显式写一个 public 无参构造或者确认类的构造函数能被 COM 调用。这条是最容易被忽略的Visual Studio 默认生成的类确实有无参构造但一旦你写了带参构造默认的无参构造就被覆盖了。5.3 PB 调 C# 方法时 boolean 参数被当整数现象PB 的lobj_calc.SomeMethod(1)传给 C# 的 bool 参数C# 抛参数格式错误。原因COM 封送时整数无法隐式转换为 VARIANT_BOOL。解决PB 端必须写true不要写1C# 端参数不要用 bool改成 int再在方法内部转换成 bool这个方法可以绕开大部分互操作层的参数校验问题。5.4 PB COM 组件里返回了 DateTime 类型C# 解析出乱码现象C# 调用 PB 函数拿到的日期时间不是 DateTime 对象而是字符串或者数字。原因PB 的 DateTime 映射到 COM 是 DATE 类型但很多 PB 版本导出的改成字符串了。解决C# 端先拿 object再装箱成 string自己解析。PB 端做好约定返回字符串格式 yyyy-MM-dd HH:mm:ss两边都清晰。5.5 C# 端 ReleaseComObject 之后进程没有退出现象程序关闭后 exe 进程还在任务管理器里过一会儿才消失。原因COM 组件内部有线程或定时器没有释放也可能是 PB 运行时的空闲线程被拽住。解决C# 端在 finally 里调用Marshal.FinalReleaseComObject并阻止垃圾回收器提前回收GC.SuppressFinalize然后强制调用GC.Collect()听说这对很多人像玄学但实测有效。5.6 COM 组件注册时权限不足部署到客户机器上失败现象部署现场没有管理员权限regasm.exe 报错拒绝访问。解决把注册动作放到安装包的自定义动作里用提升权限执行或者改用免注册 COM 的方式。免注册 COM 需要 manifest 文件C# 端能够支持PB 端则不太行所以推荐直接提升权限。若客户安全策略禁止退路是改成 Web Service。5.7 PB 端调用 C# 组件后程序集锁文件无法更新现象开发中反复编译 C# dll提示文件被占用。原因PB 的进程还拽着 COM 对象dll 被加载到内存没释放。解决每次测试完必须走完 DisconnectObject Destroy管理员taskkill /f /im pb.exe是个暴力但有效的后悔药。6. 最后一章接口设计的三个实战技巧把互调成本降到最低第一个技巧所有跨边界方法只传基础类型。把复杂对象打平成参数列表用一句话总结就是「字符串走天下」——在 PB 端拼好 JSON 传给 C#在 C# 端拼好 JSON 传给 PB。我做过一个项目两边约定所有方法签名都是string func(string jsonInput)内部自行解析。这样接口数量少、变更少、排查时抓包很方便唯一的代价是没人帮你做类型检查。适合两边都很成熟、不太改动的系统。第二个技巧在 C# 端封装一个单独的 Interop 层类把 PB 的 COM 调用全部收拢到一个类里不让业务代码直接碰 COM 对象。这样将来 PB 组件换成 Web Service、或者换成另一个 C# 模拟组件时业务侧一行不用改。封装时要连异常一起包装COM 调用报错经常是COMException直接抛出给业务层没有任何业务含义要翻译成业务异常。第三个技巧互调层里强制做日志记录。每次调用记录入参、出参、耗时和 HRESULT。你很难通过调试器跟踪 PB 与 C# 的跨进程调用日志是唯一的真相来源。我习惯在 C# 端写一个简单的调用包装器内部记日志PB 端的调用方就不用承担这个责任。实际效率上多数互调系统的延迟瓶颈来自序列化和参数拷贝而不是日志所以加日志几乎零成本。如果看到这里你应该能感受到这套方案的边界PB 和 C# 的 dll 互调能推进但它吃环境、吃注册、吃参数约定。任何一个环节不稳表现都是「能编译、跑不起来」这也是为什么这么多团队宁可用 Web Service 也不碰 COM。但如果你所在的场景必须同机互调这套 COM 互操作方案就是最可靠的路径。我这些年反复用它迁移过不少系统核心教训就是不要把接口设计成「你想怎么调」而要设计成「互操作层方便怎么调」。这个习惯是多次翻车换回来的希望帮到你。本文还有配套的精品资源点击获取