Visual Studio中MFC DLL与控制台应用配置生成DLL的区别

两类生成结果的核心差异来自项目模板预设的框架绑定、编译配置、初始化逻辑，并非单纯修改「配置类型为DLL」就能完全对齐，具体区别如下：

• MFC初始化与框架支持逻辑完全不同
  MFC DLL向导生成的项目会自动注入完整的MFC运行时生命周期逻辑：DllMain入口默认包含MFC模块状态初始化、扩展模块注册（AfxInitExtensionModule）、资源句柄管理、MFC线程本地存储配置、终止阶段资源清理逻辑，原生支持MFC类派生、消息路由、MFC资源（对话框、菜单、字符串表）加载、OLE/套接字等可选MFC特性。
  控制台项目修改配置生成的DLL默认不包含任何MFC相关初始化代码，甚至不会默认生成DllMain入口，强行引入MFC头文件调用MFC接口会因为模块状态未初始化，出现资源加载错误、访问违规、内存泄漏等问题，无法直接使用MFC能力。
• 默认编译链接配置存在本质区别
  MFC DLL向导会自动完成所有DLL+MFC场景的适配配置：预处理器宏自动添加_AFXDLL、_WINDLL，移除控制台专属的_CONSOLE宏；自动配置MFC链接方式（静态/动态链接共享MFC库）；链接器入口点自动设置为MFC DLL对应的入口函数，自动引入MFC相关依赖库；子系统配置完全适配DLL加载逻辑。
  控制台项目默认保留_CONSOLE预处理器宏，入口点默认指向控制台程序的mainCRTStartup，不会自动引入MFC依赖库，即便手动把输出类型改成DLL，大量编译参数仍按控制台EXE规则预设，直接编译会触发链接错误，手动逐项修改配置也很容易出现漏项。
• 模板生成的基础代码差异
  MFC DLL向导会根据选择的DLL子类型（常规MFC DLL/ MFC扩展DLL/带自动化支持DLL）生成匹配的基础代码：包括MFC类导出宏、OLE自动化注册逻辑、DLL导出示例、资源模板文件。
  控制台项目改出的DLL只有最基础的Win32原生DLL框架，所有MFC兼容代码、导出逻辑、特性支持代码都需要完全手写。
• 运行时默认行为差异
  MFC向导生成的DLL默认内置MFC资源切换逻辑，加载资源时会优先查找当前DLL模块的资源，不会和宿主EXE的资源冲突；CRT和MFC的模块状态做了隔离处理，多线程环境下调用MFC接口不会出现状态错乱。
  控制台改出的DLL即便手动补全MFC链接配置，默认也没有资源句柄切换逻辑，调用MFC加载资源时会默认读取宿主EXE的资源，很容易出现对话框加载失败、字符串显示错误的问题，模块状态未隔离也会导致跨模块调用MFC对象时崩溃。

如果手动把控制台项目的所有编译参数、初始化代码完全修改成和MFC DLL向导生成的项目一致，最终生成的DLL运行效果没有区别，但手动对齐配置的成本极高，很容易留下隐性bug。

相关配置参考截图：

内容的提问来源于stack exchange，提问作者Peter Boshra