.net - 为什么 COM 互操作优先于 .NET 中的 P/Invoke？

Question

在我们的项目中，我们在我们的 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 没有以下好处:

checkout 的代码将始终使用正确的 dll 而不是最后注册的 COM

多个版本可以在服务器上并行运行(例如:DEV、TEST 和 QA)

没有更多的 COM 注册麻烦

比 COM 通信快得多(我阅读的文章表明速度提高了 30%)

Answer 1

PInvoke 是一个非常好的工具，但它肯定不能替代 COM。 PInvoke 仅支持具有 C 语法的简单函数； COM 允许您实现对象模型。参加 Microsoft.Office.Interop 中的类(class)例如命名空间——它们都是没有包装器的纯 COM 类。使用 PInvoke 进行 Office 互操作将非常痛苦。
PInvoke 的另一个核心问题是，编写声明通常是客户端程序员的负担——最不可能让他们正确的人。 COM 作者可以发布自动生成的类型库，就像 .NET 程序集中的元数据一样，极大地消除了出错的可能性，并且客户端程序员无需在 Project > Add Reference 之外进行任何工作。
解决你的子弹:

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

多个版本可以在服务器上并行运行(例如:DEV、TEST 和 QA)
在 COM 中也不是问题，使用上述技术或使用无注册 list 。

没有更多的 COM 注册麻烦
使用无注册 list ，因此无需注册。非常简单——只需设置 Isolated对 True 的引用的属性.

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

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