[原]捉虫记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，那么最好仍是随着产品的代码库一块儿进行编译。而不是跟随编译环境。