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

Question

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

像这样:遗留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%)

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调用可能会产生额外的成本,这与pinvoke调用一样昂贵.

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