P / Invoke或C ++ / CLI封装C库
具有中等大小（40多个函数）的C API，需要从C＃项目中调用。 这些函数在逻辑上分解成几个类，这些类将被呈现给项目的其余部分。
在稳健性，可维护性，部署等方面，是否有任何客观的理由来选择P / Invoke或C ++ / CLI来实现该API下的互操作性？
我能想到的问题可能是，但没有问题的是：
我不确定的问题是：
还要别的吗？
在我使用现有的C库的情况下，我更喜欢PInvoke。 PInvoke虽然有时单调乏味并且有些麻烦，但是它是一个相当好理解的技术，它有着越来越多的工具和互联网文档。 一般来说，无论你遇到什么问题，Web上都有一个样本可用，或者快速检查堆栈溢出将提供一个解决方案。
C ++ / CLI是一个很棒的技术，但是与它的PInvoke相比，恕我直言，它的文档是有限的，用于互操作的特定场景。 它也没有PInvoke所具有的互操作解决方案的工具基础结构。 对于可以用PInvoke解决的场景添加C ++ / CLI程序集，对我来说似乎太昂贵了。
另一方面，如果我正在处理一个大型C ++库，我认为C ++ / CLI更多一些。 PInvoke不适用于C ++，我最终必须添加某种中间层。 要么是一个小的C层来包装所有的C ++函数调用，要么是一个C ++ / CLI库来弥补这个缺口。 在这种情况下，C ++ / CLI对我来说更自然一些。
它在很大程度上取决于如何处理内存所有权。 P / invoke只能在内存管理是一种特殊方式时才能封装指针，通常是调用者分配的缓冲区。 如果您的API返回指针（通过返回值或输出参数，无关紧要），并希望稍后将它们交还给销毁函数... p / invoke将执行自动封送处理或让您直接访问指针价值你需要发回以后，从来都没有。 因此，在这种情况下，C ++ / CLI成为一种非常理想的方法。
将P / Invoke想象成平台调用，你是否调用类似于Win32 API的方法，这非常适合P / Invoke，或者您是否需要为非托管库提供.NET绑定？
由于包装器通常非常薄，因此C ++ / CLI包装器不需要特别熟悉C ++ / CLI。 您需要了解的内容可以在语言规范中找到，它是一个包含大量示例的广泛文档。 P / Invoke对于建立较小的已有库很有好处，但如果调用该库的接口发生更改，则会遇到问题。 使用C ++ / CLI，您仍然可以在您的C ++ / CLI项目中拥有一个公开的托管界面，该托管界面用于托管代码，并更轻松地处理对C API的更改。
如果你想摆脱额外的DLL，你总是可以尝试ILMerge，但我不确定它是否能够处理混合程序集（显然不是），但它看起来好像可以将托管和非托管* .obj文件与PlatformSDK链接器是这样的：
cl.exe /MD /c /clr Unmanaged.cpp
csc.exe /target:module /addmodule:*.obj Managed.cs
link.exe /DLL /LTCG /NOENTRY /CLRIMAGETYPE:IJW *.obj Managed.netmodule
上一篇: P/Invoke or C++/CLI for wrapping a C library
下一篇: Calling a static function from an extern function C++ DLL