如果我想从PowerBuilder（10或11.5）引用.NET dll，以下哪项是最佳实践？
1）将dll注册为COM对象，并通过OleObject使用COM对象 2）升级到11.5，并转换为PB.NET，这样我就可以在PowerBuilder代码中实际拥有C＃块 3）另一种方法
这些方法我应该注意哪些事情？
答案 0 :(得分：5)
需要注意的事项：
第一种方法（COM Wrapper）适用于任何版本的PowerBuilder，包括11.5及更高版本，当您只想创建Win32应用程序时。但是，对于您实际可以执行的操作存在一些限制。必须将组件标记为COM可见。您要呼叫的方法必须是公开的。如果方法过载，您可能会遇到版本问题。例外也是一个问题，您必须在.Net端实现挂钩机制才能捕获详细的异常信息。
第二种方法不仅需要11.5及更高版本，而且还要求您将应用程序编译为.Net目标类型之一（例如，WinForm）。鉴于您可能需要进行其他修改以支持编译为WinForm，您可能会发现有一点太多工作只是为了能够调用这个程序集。另一方面，如果你正朝着.Net目标前进，那么你已经确定了。
答案 1 :(得分：2)
我没有对PowerBuilder做过任何事情，但这是我们遵循的技术（非常成功），一个无法立即从VB6迁移的项目。
1）我们使用COM引用创建了一个shim / facade来公开我们需要的.NET项目。 （我们还指定了GUID的使用属性，因此我们可以完全控制兼容性更改。）
2）我们使用内置的对象处理（在您的情况下为OleObject）引用VB6代码中的COM对象（就像在PowerBuilder代码中一样）。
3）当项目被迁移时（在我们的例子中是C＃），它们引用了底层的.NET类而不是COM shim。 （我们使用Obsolete标签标记了垫片，以确保没有人意外地使用它。）
4）在迁移了对垫片的所有引用之后，我们移除了垫片。 （我们实际上是分两个阶段完成的。在第一阶段，我们离开垫片但修改了它以抛出异常并记录它可能有关呼叫的信息。这样我们就可以知道任何调用它的位置了确认没有问题后，垫片在下一阶段被移除。）
这对我们的好处是迁移可以逐步发生。我们选择不直接暴露底层的.NET对象，因为它们仍有一些变化的风险，我们需要COM接口尽可能稳定。
升级到PB.NET肯定是可能的......但我不知道迁移会有多复杂。您可能会发现必要的时间会使迁移成为一个重要的项目（当然这对我们来说也是如此）。
我们考虑的其他方法，但被拒绝为不合适我们的需求是：
将.NET组件包装在另一个应用程序（“服务”）中，并通过套接字通信与这些组件通信。
使用.NET框架“切出”到实用程序，并通过（例如）基于文件的机制传输信息。
需要注意的事项包括：
链接两侧使用的线程模型。 （我们首先给自己打了电话，因为系统的一部分运行了MTA而不是STA - 请参阅this question以获取更多信息。）
.NET方面的例外情况与您的应用程序类似。它可能是一个非常无用的“通用”错误，甚至可能出现在调用者而不是.NET代码中。我们在.NET端添加了日志记录，在重新抛出之前给出了更详细的任何异常记录，并让调用者尽可能地处理事情。
我希望这会有所帮助。祝你好运！
答案 2 :(得分：0)
此刻我实际上遇到了同样的问题。我们使用PB 11.5，但是我们现在无法将我们的应用程序移动到.NET目标，并且在本机PB应用程序中无法执行.NET内容（PowerScript＃...）。所以，我向当地的支持部门征求意见，他们回复了Sybase的建议是使用PBNI：
Roy Kiesler在CodeExchange称为PB2DOTNET的一个很好的示例项目。将帮助您跳过前几个步骤（请注意，代码不是新的，您必须同时迁移本机PB和PBNI）。
这种方法的缺点是它增加了你必须维持的中间水平。但是，PBNI类应该只是.NET类的一个瘦包装器，这样一旦升级到PB12，就可以轻松地摆脱PBNI部分。