简介：这份资源是一套面向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 里真正能对外暴露的组件有三种形态：一是 PBD（PowerBuilder Dynamic Library），这玩意只能在 PB 运行时内部加载，C# 完全碰不了；二是 PBX（PB 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，是这套架构里最省心的对称方案。
| 产出方 | 消费方 | 推荐形态 | 额外依赖 |
|---|---|---|---|
| PB | C# | PB 生成 COM 组件 | PB 运行时环境 |
| C# | PB | C# 注册 COM 组件 | .NET Framework、注册表 |
| PB | PB | PBD，不需要 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 API，PB 用 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 的 long，C# 的 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 属性要设为 False，COM 实例由 C# 端创建并管理生命周期，PB 端不要自动实例化，否则 ReleaseComObject 时引用计数会混乱。二是方法的访问级别必须是 Public，PB 默认函数是 Public，但如果你不小心改成了 Protected，COM 导出时会静默跳过这个方法。三是方法参数和返回值尽量用基础类型，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，不要写1；C# 端参数不要用 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 互操作方案就是最可靠的路径。我这些年反复用它迁移过不少系统，核心教训就是：不要把接口设计成「你想怎么调」，而要设计成「互操作层方便怎么调」。这个习惯是多次翻车换回来的，希望帮到你。
本文还有配套的精品资源，点击获取
