背景
- 产品使用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，那么最好还是随着产品的代码库一起进行编译。而不是跟随编译环境。