下载dll放到同级目录后报下一个错误。 （这里注意：搜索的时候就发现大多数dll都是 vc_runtime 140 没有d，d表示debug。同事指点：使用vscode生成解决方案时要用release模式，不是debug模式，这也是导致我解决方式1和2失败的原因。） 下载dll放到同级目录后报错应用程序无法正常启动0xc000007b

· 之前自己用vs2019写的一个单纯的控制台程序（调用使用了MFC的dll程序），在安装了vs2019的win7上可以运行，但是在没有安装vs2019的电脑上就不能运行，提示了标题错误。

搜索过一些常规解决方案，例如：

这个问题，根据 应用程序无法正常启动0xc000007b怎么解决。主要是由于DirectX 9.0被损坏，需要下载软件运行一下（主要还是win7系统缺失了很多dll文件造成的）

打开DirectX修复工具，

依然报错。

第二种解决方案，根据教您解决应用程序无法正常启动(0xc000007b) 管理员身份打开cmd，输入

可以在路径查看修复情况，最后显示如下：（也需要重启）

参考 正确解决：坑爹的0xc000007b——应用程序无法正常启动可知： 肯定是缺乏了一些什么包，但是这个人的说法太含糊了

请教公司一个c++开发的前辈，经过高人指点，下载分发包，软件环境，就需要Microsoft VC++ Redistributable 2015这个可再分发包即可(我的可以运行的电脑是win7 vs2019) 下载 Visual C++ Redistributable for Visual Studio 2015:报错按不上，显示样本机（测试机）有一个更新的版本的时候就不能安装这个。

测试机版本：

所以找找更新的版本，下载Visual Studio 2015、2017 和 2019。 这个版本号是 14.27.29112（x86和x64都是这个版本号）

试了之后还是没用

比我本机用的要新了很多啊。。。找到本机用的吧。 在本机目录，vs2019的安装目录下， D:\visual studio2019\VC\Redist\MSVC\14.27.29016 就可以找到和自己电脑安装的分发版本一致的这个exe包 依然没用，哈哈哈

参考：应用程序无法正常启动0xc000007b解决方法

根据Dependency Walker使用说明，去这个网站下载这个软件：dependencywalker File->Open打开要查看dll依赖关系的exe文件，然后就会出现结果。

又忘了visual studio这个软件的一些使用方式，不常用就是难受。

我的解决方案下有两个项目，

使用的时候，将调用dll的那个项目设置为设为启动项目,

在将配置管理器部分的Debug模式变成Release模式之后，报了新的错误。（Debug模式下不报错，换成release模式就报错，也是奇怪。。。）

继续解决这个项目的错误

E0035 #error 指令: Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d] produce_dll C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\atlmfc\include\afx.h 24

C1189 #error: Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version. Please #define _AFXDLL or do not use /MD[d] produce_dll C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\atlmfc\include\afx.h 24

看起来是一个错。 根据error Please #define _AFXDLL or do not use /MD[d] occurs even after making changes in Project Properties 想起来以前debug模式下调试的时候也遇到过这个错误，没想到换个release模式还要从重新设置。

vs2019的设置位置是：解决方案资源管理器->右击项目名称->属性->高级->MFC的使用->选择在共享DLL中使用MFC 此外，注意 项目属性页（下图）中的配置和平台与运行界面的 并不总是一致， 所以可以直接把平台写成所有 （Debug中不设置可以运行，但是release不这样就不行？？）

错误 LNK2005 _DllMain@12 已经在 mfcs140u.lib(dllmodul.obj) 中定义 produce_dll E:\2.电动工具所\experiment02_C++\produce_dll\dllmain.obj 1

大部分中文博客都知道原因是什么： dll文件的cpp文件中默认就有dllmain这个函数，当添加MFC库时，在其中已经定义了DLLMAIN这个方法

解决方案基本都是参考： 基于MFC的dll中添加DllMain函数，编译时产生_DllMain@12 已经在 XXX.obj 中定义的解决方法 看到咧，vs2019的在这里（平台要选个特定的，不能选所有。。。） 但是我不太喜欢这种解决方式，调配置，太马后炮了

还有一些是去掉dll的cpp文件中的dllmain函数。。。。更不靠谱，例如由于引用MFC库导致DllMain重复定义问题解决 error LNK2005

解决方式2 推荐 根据error LNK2005: _DllMain@12 already defined in MSVCRT.lib 。 简单来说：就是在你编写dll的cpp文件最后加上一句代码

英语的大意是： 当我们使用MFC的时候，会直接/间接的include文件afx.h，然后MFC(afx.h)告诉链接器去寻找 _afxForceUSRDLL这个符号，然后把包含 _afxForceUSRDLL这个符号的对象放到程序中去，这样链接器就找到并把 dllmodule.obj放到程序中了，因为_afxForceUSRDLL是在dllmodule.cpp文件中定义的。

这是最常见的场景，当我们想在 共享DLL中使用MFC时，链接器编译时发现有两个DllMain函数，一个在我们自己编写dll的cpp文件中，另一个在Dllmodule.obj中。

所以我们需要告诉链接器把 _afxForceUSRDLL这个符号加到我们的dllmodule.obj中，为此我们要在自己写的DllMain函数定义的cpp文件里定义 _afxForceUSRDLL。这样链接器就会忽略mfc模块中的dllmodule.obj，只看到我们自己定义的那个DllMain。就好了

debug模式下生成的dll文件有180KB，exe文件有39KB 但是release模式下生成的dll文件只有28KB，exe文件有10KB。 原来这个东西还是不太一样哦，哈哈。还是release模式好，么么哒(* ￣3)(ε￣ *)