在開發過程中經常需要在C#中調用C++編寫的DLL，中間碰到過一些問題，這里做個總結，方便以后參考。
- 類型對照問題
- 內存釋放問題
- 版本問題(x86與x64)
- 編譯問題(靜態與動態)
- 資源加載問題
- 異常捕獲與問題定位
類型對照問題
c#調用c++方法時，首先要在類中定義一個與c++方法對應的外部方法，因為該方法是用C#語言定義的，那么肯定要弄清楚C#類型與c++類型如何對應，否則會導致調用失敗，關於這個問題其實不算什么問題，網上有很多類型對照的文章，都有很詳細的對應列表，用的時候參考一下就可以了。還可以使用工具，自動根據c++方法簽名生成對應的C# import方法簽名，參考P/Invoke Interop Assistant。
這里有一個調用約定的問題：__cdecl是C/C++函數的默認調用約定，__stdcall是C#函數的默認調用約定，也是所有的Windows API的調用方式。
有一個問題還是要注意的，在x86模式下c#中的int對應c++中的int，而在x64模式下C#中的int是對應c++中的long，就這么一個小小的變量類型，在不經意間可能就會導致c++代碼出錯。
C#調用C++（Win32）時常用類型轉換總結
內存釋放問題
由於這個問題經常遇到，並且如果不能解決的話肯定不會再考慮使用該dll了，這是一個可用性的問題。所以我在調用c++方法的時候，通常都會先批量跑一邊，通過日志記錄下每調用一次方法后，當前進程所占用的內存大小，這樣在運行一段時間以后，就能很清楚的看到內存是否持續增長，如果是的話就需要和編寫該dll的同事進行溝通，給他們提供測試數據，確認產生問題的原因。
有時即使C++中的方法進行了內存釋放，並且在c++測試代碼中已經沒有內存增長問題了，但是在C#中調用的時候內存還是會持續增長，該問題可能跟使用的場景有關，我這里是因為調用了一個返回char *類型的c++方法，我直接用C#中的字符串類型的一個變量接收了，結果發現內存總是釋放不了，后來讓同事把c++的方法更改了一下參數，然后在C#中用StringBuilder類型的變量作為參數傳入c++方法中來接收該方法的結果，這樣該內存問題就解決了。
C# // 在C#中聲明與C++方法對應的dllimport方法 [DllImport("dllname.dll", CharSet = CharSet.Ansi, EntryPoint = "Handle", CallingConvention = CallingConvention.Cdecl)] public static extern bool CPPMethod(string content,StringBuilder result); // 該變量用來接收c++方法的處理結果，作為傳出參數傳入c++方法，在構造的時候必須明確指定大小 // 如果不指定或者指定的大小不足，會導致c++方法出現空間分配不夠的異常 StringBuilder resultSB = new StringBuilder(length); string cppParam = "some content"; bool isSuccess = CPPMethod(cppParam,resultSB); // CPPMethod是與C++方法對應的dllimport方法 C++ // C++中的DLL函數原型，即：C#中要調用的方法，此處不再返回char *類型的結果，而是將結果放到傳出參數result中 extern "C" __declspec(dllexport) bool Handle(char* content, char* result); // result為傳出參數
版本問題(x86與x64)
版本不匹配的話，在調試時會提示正在加載格式不正確的dll。
如果使用的是32位的c++版dll，需要把C#項目的編譯平台設置為x86，如果使用的是64位的c++版dll，則設置為any cpu和x64都可以，這個需要自己根據實際情況對應好就可以了。
如果程序對內存的使用比較高，最好將程序編譯為64位，因為32位程序對單進程的內存大小有限制，經測試最大不超過2G。因為我的程序剛開始使用的是32位的c++版dll，並且在運行時需要調用這些dll加載很多資源，加載完這些資源進程占用的內存就差不多快2G了，所以總會莫名其妙的崩掉，甚至在加載的過程中就直接崩掉了，當時預感到是32位的問題，后來讓同事將dll重新編譯為64位后就沒有這個問題了。可以通過dumpbin命令判斷一個dll是32位還是64位，打開vs開發人員命令提示，輸入：dumpbin /headers 你的dll路徑，例如：dumpbin /headers d:\test.dll，如下圖所示：
如果是32位dll，紅框那里會顯示 
這里有一個地方需要注意，默認asp.net項目在調試時會運行在32位下的iisexpress進程中，如果你的項目是64位的，那么需要在VS中將iisexpress配置為64位模式，如下圖所示：
編譯問題(靜態編譯與動態編譯)
這個問題在運行時有時候會提示dll加載不成功，這個問題在不同的電腦上會有不同的體現，有的存在這個問題，有的就運行正常。而我本機就屬於正常的，部署的服務器屬於出問題的。出現這個問題后，在確認代碼無誤后，我用depends.exe這個工具查看了一下導致問題的那個c++版的dll都依賴什么程序集，在出問題的機器上會提示有一些依賴的dll不存在，而這些dll在運行正常的機器上是存在的。下圖紅色框中的為某些機器上可能會缺少的dll：
如果缺少相關dll，該條目的左邊會顯示出一個黃色的問號。這個問題可以采用靜態編譯進行解決，關於什么是靜態編譯可以自行百度，總之就是將程序所依賴的dll編譯到程序集中，這樣即使其他機器不存在這些dll也可以正常運行了，靜態編譯可以在vs的項目屬性中進行設置
默認是多線程 DLL(/MD)，即：動態編譯，這里更改為 多線程（/MT），即：靜態編譯。
剛才的配置只能解決缺少MSVCP120.DLL和MSVCR120.DLL這一類問題，對於缺少MFC相關的dll，還要經過下面的配置：
默認是使用標准Windows庫，這里改為在靜態庫中使用MFC。
資源加載問題(相對路徑與絕對路徑，dll中又調用其他dll加載資源)
這個問題相對比較隱蔽，出現時不會拋出異常，只能通過c++方法返回的狀態碼來判斷方法執行是否成功，要不是在這里放了一個斷點，特意看了一下，可能就遺漏這個問題了。
場景是這樣的：
我在webservice中調用c++版dll中的一個初始化方法，該方法會加載一些資源文件，我在vs中調試執行的時候沒問題，發布以后居然無法加載資源，貌似是路徑問題，我把資源文件放到w3wp.exe的根目錄下倒是可以成功加載，放在其他目錄中就不行，遇到這個問題首先想到的可能是資源所在的目錄權限不夠導致iis無法正常加載，因為之前有個同樣的問題就是這樣，但這次將資源所在的目錄更改為Everyone用戶的完全控制權限還是不行，並且該問題只出現在b/s項目中，c/s項目沒有這個問題。並且該目錄中存放了很多資源文件，有好幾個c++版的dll都需要從這里加載，其他幾個都沒問題，就這一個dll不行，看來不是權限的問題。這時候又想是不是相對路徑的問題，那我改成絕對路徑吧，結果問題依舊，后來在技術群里有個大牛說試試Directory.SetCurrentDirectory，趕緊修改代碼，測試了一下確實好使了。代碼如下：
// 保存當前工作目錄 string currWorkPath = Directory.GetCurrentDirectory(); // 切換當前工作目錄 Directory.SetCurrentDirectory(resourcePath); // 初始化進行資源加載 Init(resourcePath); // 這里要注意，使用了SetCurrentDirectory方法后，resourcePath要用相對路徑 // 還原當前工作目錄 Directory.SetCurrentDirectory(currWorkPath);
如注釋所示，使用SetCurrentDirectory切換了當前工作目錄后，方法中所用的路徑要改為相對路徑，一開始我用的是絕對路徑，居然還是無法加載。
后來發現了該問題的原因，在使用的dll中又調用另外一個dll進行資源加載，可能這樣會導致那個間接調用的dll出現路徑問題，所以出現資源加載失敗。
異常捕獲與問題定位
關於異常捕獲，雖然在方法中添加了特性HandleProcessCorruptedStateExceptions與SecurityCritical但還是捕獲不到c++中的異常，原因可能是c++在遇到某些異常時會造成程序直接退出，這樣在C#中就自然捕獲不到了，所以還是盡量保證c++代碼的健壯性。
如果在c#中調用了多個c++版dll中的方法，因為有時捕獲不到異常，很難通過常規方法找到問題的原因，c++方法中一旦出現異常可能會直接導致進程退出了，這時可以借助操作系統中的事件查看器來找出異常是來自哪個dll，同時在原有代碼中注釋掉那段調用該c++方法的代碼，或者mock一個方法調用，保證該段代碼無異常，然后再進行測試，如果無異常，那么只要解決了那個c++方法的問題即可，如果還有異常那么就是其他dll的問題，然后可以編寫測試代碼單獨測試曾經出問題的dll中的方法。異常捕獲+事件查看器+日志可以幫助開發者發現程序的大部分問題與原因。
轉自：
https://www.cnblogs.com/neverstop/p/5901652.html#item1
https://www.cnblogs.com/lidabo/archive/2012/06/05/2536737.html