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

Question

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

像这样：legacy delphi dll =＆gt; delphi COM wrapper =＆gt; .Net interop =＆gt; asp.net（mvc）

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

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

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

Answer 1

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。通过IDispatch进行后期COM调用可能会产生额外成本，这与使用Reflection进行调用一样昂贵。

---

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