最近在開發服務后台的時候，使用c#調用了多個c++編寫的dll，期間遇到了一系列的問題，經過一番努力最后都一一解決了，在此做個總結，方便以后參考，畢竟這些問題也都是很常見的，主要有以下問題：
類型對照問題
c#調用c++方法時，首先要在類中定義一個與c++方法對應的外部方法，因為該方法是用C#語言定義的，那么肯定要弄清楚C#類型與c++類型如何對應，否則會導致調用失敗，關於這個問題其實不算什么問題，網上有很多類型對照的文章，都有很詳細的對應列表，用的時候參考一下就可以了。還可以使用工具，自動根據c++方法簽名生成對應的C# import方法簽名，參考 P/Invoke Interop Assistant。不過有一個問題還是要注意的，在x86模式下c#中的int對應c++中的int，而在x64模式下C#中的int是對應c++中的long，就這么一個小小的變量類型，在不經意間可能就會導致c++代碼出錯。還有一個問題是：托管的 PInvoke 簽名與非托管的目標簽名不匹配，可以在C#代碼的方法特性上加上CallingConvention.Cdecl。如下所示：
[DllImport("dllname.dll", CharSet = CharSet.Ansi, EntryPoint = "methodname", CallingConvention = CallingConvention.Cdecl)]
內存釋放問題
由於這個問題經常遇到，並且如果不能解決的話肯定不會再考慮使用該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為傳出參數
有的時候內存問題是純粹由於c++代碼導致的，一般遇到內存問題，我會用c++的測試工程再跑一遍，看看是否仍有該問題，如果是說明真是c++的bug了，可以通知同事去修改bug了。
內存問題有時候並不會體現的十分明顯，這需要我們更加細心的觀察日志並發現導致問題的真正原因。我之前遇到該方面的一個問題，剛開始內存漲幅非常明顯，經過多次與開發該dll的同事溝通后，問題已經解決的差不多了，但是大量測試后發現內存還是會有一點上漲，雖然幅度很小，但第六感告訴我此中必有蹊蹺，這要是上線跑個幾天豈不是還得爆，后來我把每一次調用c++方法后當前進程占用的內存輸出到文件中，經過仔細觀察，發現絕大部分文件(文件內容要傳入c++方法中進行處理)都沒問題，內存都很平穩，但是有極小一部分文件在傳入c++方法后，會導致內存相比其他文件有一個明顯的增長，看來問題是出現在這些文件中，隨后把這些文件單獨放在一起進行循環調用，內存一下子就大幅增長了，后面就不用說了，問題當然解決了。因此，要保持記日志的良好習慣，哪怕是在測試工程中。
版本問題(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中的方法。`異常捕獲+事件查看器+日志`可以幫助開發者發現程序的大部分問題與原因。其他問題
###### 1、0X1A截斷全文的問題這個是c++代碼讀取文件時可能會遇到的一個問題，雖然在調試某個問題的過程中發現了這個情況，但后來經開發dll的同事說問題的原因不是這個，這里就僅此記錄一下吧，ifstream in("test.txt",'b');這樣加上第二個參數就不會截斷了。
2、vs實時調試造成iis進程一直等待的問題
兩次遇到這個問題都是在下班后出現的，當時也不知道什么原因，后來通過windbg看了一下測試程序和w3wp進程的轉儲文件，通過!gle -all命令發現每個線程都在等待狀態，如下圖所示：
iis進程也是如此，本以為是代碼死鎖了，但是通過!locks命令也沒發現有任何異常（關於這個問題，可以參考 應用死鎖分析，當時有點懵，不知道是什么造成了這種情況，后來發生一件事情讓我弄明白了為什么，那是在快下班的時候，程序正好出現了一個異常（雖是異常，其實不會導致程序崩潰退出），這時服務器上彈出了一個vs實時調試的提示窗口，我注意到iis的cpu使用率突然就降為0，測試程序的控制台也輸出了線程等待的消息，聯想到之前那些STATUS_WAIT_0的錯誤信息以及貌似死鎖的情況，我感覺到可能是iis終止了所有線程，在等待vs實時調試這個交互窗口的結束，由於平時都是在下班后才會開啟測試程序來驗證程序的穩定性，所以當彈出這個交互窗口時，一直不會有人去處理，線程不會一直這么等下去，最后測試程序就退出了，iis也無法再繼續處理請求了，這個交互窗口也貌似消失了（為什么用貌似，因為我沒有專門去留意，只是憑印象覺得之前沒見過），想到這我點了一下“取消調試”，程序繼續往下運行了，也不再阻塞了。所以在程序運行的時候，最好關閉VS的實時調試功能，以免造成不必要的問題。進入visual studio中，選擇【工具】->【選項】，點擊【調式】，在【實時】選項卡中把【本機】【腳本】【托管】三個對勾取消掉就可以了。
其實就算實時調試窗口不見了，我們也可以通過系統事件來找到一些蛛絲馬跡，如下圖所示，只不過很難僅憑這個事件就斷定問題的原因，因為服務器上運行了多個w3wp實例，只能說通過這個情況增長一些經驗了。
其實還有一些問題，到現在有點記不清了，就不敢貿然憑殘存的那點記憶來描述了，以便造成不必要的誤解。對於遇到的問題，有些很明顯，有些很隱蔽，有些需要仔細分析，有些需要在大量測試的情況下才會發現，這里只想說一句：測試很重要，工作需用心。