企业官网建设流程全解析

简介：这份源代码面向VC++初学者与Windows桌面开发入门者，围绕“引导用户一步步完成软件安装”这一典型场景，演示了多步骤安装向导界面的搭建过程。界面风格偏传统，未做过多Windows化定制，但流程清晰，便于理解向导页面的组织思路；源码中实际使用了TAB控件，展示了选项卡在对话框中的创建与切换方式，对熟悉MFC控件编程有参考价值。

压缩包共26个文件，以9个.h头文件、8个.cpp实现文件为主体，辅以.rc资源脚本、.ico图标、.avi动画、.dsp/.dsw工程文件与ReadMe.txt说明，整体仅48KB，解压后可直接用VC++打开工程编译调试。

目前已有213人学习。读者可据此获得一份可运行的向导框架，包含多页面切换逻辑、控件初始化与消息响应、安装进度动画调用及资源文件组织方式，适合作为课程设计或小工具发布界面的起点。

1. 从一份 VC 源码安装向导说起：它在 VS2019 上第一步就过不去

一份 VC 源码的安装向导，解压完双击工程文件直接编译，第一屏往往就是红字：无法打开包括文件 afxwin.h。这类「程序安装向导」的源码看着不起眼，本质是一个 MFC 对话框程序，外面套着一整套文件操作——建目录、复制文件、写注册表、建快捷方式。它逻辑不复杂，却极度挑环境：工具链、字符集、SDK 版本、UAC 权限，任何一项错位，都能让它在「复制文件」这一步静默失败，最后只给你一个空目录，连日志都不留。

如果你刚拿到这类 VC 源码，想把它编出来、改成自家项目的安装程序，下面这套从选环境到跑通验证的顺序我走过几遍，照着做能少返工。

2. 环境准备：VC++ 工具链与字符集怎么选才不返工

2.1 VC6、VS2010、VS2019 三套工具链的实际差别

打开源码目录先别急着双击，先看工程文件的后缀，它直接决定了你该装哪套工具。判断方式很直接：

我不建议为了老工程专门去装 VC6。原因不是怀旧不怀旧，而是 VC6 编出来的 exe 在现代系统上跑，一旦尝试写 Program Files 或 HKLM，会触发 UAC 的文件和注册表虚拟化——写操作被悄悄重定向到用户目录，程序自己以为成功了，你去目标路径一看什么都没有。这是最典型的黑匣子式故障，排查起来能耗掉半天。

真要用 VC6 的场合只有一种：源码里大量用了<fstream.h>、<iostream.h>这类老式头文件，或者靠 CString 到const char*的隐式转换过活，转换成本高于装旧 IDE。除此之外一律往上转，用 VS2019 的 v142 工具链，安全检查和调试能力都不是一个量级。

转换时要知道取舍：转换器只会改工程结构，不会改代码语义。字符集、预编译头、运行库这三项它基本按默认值填，而这三项恰恰是老 MFC 工程最容易翻车的地方，后面第 3 章会逐条处理。

2.2 工作负载勾选：少勾一个 MFC，后面全是 C1083

VS2019 的安装器默认装的是「使用 C++ 的桌面开发」，但 MFC 不在默认勾选里。装完打开工程，编译器第一句就是fatal error C1083: 无法打开包括文件: "afxwin.h"，很多人第一反应是去改包含路径，其实压根没装。

正确做法是在 Visual Studio Installer 里，选中「使用 C++ 的桌面开发」后点右侧「安装详细信息」，把这几个勾上：

• MSVC v142 - VS 2019 C++ x64/x86 生成工具
• Windows 10 SDK（选一个已安装在机器上的版本，别贪新）
• 适用于最新 v142 生成工具的 C++ MFC（x86 和 x64）
• 适用于最新 v142 生成工具的 C++ ATL（工程里用到 CComPtr 之类才需要）

装完想确认到底有没有装上，不用去翻目录，用安装器自带的 vswhere 探测一下最快：

"C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe" ^ -latest -products * ^ -requires Microsoft.VisualStudio.Component.VC.ATLMFC ^ -property installationPath

这段命令的逻辑是：vswhere.exe是 VS 安装器附带的独立探测工具，不依赖环境变量；-latest只取版本号最高的一个实例；-products *表示不限定 Community/Professional 版本；关键是-requires，它按组件 ID 过滤，这里传的是 MFC 组件 ID，只有真正装了 MFC 的实例才会被选中；-property installationPath让输出只剩一行路径。有路径输出说明 MFC 在位，输出为空就是没装，回去补勾。

顺带一提 SDK 版本的选择。老工程的项目属性里往往硬编码了WindowsTargetPlatformVersion，如果那台机器上没装对应版本的 SDK，MSBuild 会直接报找不到 Windows SDK。常见做法是把项目属性里的「Windows SDK 版本」改成「$(LatestTargetPlatformVersion)」，让它跟着当前机器走，而不是钉死某个 10.0.xxxxx。

2.3 解压位置与只读属性：中文路径、同步目录、杀软

工程放哪，听起来是玄学，实际影响很大。三条经验：

第一，路径里不要有中文和空格。MSBuild 对中文路径本身能处理，但老工程的 .rc 资源脚本、自定义生成步骤里写死的相对路径一旦带中文，就可能出现资源编译失败或者链接器找不到 .res 的情况，报错信息还特别含糊。我一般统一放到D:\work\setupwizard\这种纯 ASCII 路径下。

第二，别放在 OneDrive、坚果云这类同步目录里。同步客户端会在编译过程中锁住中间产物，表现为莫名其妙的LNK1104: 无法打开文件 xxx.obj，清理重建又能过，下次再犯。

第三，从压缩包解压出来的文件可能带只读属性，尤其是从只读介质拷过来的。解压后先跑一遍：

attrib -R /S /D *

-R是去掉只读属性，/S表示递归处理所有子目录，/D表示连目录本身也一起处理，不加/D的话目录属性不会变，后续生成中间文件仍可能失败。

还有一点容易被忽略：解压后先把历史构建产物清掉。老源码包里经常带着Debug/、Release/、*.ncb、*.opt、*.user这些目录和文件，它们记录的是上一位作者机器上的绝对路径，留着只会干扰判断。把Release、Debug、*.user、*.ncb、*.suo删干净，再开始动工程。

3. 打开工程与首次编译：从老工程文件到能跑的 exe

3.1 工程转换后必须手工核对的三项

用 VS2019 打开 .dsw 或 .vcproj 时，会弹一个「需要转换」的向导，一路下一步即可。转换完成后别急着按 F7，先打开「项目属性」，把这三项核对一遍，它们决定了后面一半的报错。

第一项是「配置属性 → 高级 → 字符集」。VC6 时代的 MFC 工程几乎都是多字节（MBCS），转换器有时会填成「未设置」，而 VS2019 的 MFC 库默认按 Unicode 组织。字符集和实际链接的 MFC 库不一致，症状是LNK2005: _WinMain@16 已经在 xxx 中定义或者一大堆_T相关的重定义。

第二项是「配置属性 → 常规 → MFC 的使用」。老工程可能压根没这个字段，转换后默认是「使用标准 Windows 库」，但源码里全是 CDialog、CWinApp，链接阶段必然一堆未解析符号。

第三项是「配置属性 → 链接器 → 系统 → 子系统」。安装向导是带界面的，必须是 Windows，如果被填成 Console，程序启动会先弹一个黑框。

字符集这一项怎么取舍，取决于你打算改多少代码。如果只是想把这份源码编出来跑通，把字符集改成「使用多字节字符集」是最省事的，一行代码不用动；如果是准备长期维护、后面还要加功能，那就老老实实全程走 Unicode，把源码里的char缓冲区、sprintf、strcpy逐个换成TCHAR、_stprintf_s、_tcscpy_s。短痛和长痛的区别，自己权衡。

3.2 MFC 链接方式与运行库：静态还是动态

安装向导这个程序有个特殊性：它要被拷到一台可能什么都没装的机器上运行。所以链接方式不能按普通桌面程序来选。

如果按默认的「在共享 DLL 中使用 MFC」，编出来的 exe 依赖mfc140u.dll和vcruntime140.dll，目标机没装 VC 运行库就直接报「缺少 DLL」。你可以让安装包顺带分发 vc_redist，但那就陷入了一个循环：安装程序本身需要先被安装。

所以我一般直接改成静态：项目属性里把「MFC 的使用」设为「在静态库中使用 MFC」，同时到「C/C++ → 代码生成 → 运行库」把「多线程 DLL (/MD)」改成「多线程 (/MT)」。代价是 exe 体积涨几 MB，换来的是单文件可分发。

命令行也能覆盖这两项，做自动化构建时很实用：

msbuild SetupWizard.sln /t:Rebuild /p:Configuration=Release /p:Platform=Win32 ^ /p:UseOfMfc=Static /p:CharacterSet=MultiByte

参数逐个说：/t:Rebuild表示先清理再全量构建，避免增量编译用到旧 obj；/p:Configuration=Release指定发布配置；/p:Platform=Win32指定 32 位平台，安装向导一般编 32 位兼容性更好；/p:UseOfMfc=Static是覆盖「MFC 的使用」，可选值有Static、Dynamic、false，写错大小写会直接报无效属性值；/p:CharacterSet=MultiByte等价于界面上的「使用多字节字符集」，另一个可选值是Unicode。

注意^是 cmd 里的续行符，在 PowerShell 里要换成反引号，别混用。

3.3 第一次全量编译：先看依赖，再看产物

用 IDE 编也行，但我更习惯先用命令行编一遍，因为报错信息完整、可复制、便于比对。开一个普通的 cmd 窗口（不要用 PowerShell 直接跑 vcvars），先初始化编译环境：

call "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars32.bat" cl /?

vcvars32.bat干的事是往当前会话里注入PATH、INCLUDE、LIB三个环境变量，分别指向编译器、头文件和库目录。vcvars32是 32 位，vcvars64是 64 位，vcvarsall.bat x86效果等同。如果cl /?能打印出版本信息，说明环境没问题；报「不是内部或外部命令」，基本就是路径写错或者装的是 Build Tools 而非完整 IDE（Build Tools 的路径在BuildTools目录下）。

编完之后，别只看「生成成功」四个字，用 dumpbin 看一眼真实依赖：

dumpbin /dependents Release\SetupWizard.exe

/dependents会列出 exe 导入的所有 DLL。如果列表里出现MFC140U.DLL、MFC140.DLL、VCRUNTIME140.DLL，说明静态化没生效，八成是某一项属性没改到，或者改的是 Debug 配置而编的是 Release。如果只剩KERNEL32.dll、USER32.dll、SHELL32.dll、ADVAPI32.dll这些系统 DLL，说明静态链接成功，这个 exe 拷到干净的 Windows 上就能双击。

第一次编译大概率不会一次过，链接错误集中在 MFC 和字符集上，这类问题在第 5 章有逐条对应。先把「能编出一个 exe」这件事拿下，再往下改配置。

4. 核心配置：安装路径、文件复制、注册表与资源内嵌

4.1 安装目录默认值：GetModuleFileName 的两个坑

安装向导启动第一件事是算默认安装路径。绝大多数源码是这么写的：GetModuleFileName拿到自身路径，截掉文件名得到安装源目录，再拼上C:\Program Files\xxx。这段代码有两个坑。

第一个坑是返回值。GetModuleFileName在缓冲区不够时返回的是缓冲区大小，而不是真实长度，路径被悄悄截断，后面拼出来的目录就是错的：

// 取安装程序自身所在目录，作为安装源的根目录 TCHAR szSelf[MAX_PATH] = { 0 }; DWORD dwRet = ::GetModuleFileName(NULL, szSelf, MAX_PATH); if (dwRet == 0 || dwRet == MAX_PATH) { // 返回 MAX_PATH 说明缓冲区不够，路径已被截断，不能继续用 AfxMessageBox(_T("取安装源路径失败，请把安装包放到更短的路径下")); return FALSE; } TCHAR* pSlash = _tcsrchr(szSelf, _T('\\')); if (pSlash != NULL) *pSlash = _T('\0'); // 截掉文件名，留下目录

逻辑说明：第一个参数传NULL表示取当前进程的 exe 路径；返回值必须同时判 0 和MAX_PATH，判 0 是失败，判MAX_PATH是截断；_tcsrchr从右往左找最后一个反斜杠，把它改成字符串结束符，剩下的就是目录。MAX_PATH是 260，如果安装包放在很深的目录里，这 260 个字符真不够用，所以我一般会把缓冲区开到MAX_PATH * 2并配合\\?\前缀处理。

第二个坑是默认安装目录别硬编码。C:\Program Files在中文系统、非系统盘、ARM 设备上都可能不成立：

// 取系统 Program Files 目录，不要硬编码 C:\Program Files TCHAR szProgFiles[MAX_PATH] = { 0 }; ::SHGetFolderPath(NULL, CSIDL_PROGRAM_FILES, NULL, SHGFP_TYPE_CURRENT, szProgFiles); CString strDefaultDir; strDefaultDir.Format(_T("%s\\MyApp"), szProgFiles);

CSIDL_PROGRAM_FILES是外壳常量，SHGFP_TYPE_CURRENT表示取当前实际路径而不是默认值。这里有个血泪经验：32 位安装程序在 64 位系统上跑，CSIDL_PROGRAM_FILES拿到的其实是C:\Program Files (x86)，因为 WOW64 会做文件系统重定向。如果你确实想把 64 位程序装进真正的Program Files，要么直接编 x64 版本，要么展开环境变量%ProgramW6432%：

TCHAR szBuf[MAX_PATH] = { 0 }; ::ExpandEnvironmentStrings(_T("%ProgramW6432%"), szBuf, MAX_PATH);

顺带一句：所有拼出来的路径在传给CreateProcess、ShellExecute之前都要加引号，否则C:\Program Files\My App\a.exe会被当成C:\Program.exe加参数。

4.2 目录复制：SHFileOperation 与自写递归怎么选

安装向导最核心的动作是把整棵目录树复制到目标位置。两条路，各有取舍。

第一条是用外壳 API，代码短、自带进度对话框、能正确处理长路径和权限：

// 把 srcDir 整个目录复制到 dstDir 下，全程不弹任何确认框 SHFILEOPSTRUCT fo = { 0 }; TCHAR szFrom[MAX_PATH * 2] = { 0 }; TCHAR szTo[MAX_PATH * 2] = { 0 }; _tcscpy_s(szFrom, MAX_PATH * 2 - 2, srcDir); _tcscpy_s(szTo, MAX_PATH * 2 - 2, dstDir); // 末尾天然留两个 '\0' fo.wFunc = FO_COPY; fo.pFrom = szFrom; fo.pTo = szTo; fo.fFlags = FOF_NOCONFIRMATION | FOF_NOERRORUI | FOF_SILENT | FOF_NOCONFIRMMKDIR; int nRet = ::SHFileOperation(&fo); if (nRet != 0 || fo.fAnyOperationsAborted) { // 失败处理，注意这里要把返回值转成错误信息给用户看 }

参数逐项说：FO_COPY是复制，FO_MOVE是移动，FO_DELETE时pTo必须为 NULL。pFrom和pTo必须是绝对路径，相对路径的行为没有明确定义。最容易翻车的是字符串结尾——pFrom必须以双\0结束，因为它是「字符串列表」，单\0的话函数会继续往后读栈上的垃圾数据，然后复制一堆你根本不知道哪来的文件到目标目录。所以我用_tcscpy_s时把长度上限传给MAX_PATH * 2 - 2，保证末尾至少空出两个字符。

fo.fFlags里，FOF_NOCONFIRMATION关掉所有「是否覆盖」的询问，FOF_NOERRORUI关掉系统错误弹窗，FOF_SILENT不显示进度条，FOF_NOCONFIRMMKDIR允许自动创建目标目录。返回值非 0 只表示「有操作没成功」，要不要当成整体失败，还要再看fAnyOperationsAborted。

第二条是自己递归，用FindFirstFile+CopyFile，好处是能精确控制跳过哪些文件、能自己算进度百分比、失败时知道具体是哪个文件：

// 递归复制目录，可在此处过滤掉不需要分发的文件 BOOL CopyDir(LPCTSTR src, LPCTSTR dst) { ::CreateDirectory(dst, NULL); // 目录已存在会失败，忽略即可 CString strPattern; strPattern.Format(_T("%s\\*.*"), src); WIN32_FIND_DATA fd = { 0 }; HANDLE hFind = ::FindFirstFile(strPattern, &fd); if (hFind == INVALID_HANDLE_VALUE) return FALSE; do { // 必须跳过 . 和 ..，否则会无限递归 if (_tcscmp(fd.cFileName, _T(".")) == 0 || _tcscmp(fd.cFileName, _T("..")) == 0) continue; // 部署包里的调试符号和日志不参与分发 if (_tcsstr(fd.cFileName, _T(".pdb")) != NULL) continue; CString strSrc, strDst; strSrc.Format(_T("%s\\%s"), src, fd.cFileName); strDst.Format(_T("%s\\%s"), dst, fd.cFileName); if (fd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY) CopyDir(strSrc, strDst); else ::CopyFile(strSrc, strDst, FALSE); // 第三个参数 FALSE = 覆盖已存在的文件 } while (::FindNextFile(hFind, &fd)); ::FindClose(hFind); return TRUE; }

CopyFile第三个参数bFailIfExists是我见过记反次数最多的一个：传TRUE是「目标存在就失败」，传FALSE才是「覆盖」。安装向导显然要覆盖，所以这里必须是FALSE。另外CreateDirectory在目录已存在时返回ERROR_ALREADY_EXISTS，这是正常情况，不用当错误处理。

我一般的选择是：文件数量少、不要求进度反馈就用SHFileOperation；需要在界面上显示「正在安装第 12/87 个文件」或者要跳过特定文件，就用自写递归。

4.3 注册表与快捷方式：写哪儿、怎么写

安装向导写完文件，通常还要做两件事：在卸载列表里留个条目，在桌面或开始菜单建快捷方式。

写卸载信息时，键路径是固定的，但 32 位程序在 64 位系统上会被 WOW64 重定向到WOW6432Node，结果就是「控制面板的卸载列表里看不到」：

// 写入卸载信息；KEY_WOW64_64KEY 阻止被重定向到 WOW6432Node HKEY hKey = NULL; LONG lRet = ::RegCreateKeyEx(HKEY_LOCAL_MACHINE, _T("SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\MyApp"), 0, NULL, 0, KEY_WRITE | KEY_WOW64_64KEY, NULL, &hKey, NULL); if (lRet == ERROR_SUCCESS) { const TCHAR* szName = _T("我的程序"); ::RegSetValueEx(hKey, _T("DisplayName"), 0, REG_SZ, (const BYTE*)szName, (DWORD)((_tcslen(szName) + 1) * sizeof(TCHAR))); ::RegCloseKey(hKey); }

sizeof这一行要注意：REG_SZ要求字节数，不是字符数，所以必须是「字符长度 + 1（结尾的\0）」乘以sizeof(TCHAR)。直接写sizeof(_T("我的程序"))在 Unicode 下虽然也对，但换成变量就错了，养成写全的习惯。

建快捷方式要走IShellLink，这是 COM 接口，必须先初始化：

// 创建桌面快捷方式，路径必须都是绝对路径 ::CoInitialize(NULL); IShellLink* psl = NULL; ::CoCreateInstance(CLSID_ShellLink, NULL, CLSCTX_INPROC_SERVER, IID_IShellLink, (void**)&psl); if (psl != NULL) { psl->SetPath(strTargetExe); // 目标 exe 的绝对路径 psl->SetWorkingDirectory(strInstallDir); // 工作目录，影响程序读相对路径配置 psl->SetDescription(_T("我的程序")); IPersistFile* ppf = NULL; psl->QueryInterface(IID_IPersistFile, (void**)&ppf); if (ppf != NULL) { ppf->Save(strLnkPath, TRUE); // TRUE = 记住路径，不弹「另存为」 ppf->Release(); } psl->Release(); } ::CoUninitialize();

SetPath和Save的路径都必须是绝对路径，相对路径在 Win10 之后基本都会被拒。CoInitialize每个线程只能调一次，MFC 程序一般放在CWinApp::InitInstance里，别忘了配对CoUninitialize。

4.4 资源内嵌：把要装的文件塞进 exe

单文件分发的常见做法是把待安装的文件打成压缩包，以RT_RCDATA资源的形式编进 exe。资源脚本里加一行：

IDR_PAYLOAD RCDATA "payload.zip"

运行时把它释放到临时目录，再解压复制：

// 从 RT_RCDATA 资源释放内嵌的安装包到临时目录 HRSRC hRes = ::FindResource(NULL, MAKEINTRESOURCE(IDR_PAYLOAD), RT_RCDATA); if (hRes == NULL) return FALSE; DWORD dwSize = ::SizeofResource(NULL, hRes); HGLOBAL hMem = ::LoadResource(NULL, hRes); void* pData = ::LockResource(hMem); CFile file; if (file.Open(strTempZip, CFile::modeCreate | CFile::modeWrite)) { file.Write(pData, dwSize); file.Close(); }

FindResource的第三个参数必须是RT_RCDATA而不是IDR_PAYLOAD的类型，很多示例写错这一项；LoadResource返回的句柄在现代 Windows 上不需要FreeResource，那是个空实现；LockResource拿到的指针在进程退出前一直有效，不用释放，但也不要去写它。

这个方案的边界要清楚：内嵌几十 MB 还行，再大就会拖慢 exe 启动——杀软每次双击都要完整扫一遍整个文件。超过这个量级，我更倾向于把 payload 放在 exe 旁边，用第 4.2 节的方式复制，安装包做成自解压或者直接给个文件夹。

5. 排查：编译过了却装不上的五个现场

5.1 现象：C1010，预编译头意外结束

报错原文是fatal error C1010: 在查找预编译头时遇到意外的文件结尾。原因有两个方向：一是工程设置了「使用预编译头」，但某个 .cpp 文件第一行没有#include "stdafx.h"；二是这个 .cpp 本身就是空的或者只有注释。转换过来的老工程里，后加的文件特别容易漏这一行。

解决分两种。如果这个文件确实需要参与预编译，就在文件最上面补上#include "stdafx.h"，位置必须在所有其他 include 之前。如果这个文件不需要，就在项目属性里选中这个文件，把「C/C++ → 预编译头 → 预编译头」单独设为「不使用预编译头」，注意是文件级设置，不要动整个项目。

5.2 现象：LNK2019 一堆 MFC 符号无法解析

报错里出现__imp_??0CDialog@@QAE@...这类修饰名，说明代码在调 MFC，但链接器没拿到 MFC 的库。原因通常是「MFC 的使用」这一项和实际字符集不匹配，或者转换后这一项压根是「使用标准 Windows 库」。

处置顺序是：先看项目属性「高级 → MFC 的使用」是不是设成了「在静态库中使用 MFC」；再看「常规 → 字符集」是不是和源码里的_T用法一致；最后把Release、Debug和中间目录x64/Win32整个删掉全量重建。增量编译残留的旧 obj 会让改了属性的构建看起来毫无变化，这一点很坑。

5.3 现象：装到一半闪退，没有任何提示

程序能编译、双击能起来，点「下一步」走到复制文件那一步，窗口直接消失。原因八成是 UAC：进程没有管理员权限，写Program Files或HKLM时被拒绝，而代码里对CopyFile、RegSetValueEx的返回值没做任何判断，异常抛出后没人接。

解决是在工程里加一个 manifest，声明需要的权限级别：

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> <security> <requestedPrivileges> <requestedExecutionLevel level="requireAdministrator" uiAccess="false" /> </requestedPrivileges> </security> </trustInfo> </assembly>

requireAdministrator表示启动时必须提权，用户会看到 UAC 弹窗；asInvoker是不提权，普通权限运行。装完效果是 exe 图标带个小盾牌。加完 manifest 记得重新编译，光改文件不重建是不生效的。

5.4 现象：目标机提示缺少 mfc140u.dll

在自己机器上跑得好好的，拷到另一台干净机器就报缺 DLL。原因就是第 3.2 节说的动态链接——你的 exe 依赖 VC 运行库，而目标机没装。用dumpbin /dependents一看便知。

解决有两条路：把 MFC 和运行库都改成静态（UseOfMfc=Static+/MT），或者随安装包一起分发 vc_redist。对安装向导这种「必须先于一切运行」的程序，静态是唯一稳妥的选择，因为分发运行库本身又需要一个安装器，逻辑上闭环不了。

5.5 现象：32 位安装程序在 64 位系统上装错位置

程序装完，去C:\Program Files找不到，翻半天发现在C:\Program Files (x86)里；卸载列表里也没有条目，但注册表编辑器里能在WOW6432Node下翻到。原因就是 WOW64 的文件系统和注册表重定向，32 位进程看到的Program Files和HKLM\SOFTWARE都是被重定向后的视图。

解决按需求选：如果产品本身就是 32 位，接受装进Program Files (x86)就好，只是注册表要加KEY_WOW64_64KEY，让卸载条目出现在 64 位视图里；如果产品必须是 64 位，那就直接加一个 x64 平台配置，用msbuild /p:Platform=x64编一版，问题从根上消失。最忌讳的是在一套安装逻辑里混着两种视图，那才真的没法维护。

6. 验证：跑一遍没有开发工具的机器才算装完

编译成功不等于装得上。我验证这类安装向导，固定在一台没装过任何开发工具、没装 VC 运行库的干净虚拟机上做，流程是死的一遍：

第一步，双击 exe，看 UAC 弹不弹。不弹说明 manifest 没生效，回到 5.3。弹了之后走完向导，中途故意在「选择安装目录」那一步改成一个带空格的路径（比如D:\My Tools\App），很多路径拼接的 bug 只在有空格时才暴露。

第二步，装完对文件数量：

dir /s /b "C:\Program Files\MyApp" | find /c /v ""

/s递归子目录，/b只输出路径不带摘要，find /c /v ""是统计行数的经典写法（/v ""匹配所有非空行，/c只输出计数）。拿这个数字和源目录的数字对比，少一个都算失败，尤其要看res、plugins这类子目录有没有被漏掉。

第三步，查注册表条目在不在正确视图里：

reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\MyApp" /s reg query "HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\MyApp" /s

两条都查，看条目落在哪一边，符不符合你的预期。然后打开「设置 → 应用」，确认卸载列表里能看到程序名和图标。

第四步，把程序从开始菜单启动一次，再手动删掉目标目录里的一个 dll，重启程序看它报不报错——这一步是验证你的安装完整性检查有没有真的在跑，而不是摆设。

第五步，走一遍卸载，然后回来看目录是不是空了、注册表项是不是清了、快捷方式是不是没了。安装向导最容易糊弄的就是卸载路径，写的时候顺手，验的时候全是残留。

从那以后我每次改完安装向导的复制逻辑或者路径拼接，都强制在一台全新的虚拟机上从零走一遍这五步，快照回滚，绝不省略。开发机上因为装满了各种运行库和 SDK，很多问题根本显不出来，等用户反馈「装了打不开」再去查，成本高十倍。希望这套顺序能帮到你，少走几段我走过的弯路。

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