8

在我们的项目中，我们在我们的 asp.net 应用程序中通过 COM 重用了很多 Delphi 代码。

像这样：legacy delphi dll => delphi COM wrapper => .Net interop => asp.net (mvc)

我们在访问冲突、dll 卸载等方面存在一些问题......我现在已经移植了一些以直接通过 P/Invoke 代码使用旧版 dll。

当我查看有关 COM 和 P/Invoke 的资源时，人们几乎总是建议使用 COM。这是为什么？P/Invoke 没有以下好处：

  • 签出的代码将始终使用正确的 dll，而不是最后注册的 COM
  • 多个版本可以在服务器上并行运行（例如：DEV、TEST 和 QA）
  • 没有更多的 COM 注册麻烦
  • 比 COM 通信快得多（我读过的文章表明速度提高了 30%）
4

1 回答 1

11

PInvoke 是一个非常好的工具，但它肯定不能替代 COM。PInvoke 仅支持具有 C 语法的简单函数；COM 允许您实现对象模型。以Microsoft.Office.Interop命名空间中的类为例——它们都是没有包装器的纯 COM 类。使用 PInvoke 进行 Office 互操作将非常痛苦。

PInvoke 的另一个核心问题是，编写声明通常是客户端程序员（最不可能正确处理它们的人）的负担。COM 作者可以发布自动生成的类型库，就像 .NET 程序集中的元数据一样，极大地消除了出错的可能性，并且客户端程序员无需在 Project > Add Reference 之外进行任何工作。

解决你的子弹：

  • 签出的代码将始终使用正确的 DLL，而不是最后注册的 COM
    您仍然受制于 Windows 的变幻莫测，无法找到正确的 DLL。避免意外的唯一好方法是将DLL与EXE存储在同一目录中，这在COM中也很可能；您所要做的就是创建一个名为的空文件yourapp.exe.local

  • 多个版本可以在服务器上并行运行（例如：DEV、TEST 和 QA）
    在 COM 中也不是问题，使用上述技术或使用无注册清单。

  • 没有更多的 COM 注册麻烦
    使用无注册清单，因此不需要注册。做起来很简单——只需将Isolated引用的属性设置为True.

  • 比 COM 通信快得多（我读过的文章表明速度提高了 30%）
    它比 COM慢得多。通过 ; 进行后期绑定的 COM 调用可能会产生额外费用IDispatch；这与使用反射进行调用的成本大致相同。

还有第三种实现本机代码互操作的方法：用 C++/CLI 语言编写托管类包装器。该技术在 .NET 框架中大量使用，特别是在 mscorlib.dll、System.Data 和 PresentationFramework 中，这些程序集对本机代码具有很强的依赖性。但是，不太适合 Delphi；它最适合可以从 C 或 C++ 轻松调用的本机代码。

于 2012-06-07T10:34:39.330 回答