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

【问题标题】：Why is COM interop preferred over P/Invoke in .NET?为什么 COM 互操作优先于 .NET 中的 P/Invoke？
【发布时间】：2012-06-11 08:25:44
【问题描述】：

在我们的项目中，我们在我们的 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%）

【问题讨论】：

你能从 64 位进程 p/invoke 到 32 位 dll 吗？我不这么认为。
您能否提供一些建议 COM 优于 P/Invoke 的参考资料？我非常同意您的观点，即 P/Invoke 是可用的更好的解决方案。 .NET BCL 中的大部分内部都是根据对 Win32 API 的 P/Invoke 实现的。使用 COM 互操作的唯一原因是您别无选择，例如与 Office 应用程序或仅限 COM 的 Windows API 部分互操作。
还记得 DLL 地狱吗？您的代码将使用第一个可用的同名 dll，而不是使用正确的 dll。直到运行时才会检测到任何 API 更改，这意味着版本控制几乎是不可能的。如果不更改函数本身的名称，您无法创建一个同时为新旧客户端提供服务的 DLL
通过使用免注册 COM（也称为并行注册），您可以避免缺点列表中的第 2 项和第 3 项。好吧，第 3 项变成了如何让免注册 COM 做你想做的事。 msdn.microsoft.com/en-us/library/ms973913.aspx
我不喜欢 COM。它不是线程安全的，而且速度很慢，它需要管理员权限才能安装 COM 组件，而且它完全不能移植到其他操作系统。总而言之，我非常喜欢将我的 dll 编译为 x32 和 x64，并调用正确的，并提供完整的路径，这完全消除了 dll-hell。

标签： .net com interop pinvoke

【解决方案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 调用可能会产生额外费用；这与使用反射进行调用的成本大致相同。

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

【讨论】：

很好的答案。我尝试了一个无注册的清单，但无法让它工作，至少不是来自 Visual Studio（独立属性）。我不确定“yourapp.exe.local”如何改变查找正确 COM 的行为？
我不知道如何回答“它不起作用”的问题。 .local 文件只是告诉 Windows 加载程序只查看包含 EXE 的目录，而不考虑注册表项中指定的路径。粗略且无法替代清单，但它肯定会很方便。
伟大的 cmets。但是无注册的 COM 可能非常棘手，并且是如何使 COM“更容易”的一个糟糕的例子。关于声明的第一点是有效的，但可以由提供 P/Invoke 签名的库作者解决，甚至可以制作一个 .NET 友好的对象包装器。我不得不完全不同意你的表现评论。 P/Invoke 性能远不及 IDispatch 后期绑定。事实上，P/Invoke、C++/CLI 和（非 IDispatch）COM 的每次调用性能都非常相似。 CLR + JIT 在所有这些方面都非常聪明。
@Cohen：上次我在让无注册的 COM 工作时遇到问题，我做了一个废弃的 VB6 项目，然后在上面运行 Make My Manifest。
也很容易用 Visual Studio 生成一个，将Isolated 属性设置为true。