MFC的使用——在共享DLL中使用MFC、在静态库中使用MFC

本文介绍了在Microsoft Visual Studio中开发MFC应用程序时,“MFC的使用”配置项的意义及影响。通过实例分析了不同配置选项对程序运行的影响,并提出了推荐的设置方案。

前言

我们在使用Microsoft Visual Studio软件(也就是我们常常说的VS)时,其中项目属性中有一项叫做“MFC的使用”,里面包含有不同的设置,会影响我们所编写的程序的使用,今天我就遇到了这个情况,我们一起来总结一下,避免犯下相同的错误。

内容

昨天写了一个小程序,使用的是MFC应用程序的工程,工具的版本为VS2013,工程参数都是默认的,其中有一项设置叫做“MFC的使用”,默认设置是“在共享DLL中使用MFC”,我虽然看到了但是没有放在心上,编码期间解决了一个MFC使用多字节字符集报错的问题,此处不展开,后续再表,就这样程序编写完成,非常完美!交给了一个叫做“小闪电”的用户,然后她怀着万分激动地心情拿到公司电脑一使用,结果报错了!!!

这里写图片描述

“无法启动此程序,因为计算机中丢失mfc120.dll。尝试重新安装改程序以解决此问题。”,看到这个问题我首先想到的就是动态链接库的事情,因为我使用的是VS2013正好使用的是12.0版本的库文件,所以说应该是目标机上没有这个库,当然可以手动下载这个库文件,添加至“C:\Windows\System32”目录,但是在程序开发工程中,你无法要求所有的用户都会这样做,只能从自身找解决方法了。

当然我也仔细查了一下这个叫做“MFC的使用”的参数,它其实包括3个选项,具体如截图:

这里写图片描述

  1. 使用标准Windows库   
  2. 在共享DLL中使用MFC    
  3. 在静态库中使用MFC

这三种当然有着不同的意义:

  • 第一种顾名思义,是使用WINDOWS SDK API库,不使用MFC类。话说一个MFC应用程序不使用MFC类是个什么情况,一开始我也想不通,后来我新建了一个MFC应用程序的工程,然后把这这项参数填成这一种,然后程序编译失败,具体错误如下图,这就说明问题了,如果是MFC工程必须选择第二项或者第三项,而第一项“使用标准Windows库”是为非MFC工程准备的(不知理解是否正确,请大神指教)。

这里写图片描述

  • 第二种指的是打包时一些MFC的DLL的内容没有被包含在EXE文件中,所以EXE文件较小,但是运行时要求系统中要有相关的DLL文件。这就是我的程序一开始选择的选项,要求目标计算机中至少要包含“mfc120.dll”库文件,否则无法使用。

  • 第三种是将DLL中的相关代码写进EXE文件中,文件较大,但是可以在没有相关DLL的机器上运行。个人感觉程序测试期间使用这个选项应该比较好,起码可以保证程序的正常运行。

总结

  • MFC应用程序的工程,关于“MFC的使用”属性,应该选择“在共享DLL中使用MFC”或者“在静态库中使用MFC”。
  • “使用标准Windows库” 选项只能用在非MFC工程中,如果用在MFC工程会导致代码编译报错。
  • “在共享DLL中使用MFC” 选项生成的程序可执行文件比较小,但是要求目标机器必须装有必要的库文件。
  • “在静态库中使用MFC” 选项生成的程序可执行文件几乎所有的Windows都可以执行,但是程序较大一些,其中包含必要的库文件,可以基本保证在别的机器上正常运行。
### MFC静态库共享DLL的区别 MFC(Microsoft Foundation Classes)支持两种主要的链接方式:**静态链接**和**动态链接(共享DLL)**。这两种方式在应用程序的部署、可执行文件大小、依赖性管理等方面存在显著差异。 #### 静态链接到MFC 当选择“在静态库使用MFC”时,MFC的代码会被直接编译到目标文件(如EXE或DLL)中。这种方式的优点是生成的程序可以在没有MFC运行时的机器上运行,因为它已经将必要的MFC代码打包进可执行文件中。然而,这也导致了可执行文件的体积显著增加,因为MFC的代码被复制到了每一个使用它的程序中。 例如,一个使用静态MFC链接的EXE文件可能包含如下代码片段: ```cpp #include <afxwin.h> // MFC核心头文件 class CMyApp : public CWinApp { public: virtual BOOL InitInstance(); }; class CMainWindow : public CFrameWnd { public: CMainWindow() { Create(NULL, _T("MFC Static Link Example")); } }; BOOL CMyApp::InitInstance() { m_pMainWnd = new CMainWindow; m_pMainWnd->ShowWindow(m_nCmdShow); m_pMainWnd->UpdateWindow(); return TRUE; } CMyApp theApp; ``` 该程序在编译时会将MFC静态库代码打包进最终的EXE文件中,因此不需要目标机器上安装MFC运行。但生成的EXE文件会比动态链接方式大得多[^3]。 #### 动态链接到MFC共享DLL) 当选择“在共享DLL使用MFC”时,MFC的代码不会被编译进目标文件,而是作为共享DLL(如`mfc140u.dll`)存在。这意味着生成的可执行文件更小,因为它只包含程序本身的代码,而MFC的实现则由操作系统在运行时加载。然而,这也意味着目标机器必须安装相应的MFC运行,否则程序将无法运行。 例如,一个使用动态MFC链接的DLL项目可能如下所示: ```cpp #include <afxwin.h> // MFC核心头文件 class CMyDLLApp : public CWinApp { public: virtual BOOL InitInstance(); }; class CMyDLLClass : public CObject { public: void ShowMessage() { AfxMessageBox(_T("Hello from MFC DLL!")); } }; CMyDLLApp theApp; BOOL CMyDLLApp::InitInstance() { return TRUE; } ``` 在这种情况下,生成的DLL文件依赖于系统中已安装的MFC DLL文件,因此部署时需要确保这些DLL文件存在于目标系统中,或者通过MFC Redistributable Package进行安装[^1]。 #### 模块状态与资源管理 在MFC规则DLL中,如果选择静态链接MFCDLL会将MFC的代码直接编译进DLL文件中,因此在调用DLL接口时,MFC使用DLL自身的资源。这种方式不需要模块状态切换,适用于资源独立的场景。然而,生成的DLL文件较大。 如果选择动态链接MFC,则DLL会与主应用程序共享MFC。在这种情况下,MFC使用主应用程序的资源句柄来加载资源模板。当DLL和主程序中存在相同ID的资源时,必须进行模块状态切换,以便MFC能够找到正确的资源模板。这种方式更节省空间,但资源管理更为复杂[^4]。 #### 部署与兼容性 - **静态链接MFC**:生成的程序可以在没有MFC运行时的Windows系统上运行,兼容性较好,但可执行文件较大。 - **动态链接MFC**:生成的程序较小,但要求目标系统上安装MFC运行。如果目标系统未安装MFC运行时,程序将无法运行,除非手动部署MFC Redistributable Package[^1]。 #### 总结 | 特性 | 静态链接MFC | 动态链接MFC | |------|-------------|-------------| | 可执行文件大小 | 较大 | 较小 | | 依赖性 | 无需MFC运行时 | 需要MFC运行时 | | 兼容性 | 更好 | 依赖MFC安装 | | 资源管理 | 使用DLL自身资源 | 使用主程序资源,需模块状态切换 | | 适用场景 | 需要独立部署的应用程序 | 节省空间、依赖系统环境的场景 | ---
评论 17
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

AlbertS

常来“玩”啊~

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值