[原]捉蟲記3：_ConectionPtr指針調用open失敗

背景

• 產品使用MySQL來存儲報警服務產生的報警。在報警服務的組件中使用ADO接口
• 客戶方有兩臺計算機，一臺計算機A用來組態，且能夠對設備進行調試，操做系統是Win7 64bit 專業版，安裝了VS2010；另外一臺計算機B用做驗收後生產環境中使用，操做系統是Win 2008 R2 標準版
• 我我的在公司的工做機的操做環境是win10 64bit 企業版

問題

      在客戶公司時，組態、開發、調試都是在計算機A上進行的，運行也是在計算機A上。一切都很正常。當調試完後，就從現場回到杭州，但是後續又出現了一些問題，瞭解完後就在公司的工做機上進行了實現與編譯。以後將修改後的模塊發到現場的同事那。當他將完整的系統和新變動的補丁部署到B機後，運行系統，發現報警服務並無對新產生的報警進行記錄。後來遠程進行調試後發現，_ConectionPtr指針在調用open時發生了異常，異常信息爲「不支持此類藉口」。當時第一反應就是MySQL的驅動有沒有安裝好。在確認完這個完整安裝後，從新安裝了系統，發現結果仍是同樣。可是一樣的代碼，一樣的環境，在以前的發行版本中必定是測試過的。並且我本身也在公司的工做機上安裝了虛擬機後，拿發行版進行驗證，一切都沒問題。百思不得其解。後來在檢查代碼過程當中，在同_ConectionPtr指針調用open的同一個cpp中，發現了一行代碼：

  1 #import "c:\Program Files\Common Files\System\Ado\MSADO15.DLL" no_namespace rename("EOF","EndOfFile")

      公司的聯編機器的操做系統是win7，而個人工做機是win10。初步懷疑是上面這個dll的問題。在工做機上寫了一個demo，在工做機與B機運行的結果不同，以後將B機的msado15.dll拷貝到工做機進行編譯後，發現兩方運行的結果一致。

緣由

      其實這個bug以前就有同事踩到，但是並無將此問題擴展到產品全部與MySQL相關聯的模塊進行排查。致使一個坑被踩了兩次。根本緣由是系統已經更改了COM的IID，致使用老的__uuidof(Connection)會提示E_NOINTERFACE (0X80004002)。

解決辦法

      1.將生產環境的msado15.dll拷貝到編譯環境下進行編譯

      2.使用微軟提供的Msado60_Backcompat_i386.tlb進行編譯，參考此連接

總結

      這種寫死到某個絕對路徑的作法確實值得商榷，尤爲是依賴到系統的模塊時，狀況會更糟。若是必須依賴特定的系統dll，那麼最好仍是隨着產品的代碼庫一塊兒進行編譯。而不是跟隨編譯環境。