企业官网建设流程全解析

简介：面向具备C++基础、正在使用VS2019开发Windows桌面程序的MFC学习者与工程人员，这份资料围绕MFC常规动态链接库与扩展动态链接库的封装、导出及非模态调用展开，着重解决接口声明、模块加载卸载、调用端对接和链接配置等常见问题，适合课程设计、项目复现与旧工程维护时参考。压缩包共224个文件，约328.67MB，内含h/cpp源码、dll/lib/def导出库与导入库文件、sln/vcxproj工程配置、rc/res界面资源，以及pdb、obj、tlog等调试和构建中间产物，目录中保留较完整的编译痕迹，便于对照排查链接与运行时错误。资源已有1039人学习。其价值在于同时给出常规库与扩展库两类封装例程及配套调用端，读者可据此理解AFX_EXT_CLASS导出、静态链接与动态链接差异、AfxLoadLibrary/AfxFreeLibrary及GetProcAddress的调用方式，对导出宏、模块切换与资源复用也有涉及，可借助现有工程结构较快搭建自己的MFC DLL封装与调用框架。

1. 一个非模态窗口卡住的下午：这套 VS2019 MFC DLL 例程能省掉什么

前阵子改一个老工控上位机，主界面是 MFC 对话框，客户要把参数配置窗拆成独立模块单独更新。翻完代码，最后落地的方案就是这套 VS2019 MFC DLL：主程序只留一个按钮，窗口逻辑塞进共享 MFC 的常规 DLL，弹出来是非模态的，用户能一边开着配置窗一边看实时曲线。它提供的是两份能照着抄的骨架——一份常规库、一份扩展库，分别给出非模态调用的完整打开与关闭链路；并非 Hello World。适合刚接手 vc++ 老项目、被 DLL 导出名和资源串台折磨过的 C++ 开发者。

2. 工程结构拆解：常规库、扩展库、规则库三者在 VS2019 里的真实边界

DLL 本身并不复杂；真正麻烦的是选错类型之后返工。这套例程把三种形态放在一个解决方案里，指的就是让你先看清楚边界再动手。很多人第一次建 MFC DLL 工程，看到向导里三个选项随手点第一个，结果后面想导出 C++ 类才发现导出不了，整个工程推倒重来。

2.1 向导里那三个选项到底差在哪

VS2019 新建项目搜「MFC 动态链接库」，弹出的向导上有三行选项，中文界面大致是「共享 MFC DLL 的规则 DLL」「带静态链接 MFC 的规则 DLL」「MFC 扩展 DLL」。标题里说的「常规库」「规则库」，其实是同一个东西的两种叫法，都是 Regular DLL，只是向导的中文翻译在不同版本里来回变过。

真正的区别在导出能力和 MFC 运行时的链接方式上：

关键差别在于：扩展库导出的类可以继承 CDialogEx、CFrameWnd 这些 MFC 基类，宿主拿到就能直接 new；常规库不行，因为常规库和宿主之间没有共享的 MFC 模块状态，直接把 MFC 类跨模块传过去，虚表、资源句柄全是对不上的，运行起来就是随机崩溃。

提示：只要宿主是 MFC 程序、又被要求「DLL 里弹窗口」，优先选扩展库；如果宿主可能是个纯 Win32 或者 C# 壳子，那只能走常规库，窗口封装成 C 函数导出。

2.2 例程的目录与关键文件

这套例程的解决方案结构大致是这样，我在梳理时按职责重新排了一下：

MfcDllDemo/ ├─ MfcDllDemo.sln ├─ MfcRegular/ # 常规库：共享 MFC DLL 的规则 DLL │ ├─ MfcRegular.vcxproj │ ├─ pch.h / pch.cpp # 预编译头，MFC 工程必备 │ ├─ MfcRegular.h/.cpp # DllMain + CWinApp 派生类 theApp │ ├─ MfcRegularApi.h/.cpp # 对外导出接口，只有这一层暴露给宿主 │ ├─ ModelessDlg.h/.cpp # 非模态窗口本体 │ ├─ MfcRegular.def # 导出名钉死，防 x86 修饰 │ └─ MfcRegular.rc # IDD_MODELESS_DLG 在这里 ├─ MfcExt/ # 扩展库 │ ├─ MfcExt.vcxproj │ ├─ ExtDll.cpp # DllMain + AFX_EXTENSION_MODULE │ ├─ ExtDlg.h/.cpp # AFX_EXT_CLASS 导出对话框类 │ └─ MfcExt.rc ├─ StaticRuleLib/ # 静态链接 MFC 的常规库，对比用 └─ HostApp/ # MFC 宿主对话框程序 ├─ HostAppDlg.h/.cpp └─ HostApp.rc

值得单独说一句的是MfcRegularApi.h。例程把「DLL 内部实现」和「对外契约」分成了两个头文件，宿主工程的包含路径里只放 Api 那个。这个习惯很值得抄，后面改内部类、换窗口实现，宿主一行都不用动。

2.3 在 VS2019 里把解决方案搭起来

从零建一遍，顺序别搞反，先建库再建宿主。库工程建好之后，属性页里有几项必须一次改对，改错了后面全是玄学问题：

1. 平台统一成 x64（或者统一 x86，不能一个 x64 一个 x86）。
2. 属性 → 高级 → 字符集，全部选「使用 Unicode 字符集」。
3. 属性 → C/C++ → 代码生成 → 运行库，共享 MFC 的工程选「多线程调试 DLL (/MDd)」和「多线程 DLL (/MD)」，静态的选 /MTd 和 /MT。
4. 属性 → 常规 → 在共享 DLL 中使用 MFC，这里选「使用 MFC 的动态链接库」，预处理器里会自动带上_AFXDLL。
5. 把宿主工程的「引用」指向两个库工程，或者干脆用#pragma comment(lib, ...)显式挂。

导出名这一块，例程多给了一个.def文件。原因很简单：x86 平台上__declspec(dllexport)导出的extern "C"函数会被修饰成_MfrShowModeless@4这种带下划线和参数长度的名字，宿主用GetProcAddress("MfrShowModeless")会直接拿到空指针。

; MfcRegular.def —— 把导出名钉死，宿主按名字取函数才不会翻车 LIBRARY MfcRegular EXPORTS MfrShowModeless MfrCloseModeless MfrGetDlgCount

.def里列过的函数不用再加__declspec(dllexport)，加了也不冲突。x64 下本来就没有名字修饰，所以这个文件在 x64 配置里属于「用了更稳、不用也活」的保险。

3. 常规库核心实现：从 CWinApp 到导出函数的完整调用链

常规库这一层是整个方案里最容易出错的地方。它虽然也是个 DLL，但只要用了共享 MFC，就一定有且只有一个 CWinApp 派生对象，MFC 的初始化、资源查找、消息泵全都挂在这个对象和它的模块状态上。

3.1 导出层：只暴露 C 接口，把 MFC 关在门里

对外头文件的作用是给宿主一个干净的契约，里面不能出现任何 MFC 类型，连CString都别露。宿主可能是个纯 Win32 程序，也可能是个用别的编译器编译的老代码，一旦头文件里带了afxwin.h，它就编不过了。

// MfcRegularApi.h —— 宿主只包含这一个头文件 #pragma once #include <windows.h> #ifdef MFCREGULAR_EXPORTS #define MFR_API __declspec(dllexport) #else #define MFR_API __declspec(dllimport) #endif // extern "C" 关掉 C++ 名字修饰；参数和返回值全部用 Win32 原生类型 extern "C" { MFR_API BOOL MfrShowModeless(HWND hParent); // 打开非模态窗口 MFR_API void MfrCloseModeless(); // 主动关闭，宿主退出前必须调 MFR_API int MfrGetDlgCount(); // 当前存活窗口数，调试用 }

MFCREGULAR_EXPORTS这个宏在库工程的 C/C++ → 预处理器里定义，宿主工程不定义，于是同一个头文件在两边分别展开成导出和导入。这是 Windows DLL 最常见的一套写法，比维护两个头文件省事得多。

参数用HWND而不是CWnd*，是有意为之：CWnd*是 MFC 对象指针，跨模块传等于把本模块的虚表地址交给别人，MFC 内部状态一切换就废了。传窗口句柄，DLL 内部自己CWnd::FromHandle转一下，边界干净。

3.2 一个能复用的非模态对话框类

非模态窗口类和模态的写法差别不大，唯一必须重写的是销毁时机。模态的DoModal是个阻塞函数，返回时窗口已经析构；非模态的Create立刻返回，窗口活得比函数调用长，所以「谁 new 的谁 delete」这条规矩得靠PostNcDestroy来兑现。

// ModelessDlg.h #pragma once #include "afxdialogex.h" #include "resource.h" class CModelessDlg : public CDialogEx { DECLARE_DYNAMIC(CModelessDlg) public: explicit CModelessDlg(CWnd* pParent = nullptr); enum { IDD = IDD_MODELESS_DLG }; protected: virtual void DoDataExchange(CDataExchange* pDX); // 非模态窗口唯一安全的自删除时机：窗口句柄已销毁、对象还活着 virtual void PostNcDestroy(); DECLARE_MESSAGE_MAP() public: afx_msg void OnBnClickedApply(); };

// ModelessDlg.cpp #include "pch.h" #include "ModelessDlg.h" // 导出层持有这个指针，用来判重和主动关闭 extern CModelessDlg* g_pModelessDlg; IMPLEMENT_DYNAMIC(CModelessDlg, CDialogEx) CModelessDlg::CModelessDlg(CWnd* pParent) : CDialogEx(IDD_MODELESS_DLG, pParent) { } void CModelessDlg::DoDataExchange(CDataExchange* pDX) { CDialogEx::DoDataExchange(pDX); } void CModelessDlg::PostNcDestroy() { CDialogEx::PostNcDestroy(); g_pModelessDlg = nullptr; // 先让导出层知道指针失效 delete this; // 再自杀，顺序反了就是野指针 } BEGIN_MESSAGE_MAP(CModelessDlg, CDialogEx) ON_BN_CLICKED(IDC_BTN_APPLY, &CModelessDlg::OnBnClickedApply) END_MESSAGE_MAP()

PostNcDestroy是 MFC 留给非模态窗口的标准钩子，DestroyWindow走完OnDestroy、窗口句柄失效之后才会调到这里。在这儿delete this是安全的，写在OnDestroy里就不一定了——那时候窗口还没彻底销毁，后面 MFC 内部还会碰这个对象。

g_pModelessDlg用extern声明在头文件外面，是为了让导出层和窗口类共享同一个指针。工程小的时候这么写没问题；工程大了我一般会收进一个单例或者管理器类里，避免全局变量到处飞。

3.3 非模态调用的完整链路与关闭

导出函数里第一行必须是AFX_MANAGE_STATE，这是常规库的保命符。它做的事是把当前线程的 MFC 模块状态从宿主切到本 DLL，切完之后AfxGetResourceHandle()才指向本 DLL 的资源段，LoadString、AfxMessageBox、对话框模板才找得到。

// MfcRegularApi.cpp —— 常规库的导出实现 #include "pch.h" #include "MfcRegularApi.h" #include "ModelessDlg.h" CModelessDlg* g_pModelessDlg = nullptr; extern "C" MFR_API BOOL MfrShowModeless(HWND hParent) { // 切模块状态：资源、字符串、对话框模板才会从本 DLL 里找 AFX_MANAGE_STATE(AfxGetStaticModuleState()); if (g_pModelessDlg != nullptr && ::IsWindow(g_pModelessDlg->GetSafeHwnd())) { // 已经开着就前置，不重复创建 g_pModelessDlg->ShowWindow(SW_SHOW); g_pModelessDlg->SetForegroundWindow(); return TRUE; } CWnd* pParent = CWnd::FromHandle(hParent); g_pModelessDlg = new CModelessDlg(pParent); // 注意这里用 Create 而不是 DoModal，非模态不能阻塞宿主消息循环 if (!g_pModelessDlg->Create(IDD_MODELESS_DLG, pParent)) { delete g_pModelessDlg; g_pModelessDlg = nullptr; return FALSE; } g_pModelessDlg->ShowWindow(SW_SHOW); return TRUE; } extern "C" MFR_API void MfrCloseModeless() { AFX_MANAGE_STATE(AfxGetStaticModuleState()); if (g_pModelessDlg != nullptr && ::IsWindow(g_pModelessDlg->GetSafeHwnd())) { // DestroyWindow 会走 OnDestroy -> PostNcDestroy，指针在那边清 g_pModelessDlg->DestroyWindow(); } g_pModelessDlg = nullptr; } extern "C" MFR_API int MfrGetDlgCount() { return (g_pModelessDlg != nullptr) ? 1 : 0; }

几个参数值得单独说清楚。hParent传宿主的窗口句柄，非模态窗口挂在它下面，宿主最小化时子窗口跟着走，关闭宿主时系统也会连带销毁。Create的第二个参数也是父窗口，和构造函数里传的是同一个，两处必须一致，只传一处会出现窗口位置飘到屏幕左上角的情况。

MfrCloseModeless这个函数看着多余，其实是必需的。宿主退出时如果 DLL 窗口还活着，进程卸载 DLL 的那一刻窗口对象就成了野的，退出瞬间直接访问违例。正确顺序是宿主OnDestroy里先调MfrCloseModeless()，再AfxFreeLibrary。

注意：AFX_MANAGE_STATE只对当前作用域有效，它在栈上放了个对象，函数返回时自动还原。所以每个导出函数开头都得写一遍，不能只在其中一个里写。

4. 扩展库与非模态窗口：AFX_EXT_CLASS 类导出和宿主消息循环怎么配合

常规库那一套是「函数进出」，扩展库这一套是「对象进出」。两者最大的不同在于：扩展库和宿主共享同一份 MFC 运行时，类可以直接跨模块 new，但前提是 DLL 初始化时把自己的模块信息挂进 MFC 的资源链，否则宿主永远找不到它里面的对话框模板。

4.1 DllMain 里的 CDynLinkLibrary 是资源链的关键

MFC 扩展库的 DllMain 不能随便写，模板代码里那几行是有讲究的，删掉任何一句都会出问题。

// ExtDll.cpp —— 扩展库入口，MFC 资源链在这里建立 #include "pch.h" #include "ExtDlg.h" // 保存本扩展 DLL 的模块信息，AFX_EXTENSION_MODULE 由 MFC 定义 static AFX_EXTENSION_MODULE g_extDll = { nullptr, nullptr }; extern "C" int APIENTRY DllMain(HINSTANCE hInstance, DWORD dwReason, LPVOID /*lpReserved*/) { if (dwReason == DLL_PROCESS_ATTACH) { // 初始化扩展模块，失败必须返回 0，否则宿主后面全在错误状态里跑 if (!AfxInitExtensionModule(g_extDll, hInstance)) return 0; // 挂到 MFC 的 CDynLinkLibrary 链上，本 DLL 的资源从此可被搜索到 new CDynLinkLibrary(g_extDll); } else if (dwReason == DLL_PROCESS_DETACH) { // 宿主进程退出时调用，释放扩展模块占用的资源 AfxTermExtensionModule(g_extDll); } return 1; }

new CDynLinkLibrary(g_extDll)这一行分配出去的对象是故意不释放的，它由 MFC 在模块卸载时统一回收。它的作用是把当前 DLL 的HINSTANCE和资源段挂进一条链表，之后 MFC 在AfxFindResourceHandle时就会顺着链表把每个扩展库都问一遍。少了这行，宿主调Create(IDD_EXT_DLG)会直接返回失败，GetLastError什么也不给你，这就是最典型的黑匣子现场。

4.2 用 AFX_EXT_CLASS 导出一个对话框类

扩展库导出类只要在类声明前加AFX_EXT_CLASS，它展开后是__declspec(dllexport)或dllimport，靠_AFXEXT宏自动切换。类里的成员函数、消息映射全部跟着导出，宿主拿到的是完整的类型信息。

// ExtDlg.h —— 扩展库导出的非模态对话框类 #pragma once #include "afxdialogex.h" #include "resource.h" class AFX_EXT_CLASS CExtDlg : public CDialogEx { DECLARE_DYNAMIC(CExtDlg) public: explicit CExtDlg(CWnd* pParent = nullptr); enum { IDD = IDD_EXT_DLG }; protected: virtual void DoDataExchange(CDataExchange* pDX); virtual void PostNcDestroy(); DECLARE_MESSAGE_MAP() };

宿主要做的只有三件事：包含头文件、挂上.lib、new出来调Create。不需要GetProcAddress，也不需要写.def，因为链接器在编译期就把符号对上了。

// HostAppDlg.cpp —— 宿主侧创建扩展库窗口 #include "pch.h" #include "HostAppDlg.h" #include "ExtDlg.h" // 扩展库头文件 #pragma comment(lib, "MfcExt.lib") // 导入库，Debug 配置下路径要对 void CHostAppDlg::OnBnClickedExtDlg() { if (m_pExtDlg == nullptr) { // 对象由宿主 new 出来，析构也由宿主负责，跨模块分配风险小 m_pExtDlg = new CExtDlg(this); if (!m_pExtDlg->Create(CExtDlg::IDD, this)) { delete m_pExtDlg; m_pExtDlg = nullptr; AfxMessageBox(_T("扩展库窗口创建失败，先查资源链")); return; } } m_pExtDlg->ShowWindow(SW_SHOW); m_pExtDlg->SetForegroundWindow(); }

CExtDlg::IDD这个枚举在宿主侧是可见的，因为整个类都导出了。但要注意IDD_EXT_DLG这个资源 ID 的数值在宿主工程里必须不存在，否则宿主会优先拿自己的资源去创建，出来的界面对不上，控件全是空的。

4.3 两条消息循环如何协作

非模态窗口能被拖动、能响应按钮，靠的是宿主线程的消息泵。扩展库窗口Create在宿主 UI 线程上，ShowWindow之后它就是一个普通子窗口，WM_COMMAND、WM_PAINT全部由宿主的CWinApp::Run分发。这也是为什么非模态窗口不能在工作线程里创建——那个线程没有消息泵，窗口画出来就是一块白板，点什么都没反应。

如果 DLL 里确实需要独立线程，常见做法是在那个线程里自己跑一个PeekMessage/DispatchMessage循环，线程创建窗口、销毁窗口、退出循环三者成对出现，不要指望主线程帮你兜底。这条路坑不少，我一般会直接劝退，能挪到主线程就挪。

宿主退出时的顺序也需要固定下来：先m_pExtDlg->DestroyWindow()，再让主窗口销毁。如果宿主用AfxLoadLibrary显式加载扩展库，还要在退出前AfxFreeLibrary；扩展库全程静态链接进宿主的话，这一步可以省。

5. 踩坑排查：DLL 加载失败、资源串台、非模态窗口崩溃的五种现场

这些坑基本集中在两个阶段：加载期和运行期。区分开之后排查会快很多，因为加载期的问题几乎都是配置问题，运行期的问题几乎都是模块状态和生命周期问题。

5.1 加载期：加载不上、创建失败

现象一：LoadLibrary一直返回 NULL，GetLastError是 126 或者 193。

原因基本只有两类：126 是「找不到模块」，通常是 DLL 不在宿主工作目录、PATH、或者没放进输出目录；193 是「不是有效的 Win32 应用程序」，说白了就是位数不匹配，宿主 x64、DLL x86，或者反过来。也有一部分是 MFC 运行时缺失，DLL 依赖的mfc140u.dll在目标机器上没装。

解决办法很直接：把四个工程（两个库、宿主、静态库）的平台配置逐个检查一遍，配置管理器里全部对齐；再用dumpbin /dependents MfcRegular.dll看一眼依赖，缺什么补什么。发布到干净机器上时，把 VC++ 运行库一起打进去，别指望用户自己装。

现象二：LoadLibrary成功了，但GetProcAddress返回 NULL。

原因通常是导出名被修饰了，或者你查的名字大小写、前后缀对不上。x86 下__declspec(dllexport)会把extern "C"函数修饰成_MfrShowModeless@4。

解决方式是加.def文件把名字钉死，或者用dumpbin /exports MfcRegular.dll把实际导出名打出来，宿主照着写。查的时候别用GetProcAddress排除法一个个试，浪费时间。

5.2 运行期：资源、断言与销毁时机

现象三：非模态窗口弹出来了，但界面是英文的，或者控件全空、提示文字乱码。

原因是常规库的导出函数里漏了AFX_MANAGE_STATE(AfxGetStaticModuleState())，当前线程的模块状态还停在宿主那边，AfxGetResourceHandle()指向宿主的资源段，于是对话框模板按 ID 去宿主里找，找到个同 ID 的别的资源，就出现了「窗口能显示但内容不对」的诡异现象。

解决办法是给每个导出函数第一行都补上AFX_MANAGE_STATE，包括那些看起来「只返回个数」的小函数。补完之后还会乱，就检查.rc文件的编码和#include "afxres.rc"有没有漏。

现象四：窗口关掉之后再点按钮，程序直接崩在g_pModelessDlg->ShowWindow上。

原因有两个层面。一是PostNcDestroy里delete this之后没把g_pModelessDlg置空，指针成了野的；二是置空和 delete 的顺序反了，先 delete 再判断IsWindow，等于拿一个已释放对象的成员去试。

解决方式是严格按「置空 → delete this」的顺序走，并且在导出函数里判重的时候用g_pModelessDlg != nullptr && ::IsWindow(...)两个条件一起判断。

现象五：宿主退出时偶发崩溃，崩在AfxTermExtensionModule或者 DLL 已经卸载之后的某个回调里。

原因是宿主先卸载了 DLL，窗口对象还在，进程退出前系统给窗口发WM_DESTROY，消息映射的代码已经在卸载的模块里，跳过去就是访问违例。

解决办法是在宿主的OnDestroy里，先主动关掉所有 DLL 窗口，再走AfxFreeLibrary。这个顺序我踩过一次之后，就把它写进了工程模板里，所有类似项目一律照抄。

6. 二次开发：把两份例程收敛成一个可插拔的窗口插件接口

例程跑通之后，下一步基本都会走到「我有五个窗口都要这么搞」的局面。这时候再把导出函数一个个往上加就不合适了，得抽一层接口出来。做法很简单：宿主和所有 DLL 共用同一个纯虚接口头文件，每个 DLL 只导出一个工厂函数。

// IPlugin.h —— 宿主与所有插件 DLL 共享，零 MFC 依赖 struct IPlugin { virtual ~IPlugin() {} virtual const wchar_t* Name() const = 0; // 显示在菜单上的名字 virtual BOOL Show(HWND hParent) = 0; // 非模态打开，不做阻塞 virtual void Close() = 0; // 宿主退出前必须调 }; typedef IPlugin* (*PFN_CREATE_PLUGIN)(); // 每个 DLL 只导出这一个符号，固定叫 CreatePlugin

宿主侧用LoadLibrary+GetProcAddress("CreatePlugin")遍历插件目录，建一个vector<IPlugin*>管理起来，删除时统一调Close。改造过程中最容易漏的是三件事：

验证的时候别只跑 Debug。切 Release 跑一遍，两个平台各跑一遍，再用dumpbin /dependents确认没有混进静态 MFC 的库。我以前图省事只测 Debug，结果 Release 下/MD和/MT混着链，上线当天崩在客户机器上，那次的教训是：配置管理器里四个工程的运行库设置必须一起看，不能只看当前活动的那一个。从那以后我每加一个库工程，都强制把「平台 + 字符集 + 运行库 + MFC 链接方式」四项过一遍再开始写代码。希望帮到你。

本文还有配套的精品资源，点击获取