使用P / Invoke有什么缺点

Question

我正在使用.net框架工作。在这个时候有一些情况，我使用P / Invoke做我无法用托管代码做的事情。

但是我从来不知道使用它的真正缺点是什么。这也是我尽量不尽可能使用它的原因。

如果我谷歌，那么我会找到关于它的各种帖子，有些会画出灾难性的图片，并建议永远不要使用它。使用一个或多个P / Invoke调用的应用程序的主要缺点和问题是什么？它们何时适用。 （不是性能视角，更多的是“无法从网络共享中执行”）？

Answer 1

1. 托管/非托管类型之间的编组会产生额外的开销
2. 不适合中等信任
3. 不太直观，可能导致细微的错误，如泄漏手柄，破坏内存，......
4. 在查看导出的C函数正确之前可能需要一些时间
5. migrating from x86 to x64
时的问题
6. 当出现问题时，您不能简单地进入非托管代码进行调试并理解为什么会出现异常。你甚至无法在Reflector中打开它： - ）
7. 限制跨平台互操作性（即：如果您依赖于仅限Windows的库，则无法在Linux下运行。）

结论：只有在没有托管备选方案或性能关键型应用程序中才使用，其中只存在非托管库以提供所需的速度。

Answer 2

使用P / Invoke有三种不同的情况，每种情况都会产生（或不存在）不同的缺点。

1. 您需要使用.NET Framework中未提供的Windows功能。你唯一的选择就是P / Invoke，你所面临的不利之处在于现在你的应用程序只适用于Windows。

2. 您需要使用其他人提供给您的C风格的DLL，并且没有托管等效项。现在你必须使用你的应用程序部署DLL，并且你在函数声明（例如IntPtr / int），字符串编组以及人们发现困难的其他事情中存在编组时间和可能的搞砸问题。

   < / LI>

3. 您有一些您编写或控制的旧本机代码，并且您希望从托管代码访问它而无需移植它。在这里你有（2）的所有问题，但你可以选择移植它。我将断言你通过移植它会导致更多的错误，而不是P /调用错误。如果您移植的代码会对本机代码（如CRT）进行大量调用，则可能会导致更大的性能问题。

我的底线是，虽然P / Invoke非常重要，但告诉人们避免它是不好的建议。一旦你做对了，运行编组成本就是剩下的。这些可能小于移植代码时的运行时成本。