简介面向 VS2019 下 MFC DLL 封装与调用的开发者这份资源以 MFC 扩展 DLL 与常规 DLL 两套例程为主线覆盖共享动态链接库的创建、接口导出、加载与卸载以及非模态对话框调用方式适合需要提升 C 组件复用能力的桌面应用工程师参照学习。压缩包共 224 个文件包含 3 套 sln 解决方案与 vcxproj 工程、12 个 cpp 与 27 个 h 源文件、6 个 dll、6 个 lib 及 exp/def 导入导出文件另有 rc 资源、调试日志和 PDB 符号文件整体约 328.67MB完整工程可直接用 VS2019 打开并对照源码、生成物与日志理解构建过程。已有 1035 人学习下载。两套例程分别展示扩展库导出类与常规 DLL 封装对话框资源编译产物中 dll/lib/exp 便于比对两种导出方式调试日志和 PDB 可辅助定位调用问题。配套例程不仅演示 AFX_EXT_CLASS 导出和项目配置还给出调用端使用 AfxLoadLibrary、AfxFreeLibrary 与 GetProcAddress 实现非模态调用的完整代码并区分动态/静态链接差异便于读者快速迁移到自己的模块化项目中。1. MFC DLL封装不是向导下一步就能跑通的事这次拿扩展库和规则库做对照做VC开发的人几乎都跳过动态链接库的坑VS2019里新建一个“MFC DLL”工程向导生成两个导出函数然后在主程序里一调用要么编译报错要么运行时对话框闪现后程序崩溃。问题往往不是代码语法而是对“MFC扩展库”和“MFC常规库规则库”两种封装方式的理解错位。这个例程包里同时给了两个完整示例一个展示了扩展库怎么封装对话框类并通过非模态方式调用另一个展示了规则库怎么用导出函数承载非模态对话框调用很适合正在做插件开发、软件模块拆分或者给现有MFC程序补扩展功能的开发者直接打开、编译、跑通。我今天就按这两个例子的思路把封装原理、调用代码和实际踩过的坑一起排干净。2. MFC扩展库与规则库先分清两种形态再动手2.1 两种库的本质区别导出对象还是导出函数VS2019里创建MFC DLL时向导会让你选择“带静态链接的MFC规则库”还是“共享MFC DLL的普通DLL”但真正影响封装方案的是你要导出的是“C类接口”还是“C风格函数接口”。MFC扩展库Extension DLL允许直接导出MFC类比如CDialog、CView、CWinApp的派生类。它和调用方共享MFC动态库实例也就是说DLL里的MFC状态与EXE里的MFC状态保持同一套这样你才能跨模块传递CWnd*甚至直接调用类的成员函数而不用担心内部句柄不一致。反过来MFC规则库Regular DLL也就是题目里说的“常规库”虽然也可以包含MFC类但导出给外界的通常是一组普通C函数类似于“创建对话框”、“返回控件内容”这种根功能即使调用方不是MFC程序也能正常加载。下表能帮你快速对号入座特性MFC扩展库MFC规则库常规库能导出的接口类型MFC类、成员函数普通函数、C接口调用方要求必须是MFC程序且共享MFC DLL可以是任何Win32/C程序共享MFC运行时必须动态共享可选择静态或动态链接MFC典型场景封装对话框类、视图类、自定义控件对外提供功能接口、给非MFC程序调用导出头文件需要提供MFC类型定义头文件只用extern C声明即可一句话记忆扩展库传“类”规则库传“函数”。封装一个对话框并要对方能直接操作这个类优先用扩展库如果只是想让对方弹出一个对话框并获取返回值规则库更省事。2.2 我的选型逻辑什么时候用扩展库什么时候用规则库我在实际项目中见过不少反例有人为了省事把对话框封装在规则库里但调用方是一个MFC扩展模块结果传入的CWnd*在规则库里变成了另一个“孤儿窗口”因为两边MFC模块状态不统一。反过来也有团队非要用扩展库导出一个纯计算函数导致接入方被迫拉入整个MFC环境得不偿失。我的判定顺序就三条调用方会不会只拿到这个DLL如果对方程序完全不用MFC只能选规则库并且导出函数签名里尽量别出现CWnd*、CString这类MFC类型。要用那就要保证对方也是MFC程序。你封装的东西是不是一个完整的MFC对象比如非模态对话框、可复用的视图、需要重写的控件就应该用扩展库因为调用方可能要持有这个对象甚至在其上调用自定义方法。会不会动态加载如果打算运行期用LoadLibrary去拿DLL规则库更容易只要导出函数是extern C就不会被C符号修饰影响精确调用。扩展库动态加载还得处理MFC模块初始化除非你直接用静态加载不然坑很多。这两个例程包正好都覆盖了上面的路径扩展库例程面向MFC程序做静态加载规则库例程提供了extern C接口方便动态或静态加载。下面我按两个方向分别拆代码。3. MFC扩展库封装从类导出到非模态调用3.1 扩展库工程配置要点在VS2019里新建一个“MFC DLL”工程为了做扩展库需要在“高级”选项里把“MFC的用法”选为“使用共享MFC DLL”同时把“DLL类型”选为“MFC扩展DLL”。注意MFC扩展库不能选择静态链接MFC否则导出的类无法与调用方共享MFC内部状态。工程创建后你会发现自动生成的DllMain里多了AFX_MANAGE_STATE的调用这个宏是扩展库的命脉它让当前DLL的MFC模块状态被正确保存与恢复。很多初学者手动写DLL时漏了这一句结果对话框里的资源加载错乱。下面是一段典型入口// MFCExprDemo.cpp : 扩展库入口 #include pch.h #include framework.h #include MFCExprDemo.h #ifdef _DEBUG #define new DEBUG_NEW #endif BEGIN_MESSAGE_MAP(CMFCExprDemoApp, CWinApp) END_MESSAGE_MAP() CMFCExprDemoApp theApp; BOOL CMFCExprDemoApp::InitInstance() { // 核心加载包含资源托管所需的模块状态 return CWinApp::InitInstance(); } BOOL CMFCExprDemoApp::ExitInstance() { return CWinApp::ExitInstance(); } extern C int APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID) { if (ul_reason_for_call DLL_PROCESS_ATTACH) { theApp.m_hInstance hModule; theApp.SetCurrentHandles(); } return AfxWinInit(hModule, NULL, NULL, NULL); }这段代码里AfxWinInit负责初始化MFC的Win32层引用扩展库必须要调用它否则后面创建CDialog对象时内部类指针是空的。SetCurrentHandles把资源实例句柄绑定到当前模块都是为了确保对话框模板资源能在这个模块里被找到。参数说明如果你把扩展库用在非MFC程序里AfxWinInit会返回失败这就是后续崩溃的直接原因。因此MFC扩展库的调用方必须也是MFC程序。3.2 在扩展库里封装非模态对话框类我们要导出一个类这个类内部创建并管理一个非模态CDialog派生对象。示例中的CDemoDlg是基础对话框提供一个全局静态指针让外部可以拿到当前实例来发消息或设置内容。// 导出对话框类 class AFX_EXT_CLASS CModelessDlgWrapper : public CWnd { public: CModelessDlgWrapper(); virtual ~CModelessDlgWrapper(); // 创建非模态对话框并立即显示 BOOL ShowDlg(CWnd* pParent nullptr); // 向对话框内控件发送消息 BOOL SetEditText(const CString strText); protected: bool m_bCreated false; CDemoDlg* m_pDlg nullptr; afx_msg void OnDestroy(); DECLARE_MESSAGE_MAP() };关键在ShowDlg的实现不能直接DoModal()那会阻塞消息循环而要用Create并ShowWindow。更不能在栈上创建对话框对象因为非模态要求对象持续存在栈对象会在函数返回时析构。BOOL CModelessDlgWrapper::ShowDlg(CWnd* pParent) { if (m_bCreated) return TRUE; // 防止重复创建 m_pDlg new CDemoDlg(this); if (!m_pDlg-Create(IDD_DIALOG_DEMO, pParent)) { delete m_pDlg; m_pDlg nullptr; return FALSE; } m_pDlg-ShowWindow(SW_SHOW); m_bCreated TRUE; return TRUE; } void CModelessDlgWrapper::OnDestroy() { if (m_pDlg) { m_pDlg-DestroyWindow(); delete m_pDlg; m_pDlg nullptr; } m_bCreated false; CWnd::OnDestroy(); }AFX_EXT_CLASS宏会在导出时展开成__declspec(dllexport)在调用方包含头文件时展开为__declspec(dllimport)所以只要这个类写在DLL工程里调用方包含头文件时就能直接调用。m_pDlg指针是长期持久的确保非模态对话框在被关闭时触发OnDestroy完成释放。注意这里的this指针传给Create的父窗口参数实际上Create的第一个参数是父窗口指针但CDemoDlg的构造器里你可能还需要保存真正的父窗口建议把pParent也一并保存否则消息框弹出时的所有者句柄不对。3.3 调用端静态加载并持有对象指针调用方工程要做的第一件事是告诉链接器去哪找这个导出类头文件加#include CModelessDlgWrapper.h并在工程设置里的“附加依赖项”添加扩展库的.lib文件。下面是EXE端的调用代码// 在某个MFC主窗口的命令响应函数中 void CMainFrame::OnShowModelessDlg() { if (m_pWrapper nullptr) { m_pWrapper new CModelessDlgWrapper(); if (!m_pWrapper-ShowDlg(this)) { AfxMessageBox(_T(对话框创建失败)); delete m_pWrapper; m_pWrapper nullptr; return; } } else { // 已经创建过则把窗口带到前台 m_pWrapper-ShowWindow(SW_SHOW); m_pWrapper-SetForegroundWindow(); } }这里有一个容易忽略的细节m_pWrapper必须是主窗口的成员变量不能是局部变量否则函数结束后CModelessDlgWrapper对象也会析构里面的m_pDlg虽然还活着但外层包装没了后续没法再给对话框发消息。逻辑说明ShowDlg内部负责new出CDemoDlg所以每次调用只需判断包装类是否存在。调用方持有的是包装类而不是直接操作对话框类这样即使以后对话框内部结构变化也能保持对外接口稳定。参数方面ShowWindow(SW_SHOW)和SetForegroundWindow()在重复点击命令按钮时很有用可以避免每次都重新创建实例。如果你希望用户每次点击都新建一个独立对话框那就改CModelessDlgWrapper让其内部增加一个实例计数器。4. MFC规则库封装普通DLL里做非模态调用4.1 规则库的入口与导出函数声明规则库Regular DLL和扩展库的核心差异在于它不强制对外导出MFC类而是导出一组C还是C风格都可的普通函数同时DLL内部可以自由使用MFC类。创建时在向导里选“使用共享MFC DLL”的“MFC规则DLL”或者“静态链接MFC”的规则DLL。注意如果打算把DLL发布给不同版本的调用方建议选“使用共享MFC DLL”但要保证调用方装了对应版本的运行库。规则库的DllMain大体如下// MFCRegularDemo.cpp #include pch.h #include framework.h #include MFCRegularDemo.h #ifdef _DEBUG #define new DEBUG_NEW #endif BEGIN_MESSAGE_MAP(CMFCRegularDemoApp, CWinApp) END_MESSAGE_MAP() CMFCRegularDemoApp theApp; BOOL CMFCRegularDemoApp::InitInstance() { return CWinApp::InitInstance(); } extern C int APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) { if (ul_reason_for_call DLL_PROCESS_ATTACH) theApp.m_hInstance hModule; return AfxWinInit(hModule, NULL, NULL, NULL); }注意规则库里的AfxWinInit同样必要但它的限制没扩展库那么严即使调用方本身没有任何MFC初始化DLL通过自己的AfxWinInit也能自建MFC环境创建对话框没问题。这点与扩展库形成鲜明对比——扩展库要求调用方也必须初始化MFC模块规则库可以不要求。4.2 导出函数创建并显示非模态对话框规则库里写一个导出函数函数签名里尽量避免出现CString、CWnd*这类MFC类型否则非MFC调用方没法编译头文件。一种安全做法是把对话框的窗口句柄以HWND返回把接收消息的父窗口句柄用HWND传入。这里演示最常用的方式——导出函数接收父窗口句柄并返回对话框句柄。// 头文件导出声明 extern C __declspec(dllexport) HWND WINAPI ShowModelessDialog(HWND hParent); extern C __declspec(dllexport) BOOL WINAPI CloseModelessDialog(HWND hDialog); extern C __declspec(dllexport) void WINAPI SetDialogEditText(HWND hDialog, LPCTSTR lpszText);实现文件里维护一个全局的对话框实例指针但注意要在ExitInstance里清理避免进程卸载时泄漏。static CDemoDlg* s_pDlg nullptr; HWND WINAPI ShowModelessDialog(HWND hParent) { AFX_MANAGE_STATE(AfxGetStaticModuleState()); if (s_pDlg ! nullptr) return s_pDlg-GetSafeHwnd(); CWnd* pParentWnd CWnd::FromHandle(hParent); s_pDlg new CDemoDlg(); if (!s_pDlg-Create(IDD_DIALOG_DEMO, pParentWnd)) { delete s_pDlg; s_pDlg nullptr; return nullptr; } s_pDlg-ShowWindow(SW_SHOW); return s_pDlg-GetSafeHwnd(); }这里第一行AFX_MANAGE_STATE(AfxGetStaticModuleState())是规则库的核心。由于规则库里有自己的MFC状态而调用方可能是MFC程序也可能是纯Win32程序如果缺少这个宏DLL内部拿到的模块句柄可能是调用方的导致对话框资源加载失败。这个宏把当前模块状态切换回DLL自己的。CWnd::FromHandle(hParent)把外部传入的HWND临时包装成CWnd*这样Create才有有效父窗口。注意FromHandle返回的指针是临时的不应当长期保存所以Create之后立即把父窗口信息传递给CDemoDlg内部保存。另一种做法是直接调用CDemoDlg::Create再ShowWindow这里为了简化写法用了临时包装。4.3 调用端动态加载方式更灵活规则库的调用端可以用LoadLibrary动态加载这样就不需要包含头文件和链接lib。示例代码展示动态加载方式适合不想在工程里添加依赖的插件化架构typedef HWND (WINAPI* FnShowDlg)(HWND); typedef void (WINAPI* FnSetText)(HWND, LPCTSTR); void LoadAndInvoke() { HMODULE hDll LoadLibrary(_T(MFCRegularDemo.dll)); if (!hDll) return; FnShowDlg pShow (FnShowDlg)GetProcAddress(hDll, ShowModelessDialog); FnSetText pSet (FnSetText)GetProcAddress(hDll, SetDialogEditText); if (pShow pSet) { HWND hDlg pShow(GetSafeHwnd()); if (hDlg) pSet(hDlg, _T(来自动态传递的内容)); } }调用约定必须注意导出端用了WINAPI也就是__stdcall那么typedef声明的函数指针也必须是__stdcall否则编译能过运行时栈被破坏轻则对话框异常重则进程崩溃。这是DLL调用里最容易出现的“玄学”错误之一。再补充一个释放点当对话框被用户关闭后CDemoDlg的OnDestroy里应当通知外部或者至少把PostNcDestroy里delete this。否则全局s_pDlg还指向一块已析构的内存。常见做法是重写PostNcDestroyvoid CDemoDlg::PostNcDestroy() { CDialog::PostNcDestroy(); if (s_pDlg this) s_pDlg nullptr; delete this; }这样动态创建的非模态对话框在窗口销毁后会自动释放自身并清空全局指针避免外部重复获取到野指针。5. 实战避坑编译链接与调用期的五个常见问题5.1 现象对话框资源加载失败Create返回-1原因DLL里的资源和调用方的资源ID冲突或者模块句柄没有切换。MFC扩展库和规则库对这个问题处理不同。扩展库中如果调用方和DLL都定义了IDD_DIALOG_DEMO且数值相同调用方自己的资源会被优先找到导致对话框加载出错。解决规则库必须加AFX_MANAGE_STATE(AfxGetStaticModuleState())并在每个导出函数入口都加。扩展库则要在DllMain里正确调用AfxWinInit同时推荐给对话框资源设置一个高位ID比如从1000开始避开调用方常用ID区间。更稳妥的方式是使用FindResource加模块句柄强指定资源来源但一般场景下重命名ID就够了。5.2 现象导出类在调用方编译时提示“未定义符号”原因扩展库导出类头文件只在DLL工程里用__declspec(dllexport)而在调用方工程里被当成普通类声明。注意AFX_EXT_CLASS宏在DLL内部和外部有不同的展开这要求调用方必须#include这个头文件并且在链接器输入中加入MFCExprDemo.lib。解决检查调用方工程的“附加依赖项”里是否包含了.lib并确认.lib和.dll都能从系统路径找到。另外如果使用了__declspec(dllexport)手动标记那在调用方头文件里要换成__declspec(dllimport)。用AFX_EXT_CLASS可以自动切换但前提是_AFXEXT这个编译宏在DLL工程里已被定义。如果没定义就会变成dllexport和dllimport混用。检查DLL工程的“预处理器定义”里是否有_AFXEXT。5.3 现象非模态对话框一闪而过或者创建后立即收到“调试断言失败”原因把对话框对象定义在了局部作用域。非模态对话框的Create不会阻塞函数返回后局部对象的析构函数会调用DestroyWindow于是窗口刚出现就被销毁。解决把对话框对象放在堆上用new分配并在对话框的PostNcDestroy中delete this。同时确保外层包装类扩展库例也有对应的生存期管理。我一般在调用端用一个成员指针保存DLL返回的HWND在关闭主窗口时调用导出函数去清理。血泪经验千万不要在栈上写CDemoDlg dlg; dlg.Create(...);然后交给用户操作十次有九次必然崩溃。5.4 现象Release版本一切正常Debug版本调用乱码原因不同配置下DLL和EXE使用了不同的MFC运行库。比如DLL用动态MFC Debug版EXE用动态MFC Release版或者一边动态一边静态都会造成CString内部结构不一致特别是跨模块传递CString时直接内存损坏。解决发布和调用时必须保证两边“配置”完全一致。更严格的做法是在规则库导出函数的边界不传递MFC类型改用const char*或const wchar_t*。扩展库更是如此AFX_EXT_CLASS导出的类成员如果包含CString那调用方必须用相同运行时配置编译。我现在的习惯是凡是跨模块接口一律只用HWND、LPCTSTR、BOOL这些原生类型MFC类永远不越过DLL边界。5.5 现象非MFC程序加载扩展库失败原因扩展库初始化时AfxWinInit要求当前进程已有MFC应用对象CWinApp。非MFC程序没有CWinApp扩展库的DLL主线程初始化会失败。解决如果确认调用方不是MFC程序就必须改用规则库并且导出函数里确保有AFX_MANAGE_STATE。规则库可以在普通Win32进程里正常工作因为它自己会构造一个MFC应用对象。如果你做了一个插件想给非MFC宿主用又不想放弃对话框封装那就用规则库对外只暴露HWND接口。这也是我见过的最多工程事故之一团队把控件封装成扩展库结果宿主程序不是MFC的连加载都过不去。6. 把例程改造成自己能复用的工具三个进阶验证技巧扩展库和规则库的例子看懂了实际上手时还有三件事值得做验证导出符号、验证调用约定、验证资源生命周期。先看导出符号。编译完成后用VS自带的“开发者命令行工具”执行dumpbin /exports MFCExprDemo.dll你会看到扩展库里导出的类符号大量是C修饰的复杂字符串比如“?ShowDlgCModelessDlgWrapper...”。这是C类导出的常见形态。而规则库用extern C后导出的是ShowModelessDialog等明文函数名。这个差异决定了你动态加载时GetProcAddress的写法如果是扩展库的类成员函数动态加载非常麻烦必须拿到类的虚表指针或通过接口转换所以扩展库更推荐静态链接。而规则库因为导出名清晰动态加载轻松。再谈调用约定验证。你可以在调用端故意写错typedef比如把WINAPI写成普通的__cdecl然后在GetProcAddress后调用程序会弹一个“栈错误”或直接崩溃。这个错误非常隐蔽尤其是在Release优化下。我一般会在回调指针前强制转成固定签名((void(__stdcall*)(void))pSet)(NULL)这种方式来测试指针是否有效但实际生产程序还是在typedef上保持一致。从那以后我每次写DLL封装都强制自己先在灌入代码前把导出端的调用约定写清楚再在调用端同步一次绝不依赖编辑器默认设置。再验证资源生命周期。把任务管理器或者进程监视工具打开找到你的宿主进程在非模态对话框显示和关闭的各个时刻观察进程内存变化。如果关闭对话框后内存没有回落说明delete this没有执行一直泄漏。在规则库例子里如果PostNcDestroy没被触发就需要检查是否在你的EXE端提前调用了DestroyWindow两次。一个稳妥做法是在退出时调用一个导出函数强制释放所有残留对话框实例。最终我自己的习惯是分两步走第一所有跨模块接口都先写一份“接口契约文档”哪怕只有三人团队也要注明调用约定、是否使用MFC类型、由谁负责销毁。第二每个DLL都做一个最小调用Demo非模态对话框就用一个按钮来创建和关闭保证它能在生命周期上反复打开、关闭100次不泄漏。这样才能把例程里的代码真正变成稳定可维护的模块。希望帮到你。本文还有配套的精品资源点击获取
