C++ MFC程序引用32位与64位外部头文件和库文件常见问题

问题一：LNK2001 无法解析外部符号

举例:引用MySQL文件mysql.h,libmysql.dll,libmysql.lib文件后出现如下问题

问题原因：

引入的mysql.h头文件会去项目配置库路径中找库文件，因为头文件中定义的方法与库文件中的方法不一致，导致出现无法解析的外部符号问题。这里不一致的原因可能是32位的头文件在64位库文件中寻找方法，64位头文件与32位库文件交叉编译，或者32位头文件与32位库文件一致但是在64位环境中编译报错等原因。

解决方案：

方法①:可以尝试修改VS编译版本

将win32修改为x64 如下图所示

如果没有x64编译的话，可以在右击项目->属性->添加x64

修改编译版本之后大概率能编译通过，但是如果你项目中有引用的其他32位版本的头文件和库文件的话仍然会报错，所以方法①治标不治本。

方法②：下载或者更新与编译版本一致的文件并替换

     以我的问题为例，报错无法解析外部符号，也就头文件和库文件不一致，以及还有编译版本的原因，导致了出错。明白了出错原因，直接下载32位的mysql，引用其中libmysql.lib以及libmysql.dll。例如，我这是个老项目的维护，一开始的环境我并没有，我自己装的是Mysql server 8.0 ，项目中引用的是项目中的mysql.h,而配置信息是之前电脑中的mysql环境的库文件，转移到我自己 的电脑上，我引用自己的8.0库文件就出现了这个问题，为了解决这个问题，我直接将老师傅的电脑中的mysql环境(简单来说就是mysql整个文件夹)给复制下来了。

问题二: 报错 LINK2001 无法解析的外部符号  imp_xxxxxxxx

imp即引用了导入的不是合适版本的的库文件，这个问题与上述问题类似，主要是自己配置的时候注意32位和64位的文件，再就是编译的版本

问题三：Debug Assertion failed! 

出错原因：一方面可能是野指针，内存泄漏，另一方面可能是缺少文件

方法① 如果是野指针，内存泄漏的原因，一直点击重拾按钮同时打开调用栈窗口，直到上面的错误弹窗不再出现，而是出现一个异常窗口，这是查看调用栈信息寻找内存泄漏的位置修改代码。

方法② 如果你用release版本启动程序，发现编译能通过，但是日志显示程序编译完成后就退出了，无法启动，而debug出现断言错误。尝试方法一没有效果，并没有弹出异常窗口，则很有可能是缺少项目中的某些文件，以上图为例，这个断言错误就是系统缺少串口相关的文件，网上下载MSComm文件，将其中的MSCOMM.SRG、MSCOMM32.DEP、MSCOMM32.oca、mscomm32.ocx拷贝到：C:\Windows\System32（WIN7系统）；C:\WINDOWS\system32（XP系统）。

注意：64位win7系统还需要将mscomm32.ocx文件复制到C:\Windows\SysWOW64\目录下，否则后面注册会出错。

接着就是注册(系统注册表)：方法一：

在C:\Windows\System32里找到cmd.exe以管理员身份运行：

Regsvr32  C:\WINDOWS\system32\MSCOMM32.OCX

方法二：win+r ->regedit进入注册表

修改注册表：win+R组合键打开“运行”或者直接在开始菜单里找到“运行”；输入regedit后回车，打开注册表管理器，在其中找到HKEY_CLASSES_ROOT项下的Licenses项，添加主项命名为“4250E830-6AC2-11cf-8ADB-00AA00C00905”，并将键值修改为“kjljvjjjoquqmjjjvpqqkqmqykypoqjquoun”

这里修改注册表的时候有两个问题:一个是你新建了一个表项但是却无法重命名表名，这时你要查看这个表项名是否已经存在，另外就是是否是管理员权限，如果不是的话那就要按下述操作

登录管理员->右击新建项->权限->给自己需要的用户设置权限

问题四：LNK2019 无法解析外部符号。。又是在哪种引用的

出现此问题大概率是链接库内容填充不对，举一个例子，有一个项目需要编写C++ 动态库联调(输出动态库文件到可执行文件目录下进行调试)，用到了OpenCV的库文件，在属性页配置了OpenCV的库目录，并在连接器界面加入了相对应的库文件

一运行就出现如下的错误

出现上述这么多错误的时候已经可以晕一会了，因为实在不知道到底哪里引用了莫名其妙的变量或者库函数。只有一点可以明确，出现LNK2019就是链接库不对，于是我又仔细查看我的属性配置发现我添加的库名少了d。因为OpenCV中对于debug模式和release模式下的编译有两种库文件，debug模式下对应的是 库名d.lib 例如 111d.lib

release模式下对应的是库名.lib 例如 111.lib 

我直接一改编译运行，直接通过。所以往后再出现LNK 2019 无法解析外部符号，并提示在哪引用的直接去找引用的库目录和编译环境(debug/release)

问题五：LNK1104 无法打开*.dll文件

原因目前我认为有两个:

1 运行DLL程序会生成一个DLL文件到指定的目录，而当指定目录下有同名文件时会被覆盖。如果被本应该覆盖的文件正在被别的程序或者其他用户使用中就会导致无法覆盖从而导致无法打开,或者没被占用但是已经存在，我觉得这是个奇怪的bug，删除原来存在的文件后可以正常启动。

2 同名文件没有被占用，能够正常被删除，但是却无法再次生成，点击程序运行会爆出很多如问题四的错误，那种情况可以找找是不是动态链接库或者编译环境(debug/release)不对