C# Native Interop - 为什么大多数库使用 LoadLibrary 和委托(delegate)而不是 SetDllDirectory 和简单的 DllImport

Question

有一个great answer on SO关于如何在运行时为 DllImport 设置搜索目录。使用两行代码即可正常工作。

但是，许多开源项目改为使用 LoadLibrary 函数。有“谣言”说通过委托(delegate)调用 native 方法速度较慢。我称它们为“谣言”，因为我只在两个地方看到过这种情况，而且无论如何这都是微观优化。

最有意思的地方是这篇博文:http://ybeernet.blogspot.com/2011/03/techniques-of-calling-unmanaged-code.html

在那里，作者测量了不同技术的性能:

• C#(信息性)4318 毫秒
• PInvoke - 抑制安全 5415 毫秒
• 调用指令 5505 毫秒
• C++/CLI 6311 毫秒
• 函数委托(delegate) - 抑制安全 7788 毫秒
• PInvoke 8249 毫秒
• 函数委托(delegate) 11594ms

NNanomsg使用函数委托(delegate)，但在 this line 上提到博客文章并附有评论“这对传统 P/Invoke 的性能影响显然不好” .

Kestrel server来自 MSFT 的 ASP vNext 使用与 Libuv 库相同的技术:here is the code

我认为委托(delegate)比简单的 DllImport 使用起来更麻烦，考虑到性能差异我想知道为什么面向性能的库使用委托(delegate)而不是设置 dll 搜索文件夹？

是否有任何技术原因，例如安全性、灵 active 或其他原因 - 或者这只是个人喜好问题？我不明白其中的原理 - 有没有可能作者只是没有足够地搜索 StackOverflow!？

Answer 1

Hmya，博客文章，这种分发技术信息的方式存在根本性的缺陷。如果我们能投票给他们，世界会变得更美好。作者在比较苹果和橘子。嗯，更像是苹果和自行车。

这里比较了两种根本不同的互操作场景。第一个是“正常”的，一个在非托管 DLL 中调用代码的托管程序。使用 [DllImport] 属性或 C++/CLI 是首选武器。在 CLR 内部进行了高度优化，它动态生成机器代码来转换参数并进行调用。重要的是，托管程序总是运行 很多 非托管代码，因为它运行在纯非托管操作系统之上。

您所说的“慢速”版本是相反的。从非托管程序调用托管代码。有些人称之为“反向pinvoke”。它更加复杂，因为在调用托管代码之前，您首先必须加载和初始化 CLR。并创建一个应用程序域。然后找到并加载包含代码的 .NET 程序集。然后 JIT 编译它。

有以下三种基本方法:

• 自定义托管 CLR。这是迄今为止最强大的版本。您使用托管接口(interface)显式创建 CLR 实例并完全控制其配置。 CLRRuntimeHost COM 组件类是实现这一目标的主要工具。

• 通过为 .NET 类提供 [ComVisible(true)] 属性，将它们公开为 COM 组件。上手非常简单，非托管代码完全不知道它实际上正在使用 .NET 代码。默认的 CLR 主机被加载，COM 组件的注册表项指向 mscoree.dll，它根据需要引导 CLR。唯一的缺点是非托管代码作者需要编写 COM 客户端代码，这是一项正在丢失的技能。

• 您所说的，利用 C++/CLI 编译器生成 DLL 导出的能力。值得注意的还有 Robert Gieseke 的 Unmanaged Exports 工具，使用完全相同的技术，但通过重写程序集注入(inject)这些 DLL 导出。

除了调用费用之外，以第三种方式进行操作还有非常明显的缺点。它的可扩展性很差，每个方法都必须显式导出，而且它必须是静态的，因此您无法实现对象模型。还有 super 骗子、可怕、讨厌、无法处理的问题，当调用失败时你无法得到任何诊断。托管代码喜欢抛出异常，如果不是来自代码本身，那么来自试图告诉您传递了错误参数或无法准备代码的 CLR。您看不到这些异常，无​​法判断函数失败，也无法判断为什么它失败了。如果非托管代码没有使用非标准的 __try/__except 关键字捕获 SEH 异常，那么程序就会崩溃。没有任何诊断。即使它确实捕捉到 SEH，您也只会收到“它没有工作”的信号。

必须编写以这种方式调用的托管代码来处理此问题。它必须在公共(public)方法中包含 try/catch-em-all。并记录异常并提供一种返回错误代码的方法，以便调用者可以检测到故障。然而，诸如缺少相关 DLL 或版本控制问题之类的严重问题根本无法诊断。对于非托管代码作者来说，简单的 LoadLibrary + GetProcAddress 看起来很容易，但它是长期支持的噩梦。