（想直接看结果的直接翻到最后）
之前对C++接触不多，最近工作需要，第三方给了一个C++的lib库，我们需要把它封装一下在C#中调用。对方要是直接给Dll就省事了。。。
研究了一下，基本有三个方向：
1. 建立CLI类型的，或者叫Managed的基于.NET的dll，这样c#可以直接进行引用。
2. 建立native的c++ dll，然后在C#用 dllimport的方式调用。
3. 建立com组件。
一开始感觉第一种很美好。直接加到reference中就能像引用一个C#的dll一样使用了。而且有一个好处是，我可以把这个dll工程和我的调用的C#工程放在一个solution中，然后在调试的时候，断点能直接进入到这个C++的工程中。这点要调试起来是很美好的哦。
方法可以参考这个：https://docs.microsoft.com/en-us/cpp/dotnet/how-to-wrap-native-class-for-use-by-csharp?view=vs-2017
一个不错的C#使用CLI/CLR 调用native C++ 的例子：http://www.dorodnic.com/blog/2014/12/10/calling-cpp-by-example/
基本上就是创建一个CLI类型的工程。注意工程的属性，选择一下CLR，以及Framework的版本。
在Header中引入头文件，在Resources中引入Lib文件。
这样在GoWrapper.cpp中就可以把需要的函数封装一下了。
这里可以选择更好的封装方式，比如对于原有的C++函数使用指针来返回结果的方式，我们可以使用一个自定义的类来返回之类的。但是考虑到要包装很多的函数，为了简便，最好让包装好的函数看起来和原有的函数差不多，对于指针可以通过ref或者out的方式来调用。
这样在调用的时候，就可以像下面这样调用：
注意如果想要用ref的方式调用的话，用下面这种来声明：
到现在，CLI的Managed dll方式基本已经完成了。可是想想如果要包装的时候，这一百多个函数的类型转换也将会是很大的一个工作量。我决定再尝试一下native dll的方式，虽然不能在同一个solution中debug，但是毕竟包装起来方便一些，只好忍忍了。
参考文档：https://msdn.microsoft.com/en-us/library/ms235636.aspx
主要就是要在native dll的函数前面加上 __declspec(dllexport) int __stdcall 的声明（__stdcall非必须），它就可以export了。
MSDN的关于dllexport和dllimport的说明：https://msdn.microsoft.com/zh-cn/library/3y1sfaz2.aspx
还有下面这个也不错：
https://docs.microsoft.com/zh-cn/cpp/build/importing-into-an-application-using-declspec-dllimport?view=vs-2017
为什么要写成 ifdef 就 export， 如果不，就import的方式，主要是为了便于同一个头文件可以同时应用于客户端和提供端。
根据上面那个walkthrough，native 的dll还是很好创建的。要记得在工程属性里面，CLR不要选择，就是native 的dll，或者记得要在创建project的时候的模板就选择native的。
不过，这样生成的dll，我在import的时候遇到了问题。import的代码如下：
这里我必须使用一个EntryPoint=“#1”来指定我这个函数的entrypoint，因为生成的dll里面，export的函数的entrypoint的名称后面有一串 @xxxx 的东西。这个entrypoint 可以使用depends打开查看，可以使用名称或者序号。这样很不方便对不对，我用过的dllimport没有哪个是要这么搞的。为了解决这个问题，我们需要用到一个DEF文件。在properties中可以指定所使用的DEF文件，不过如果你自己添加一个DEF文件的话，它会被自动添加到Properties的设置中的，其实你不需要手动去指定它。
Def文件的作用就是告诉编译程序，我要把哪个函数用来export，用什么样的名称来export。当然，有了这个DEF文件，就可以不需要__declspec(dllexport) int的声明了。
修改之后的头文件：
修改之后的def文件：
调用方：
到现在，应该还比较圆满了。虽然我么有了调试C++库的便利，但是包装几百个函数也容易一些。只要直接把那个函数return回去就好了。
正当这时，凝望着我可爱的头文件。我忽然想起，当用depends查看生成的dll的时候。在依赖中是可以看到第三方的函数的。它们貌似也都加过 __declspec的前缀。那么既然它都加过了。那我还再Wrap一遍干啥？？？试了一下。把DEF文件删掉，把我加的Wrapper删掉，把我加的头文件也删掉。试了一下，可以用！！！
最终，其实就只是创建了一个native的dll，在resources里面加上了第三方的lib文件而已。别的自己的头文件和cpp文件一个都不用加的。有一种“慕然回首，那人却在灯火阑珊处”的感觉。虽然转了一圈，但是也算对于各种DLL的知识都有了了解，也算是有很多的收获了。而且这个方法适用的前提在于第三方已经把自己的函数都添加了 declspec的前缀。如果没有的话，可以简单的通过添加 DEF文件的方式来export出想要的方法。
附一个DEF文件的文档：https://docs.microsoft.com/zh-cn/cpp/build/reference/module-definition-dot-def-files?view=vs-2017
转载请注明出处！！
网友评论