简介面向 C/MFC 开发者的一套 VS2019 动态链接库封装例程同时包含 MFC 扩展 DLL 与 MFC 常规 DLL 两个独立工程并演示了非模态对话框调用方式适合需要快速掌握 DLL 导出接口设计、动态加载与跨模块类共享的读者。压缩包共 224 个文件既有 h/cpp 源文件、vcxproj/sln 工程文件也有编译生成的 dll/lib、obj/pdb 及 tlog 等中间产物完整保留从源码到构建的现场状态整体约 328.67MB。已有超过 1000 人学习下载。通过两个模块可对照研究 AFX_EXT_CLASS 导出宏、DEF 文件导出方式、动态链接库在对话框程序中的加载与释放流程还能看到调试信息、资源文件与工程配置的配套组织方式。对需要做功能模块复用或给现有 MFC 程序拆分 DLL 的开发者有直接参考价值。1. VS2019 下 MFC DLL 封装与非模态调用先搞清楚两种 DLL 再动手你用 MFC 写的主程序已经堆了几千行代码现在要让产品加一个“参数设置”悬浮窗最省事的做法不是继续往主工程塞对话框而是用 DLL 把界面模块拆出去。标题里的“共享动态链接库MFC 常规库”和“MFC 扩展库”是两条完全不同的路前者适合导出 C 风格接口后者适合把对话框类直接交给主程序 new。VS2019 下创建这两个工程并不难难的是资源句柄、MFC 运行库一致性和非模态窗口的生命周期。这篇笔记给出两个能照着建的最小例程并说明几种常见的翻车原因。适合刚跟完 vs2019 下载安装教程、正在看 MFC 教程的开发者也适合被 dll 冲突坑过的老手。2. MFC 规则 DLL 与 MFC 扩展 DLL 的边界选型表和三个影响调用方式的细节2.1 两种 DLL 在 VS2019 项目模板里的区别在 VS2019 里新建“MFC DLL”项目时向导的“应用程序设置”页会把 DLL 类型分成“使用共享 MFC DLL 的规则 DLL”和“MFC 扩展 DLL”。前者就是标题里说的 MFC 常规库也叫 Regular DLL它内部可以有一个精简的 CWinApp 派生对象导出的入口通常是 extern C 函数。后者用于扩展 MFC 框架本身允许把CMyDialog这样的类原样导出让主程序像使用本地类一样使用它。这个区别直接影响你后面能写出什么样的封装例程规则 DLL 适合把一组操作封装成黑匣子调用方不关心 MFC扩展 DLL 则要求调用方本身也是 MFC 程序并且大家共享同一份 MFC 运行库。很多人在纠结“桌面软件开发 用 MFC 还是 Qt”时注意力全在 UI 框架上真正落地时反而卡在 DLL 类型选择上。2.2 非模态调用为什么比模态调用更挑封装用DoModal()弹出模态对话框时窗口内部会运行自己的消息循环调用方代码停在DoModal这一行对话框关闭后才返回所以对象可以用栈上局部变量生命周期清晰。非模态不是这样Create()返回后窗口就继续运行消息由主程序的消息循环分发。要想窗口不被提前回收就必须用new创建对象并让对象在窗口销毁时自行delete。跨 DLL 做非模态时这个“谁创建、谁销毁”的问题会被放大。如果 DLL 导出的是CreateModelessDlg()这样的函数函数内部new了一个对话框对象外部拿到 HWND 后毫不知情关闭窗口时如果没人 delete就内存泄漏如果外部再 delete又可能跨模块崩溃。常用做法是在对话框的OnClose里DestroyWindow()再在PostNcDestroy里delete this让窗口自己收尸。2.3 选型表规则 DLL 还是扩展 DLL场景规则 DLL扩展 DLL调用方是非 MFC 程序C#/Qt 等合适导出 C 接口不合适导出 MFC 类无法消费调用方是 MFC 程序要直接使用对话框类不推荐类跨模块有风险合适AFX_EXT_CLASS 导出只想封装几个业务函数轻量配置简单偏重需要把 CString/CRuntimeClass 传回主程序可以但要注意模块状态更自然共享同一 MFC 状态我的习惯是只要明确调用方是 MFC并且封装对象是对话框就直接上扩展 DLL只要有一天可能被 C# 或脚本语言调用就老实用规则 DLL 导出纯 C 接口。后面两个章节分别演示这两个例程代码都在 VS2019 默认配置下跑过没有改其他额外设置。2.4 开工前先确认三样东西在开始建工程前打开 VS2019 安装器确认安装了“用于 v142 生成工具的 C MFC”组件没有的话项目模板列表里看不到 MFC DLL。接着在 DLL 项目属性 - 常规 - MFC 的使用里确认依赖方式规则 DLL 和扩展 DLL 都必须和主程序保持一致最后看预处理器扩展 DLL 的工程里必须有_AFXEXT规则 DLL 的工程里必须有_AFXDLL。这三项不对后面所有调试都会绕远路。3. 例程一用规则 DLL 封装非模态对话框导出 C 接口给主程序调用3.1 创建规则 DLL 工程和对话框资源新建项目时选择“MFC DLL”项目名取 RegDllDemo。向导的应用程序设置里DLL 类型选“使用共享 MFC DLL 的规则 DLL”完成。这个选项会自动加上_AFXDLL让 DLL 在运行时动态链接 mfc140u.dll而不是把 MFC 静态塞进去。在资源视图里添加一个 DialogID 设为IDD_MODELESS_DLG标题写“规则 DLL 面板”。按类向导生成类CModelessDlg基类选CDialogEx。对话框属性把 System Menu 保留关闭按钮留着即可后面我们会在OnClose里做销毁。3.2 导出创建函数AFX_MANAGE_STATE 不能省// RegDllDemo.cpp 或单独的 Factory.cpp #include pch.h #include ModelessDlg.h extern C __declspec(dllexport) HWND WINAPI CreateModelessDlg(HWND hParent) { AFX_MANAGE_STATE(AfxGetStaticModuleState()); CModelessDlg* pDlg new CModelessDlg; CWnd* pParentWnd CWnd::FromHandle(hParent); if (!pDlg-Create(IDD_MODELESS_DLG, pParentWnd)) { delete pDlg; return nullptr; } pDlg-ShowWindow(SW_SHOW); return pDlg-GetSafeHwnd(); }这段代码是前面分析的最大落点。AFX_MANAGE_STATE的作用是让 DLL 内部对 MFC 资源句柄的查找切回 DLL 自己的模块状态。少了这一行CreateModelessDlg看起来正常但Create加载IDD_MODELESS_DLG时可能从 EXE 那边找模板结果就是资源找不到。随后 new 出来的对话框指针不会返回给外部避免外部误删返回 HWND 给外部操作窗口。如果Create失败立即delete并返回 null不留野指针。注意AFX_MANAGE_STATE只在共享 MFC 的规则 DLL 里必需。如果你把规则 DLL 选成静态链接 MFC这一行可以省但会带来另一堆跨模块对象问题不推荐。3.3 让非模态窗口自己管理生命周期// ModelessDlg.cpp BEGIN_MESSAGE_MAP(CModelessDlg, CDialogEx) ON_WM_CLOSE() END_MESSAGE_MAP() void CModelessDlg::OnClose() { DestroyWindow(); } void CModelessDlg::PostNcDestroy() { CDialogEx::PostNcDestroy(); delete this; }OnClose处理右上角 X标准关闭行为直接DestroyWindow()触发PostNcDestroy。PostNcDestroy是窗口销毁链中最后一个能拿到对象地址的地方在这里delete this能保证 new 出来的对象被精确释放。外部拿到的 HWND 在销毁后失效但不会二次 delete因为外部根本没有对象指针。3.4 主程序用 LoadLibrary 调用这个 DLLtypedef HWND(WINAPI* PFN_CreateModelessDlg)(HWND); void CMainDlg::OnBnClickedOpenModeless() { HMODULE hDll ::LoadLibraryW(LRegDllDemo.dll); if (!hDll) { AfxMessageBox(L加载 DLL 失败); return; } PFN_CreateModelessDlg pfnCreate reinterpret_castPFN_CreateModelessDlg(::GetProcAddress(hDll, CreateModelessDlg)); if (pfnCreate) { HWND hDlg pfnCreate(GetSafeHwnd()); if (!hDlg) AfxMessageBox(L对话框创建失败); } }示例采用显式调用省去配置导入库的步骤。这里有几个参数需要盯住WINAPI对应__stdcall如果你用默认的__cdeclGetProcAddress后调用会栈错乱函数名用CreateModelessDlg是因为代码里用了extern C关闭名字修饰如果用 C 导出这里就变成了一长串?CreateModelessDlg...。LoadLibrary只需要执行一次稳妥做法是把 hDll 存成成员变量在程序退出时FreeLibrary频繁加载卸载会导致 mfc140u.dll 引用计数抖动也容易撞上 dll 冲突。4. 例程二用扩展 DLL 导出对话框类主程序 new 出非模态窗口4.1 创建扩展 DLL 工程与资源VS2019 里新建“MFC DLL”项目项目名取 ExtDllDemo这次在向导里选“MFC 扩展 DLL”。向导会自动生成 DllMain 并调用AfxInitExtensionModule这一步把扩展 DLL 的资源链接入主程序。工程预处理器里能看到_AFXEXT这正是AFX_EXT_CLASS宏判断导出/导入的关键。添加一个对话框资源ID 设为IDD_EXT_DLG生成类CExtDlg基类选CDialogEx。记得把对话框资源放在 DLL 的资源文件里不要放在调用方 EXE 的.rc中。4.2 用 AFX_EXT_CLASS 导出对话框类// CExtDlg.h #pragma once #include afxdialogex.h class AFX_EXT_CLASS CExtDlg : public CDialogEx { public: CExtDlg(CWnd* pParent nullptr); enum { IDD IDD_EXT_DLG }; protected: virtual BOOL OnInitDialog(); afx_msg void OnClose(); DECLARE_MESSAGE_MAP() };AFX_EXT_CLASS宏的意义在于构建 DLL 时自动变成__declspec(dllexport)主程序 include 这个头文件时自动变成__declspec(dllimport)。这样类的外部链接完全由宏处理不需要手写两份导出声明。// CExtDlg.cpp #include pch.h #include CExtDlg.h #include afxdialogex.h BEGIN_MESSAGE_MAP(CExtDlg, CDialogEx) ON_WM_CLOSE() END_MESSAGE_MAP() CExtDlg::CExtDlg(CWnd* pParent) : CDialogEx(IDD_EXT_DLG, pParent) { } BOOL CExtDlg::OnInitDialog() { CDialogEx::OnInitDialog(); // 这里初始化控件注意不要在 Create 之前加载字符串资源 return TRUE; } void CExtDlg::OnClose() { DestroyWindow(); } void CExtDlg::PostNcDestroy() { delete this; CDialogEx::PostNcDestroy(); }OnClose和PostNcDestroy与规则 DLL 里的做法一样保证非模态窗口自己释放。PostNcDestroy里先delete this再调基类顺序不能反如果先调基类this 指向的虚表已经被破坏delete 会直接翻车。4.3 主程序直接 new 类并创建非模态窗口在主程序工程设置里添加ExtDllDemo.lib的链接并把 ExtDllDemo 的包含目录加入。按钮事件代码#include CExtDlg.h void CMainFrame::OnOpenExtDlg() { CExtDlg* pDlg new CExtDlg(this); if (pDlg-Create(CExtDlg::IDD, this)) { pDlg-ShowWindow(SW_SHOW); } else { delete pDlg; AfxMessageBox(L扩展 DLL 对话框创建失败); } }这里真正做到了“直接 new 出非模态窗口”没有中间导出函数。CExtDlg::IDD是编译期枚举传入Create后MFC 会沿CDynLinkLibrary链查找资源找到扩展 DLL 里的对话框模板。因为类由 DLL 导出主程序可以直接访问它后续比如调用 public 方法设置控件内容也顺理成章。这里的生命周期同样交给PostNcDestroy所以主程序只负责 new 和ShowWindow不要手动 delete。4.4 两个例程的差异对比对比点规则 DLL 例程扩展 DLL 例程调用方非 MFC 也可必须是 MFC 程序导出内容C 函数MFC 类获得窗口方式函数返回 HWNDnew 类对象资源链靠 AFX_MANAGE_STATE 手动切靠 CDynLinkLibrary 自动找生命周期DLL 内部 new/deleteDLL 类内 PostNcDestroy delete this实际操作中如果扩展 DLL 的对话框 ID 恰好和主程序某个对话框 ID 相同资源查找仍可能命中的是主程序模板。兜底做法是在CreateWindow前用AfxSetResourceHandle切换到扩展 DLL 模块句柄创建后恢复这样能彻底绕开 ID 冲突。5. MFC DLL 封装与调用常见问题排查冲突、资源句柄和指针生命周期5.1 窗口一闪而过或资源 ID 找不到现象调用CreateModelessDlg后窗口瞬间消失或者调试输出直接报IDD_MODELESS_DLG找不到。原因规则 DLL 的导出函数体里漏了AFX_MANAGE_STATE(AfxGetStaticModuleState())或者扩展 DLL 的对话框 ID 和主程序已有 ID 冲突MFC 资源查找命中了主程序模板。解决规则 DLL 在入口函数体第一行补上AFX_MANAGE_STATE扩展 DLL 在创建前后用AfxSetResourceHandle切换资源模块句柄。排查时打开两边工程的Resource.h对比对话框 ID 是否有重复。5.2 加载 DLL 后主程序崩溃提示 mfc140u.dll 相关错误现象DLL 能加载但调用导出函数后进程直接崩调试器停在堆分配或CString构造附近。原因主程序和 DLL 一个用/MDd一个用/MD或者一个静态链接 MFC一个动态链接 MFC导致两边各持一份 CRT 堆。跨模块 new/delete、传递CString都会踩到 dll 冲突。解决在项目属性里把“MFC 的使用”统一为“在共享 DLL 中使用 MFC”并确认主程序和 DLL 的运行库都是“多线程调试 DLL (/MDd)”或“多线程 DLL (/MD)”。发布目标机器时优先装微软官方 VC 运行库不要一报错就下载 dll 修复工具很多“修复”会顺手把 mfc140u.dll 替换成不匹配的版本。5.3 非模态窗口关闭后再点一次菜单直接崩溃现象第一次打开关闭都正常第二次点击打开按钮CreateModelessDlg或new CExtDlg时崩溃。原因上一次关闭时对象已经通过PostNcDestroy删除外部还留着旧的 HWND。再次点击菜单时代码可能还在用这个 HWND 做父窗口或IsWindow判断悬空指针一用就崩。解决外部保存 HWND在收到窗口销毁通知时把 HWND 置空或者在 DLL 内部用一个静态 map 维护 HWND 到对象指针的映射关闭时自动清理。不要在PostNcDestroy之后还调用该对象的方法。5.4 链接期提示 unresolved external symbol现象扩展 DLL 例程中主程序编译通过但链接时找不到CExtDlg::CExtDlg、CExtDlg::Create这类符号。原因AFX_EXT_CLASS在 EXE 工程里没有变成dllimport。最常见的情况是 EXE 工程预处理器里也手动定义了_AFXEXT导致宏判断错误或者链接时没有添加扩展 DLL 的.lib。解决审查 EXE 工程的预处理器定义去掉_AFXEXT确认主程序链接器输入里加了ExtDllDemo.lib。用dumpbin /exports ExtDllDemo.dll可看到??0CExtDlg...符号确认 DLL 确实导出了类。5.5 对话框能创建但点击按钮没反应或控件内容空白现象窗口弹出来了标题栏也正常但对话框里的按钮点了没反应SetDlgItemText设置的文字显示为空。原因消息映射表和资源句柄切换不正确扩展 DLL 中控件变量跨模块绑定失败或 DLL 中的资源状态在OnInitDialog时已经切回了主程序。解决检查消息映射ON_WM_CLOSE是否在派生类中DoDataExchange里使用DDX_Control时必须在OnInitDialog执行前保证资源句柄属于 DLL。调试时在OnInitDialog里下断点看GetDlgItem返回是否为空。6. 收尾技巧用 dumpbin 验证导出给非模态窗口发消息的通用做法6.1 用 dumpbin 检查 DLL 导出表开发完两个例程先别急着跑。打开“x64 Native Tools Command Prompt for VS2019”执行dumpbin /exports RegDllDemo.dll dumpbin /exports ExtDllDemo.dll第一行能明显看到CreateModelessDlg这个无修饰函数名第二行可以看到一堆 C 修饰后的类符号。如果规则 DLL 里没看到CreateModelessDlg说明extern C丢了或被编译器优化掉回到代码检查。还可以用dumpbin /dependents看两个 DLL 依赖是否都是mfc140u.dll如果混入不同命名版本的 MFC DLL发行时就会冲突。6.2 给非模态窗口发自定义消息非模态窗口创建后返回的 HWND或CExtDlg*的GetSafeHwnd可以保存到主程序成员变量。需要通知 DLL 里的面板刷新数据时定义WM_APP 200#define WM_MY_UPDATE_DATA (WM_APP 200) ::PostMessage(hWndPanel, WM_MY_UPDATE_DATA, (WPARAM)nUser, (LPARAM)0);在CExtDlg消息映射里加ON_MESSAGE(WM_MY_UPDATE_DATA, OnUpdateData)即可。这里用PostMessage而不是SendMessage避免主程序等待 DLL 处理时因为窗口已销毁而卡死如果必须同步取返回值调用前先::IsWindow(hWndPanel)判断。6.3 主程序退出前的统一关闭我习惯在主程序ExitInstance里维护一个CArrayHWND把所有非模态窗口的 HWND 存进去退出时逐个::SendMessage(hWnd, WM_CLOSE, 0, 0)。这样能保证 DLL 里的PostNcDestroy有机会执行避免进程退到一半时 DLL 资源还没释放的诡异问题。见过不少项目不处理这一步平时运行都正常但系统托盘图标残留或 DLL 卸载失败往往就是非模态窗口没收干净。这些技巧是我从“DLL 封装例程”这条路上一步一步踩出来的规则 DLL 导出 C 接口最稳扩展 DLL 导出类最省事但两者都绕不开“谁销毁对象”和“资源在哪个模块”这两件事。希望帮到你。本文还有配套的精品资源点击获取