简介面向需要制作 MSI 安装包的软件开发者、打包工程师与部署人员Advanced Installer 20.7.1 提供了图形化的 Windows Installer 编写环境能够生成符合 MS Windows 认证的安装程序并支持自定义欢迎界面与安装过程界面。资源包内含约 2000 个文件压缩后约 161MB文件构成以 png/jpg/ico 等图形素材、aip 工程文件、xsd/xml 配置模板为主另有少量 msi 示例包和 rtf/html 说明文档便于理解安装包结构并复用界面素材。目前已有 940 人学习/下载。通过这批资料可以快速掌握 Advanced Installer 的项目组织方式借鉴内置的多种界面模板和本地化配置直接修改 aip 工程即可生成符合 Windows 规范的 MSI 安装包丰富的图片、图标与 XAML 资源也为安装界面的视觉定制提供了现成素材。对于希望系统学习安装包制作或需要参考成熟打包方案的技术人员这是一份实用且完整的工具参考。1. 为什么要用 Advanced Installer 20.7.1 做软件打包从“发个 ZIP”到“正规安装包”做 Windows 软件分发最掉价也最坑的就是“发个压缩包让用户自己解压”。用户解压完不知道点哪个 exe杀毒软件把文件当可疑程序隔离卸载的时候连注册表和快捷方式都清不干净——这些问题所有做过交付的人都遇到过。Advanced Installer 是我拆过一遍后觉得最值得长期用的打包工具它解决的不只是“把 exe 包一层”而是把 VC 运行库合并、注册表写入、快捷方式管理、升级与卸载逻辑全部收进一个工程文件里单独发布了 20.7.1 这个稳定版本。适合谁用主要面向两类人一类是给客户做交付的 C/S 架构开发者另一类是把内部工具分发给非技术同事的运维。前者关心 MSI 的干净安装和卸载回滚后者关心双击下一步就完事、不用解释“环境变量怎么配”。Advanced Installer 的免费版覆盖了大约 90% 的普通软件打包需求支持创建 MSI 和 EXE 安装包、内置启动条件检查、支持安装后运行配置20.7.1 这个版本还完善了 MSIX 支持和更新功能。下面的所有操作我都基于 20.7.1 的免费版做演示完全够用。2. 用 Advanced Installer 20.7.1 创建第一个 MSI 安装包从新建工程到生成产物的完整流程2.1 工程类型怎么选MSI 还是 EXE别一上来就点错打开 Advanced Installer 20.7.1 后第一步不是直接拖文件而是面对一个工程类型选择界面。很多人在这就翻车了——误以为 EXE 工程比 MSI 更高级选了 EXE结果后面打包出来的东西既没法做组策略推送也没法用标准方式做卸载修复。实际上对于绝大多数 Windows 桌面应用优先选 MSI 工程理由很具体MSI 是 Windows Installer 的标准格式卸载信息会注册到“程序和功能”面板支持修复安装也支持通过 Active Directory 或 SCCM 推送。EXE 工程适合什么场景适合你需要在安装前跑一段自定义检测脚本、或者要对安装包做自解压和静默参数定制的场景。在 Advanced Installer 20.7.1 里新建工程时有六个模板MSI - 简单版、MSI - 专业版、EXE - 简单版、EXE - 专业版、MSIX 打包、Pure MSI。简单版和专业版的区别在于是否预置了更多功能页面对多数应用选 MSI 简单版就够。这里有个判断标准如果你的应用安装目录默认装在 Program Files 下且不需要安装时动态生成配置文件简单版够用需要安装时让用户输入序列号、或按用户类型勾选功能组件就选专业版。我一般默认选专业版省得后期要加功能时发现工程类型锁死还得重新迁移。2.2 把文件拖进工程目录结构决定了安装后的真实布局选择工程类型后进入主界面左侧是功能树中间是资源面板。添加程序文件的方法是在左侧树里展开“文件”节点右键点击“应用程序文件夹”选择“添加文件夹”然后把你的 exe、dll、配置文件全部拖进去。这一步有个关键点——安装包里的目录结构会和最终安装到用户机器上的结构完全一致所以如果你在开发环境里依赖相对路径读取配置那拖进去时就必须保持原来的目录层级。很多开发者的习惯是直接选中 Release 文件夹往里拖这个做法没问题但要注意把config、logs这类可写目录单独处理不要放进 Program Files 下的安装目录里后面权限会在正式环境出问题。文件添加完后点一下左侧“应用程序文件夹”能在右侧属性面板里调整文件和文件夹属性。这里建议勾选“始终安装”选项避免文件因为版本号相同被安装器跳过。另一个要在这一步处理的点是如果你的程序依赖 VC 运行库比如基于 MFC 或 Qt 编译出来的程序普通的文件拖入并不能解决目标机器缺运行库的问题。Advanced Installer 20.7.1 里要在“先决条件”节点里勾选对应项常见的是“Visual C 2015-2022 Redistributable (x64)”它会自动把运行库合并进安装包或设定为下载安装。两者区别后期我会说清楚。工程文件与安装内容的对应关系 Applications Folder对应安装目录默认 Program Files\{ProductName} ├── MyApp.exe - 主程序 ├── MyApp.dll - 动态库勾选“始终安装” └── config.ini - 配置文件建议移动到 Common AppData 或用户目录拖入文件只是第一步真正影响安装体验的是文件和目录的属性设置。在这个面板做三件事第一给主程序 exe 设置“始终安装”第二如果你有多个版本的 dll 需要共存关掉“相同版本跳过安装”的默认行为第三记录一下你放在应用程序文件夹里的总体积因为后面配置升级包时体积差会被用来判断是否需要执行整体替换。2.3 产品信息与版本号这里填错会直接导致升级失败左侧树切到“产品信息”节点这里的四个字段决定了安装包的身份标识产品名、版本号、制造商、产品代码。前面三个都好填版本号格式是主版本.次版本.修订号比如 1.0.0。最容易踩坑的是“产品代码”这一项——每次生成新安装包时如果你的程序版本是升级而不是全新安装产品代码要保持不变而“升级代码”可以变。Advanced Installer 20.7.1 在新建工程时会自动生成一个随机 GUID 作为产品代码你只要别手动乱改就行。但如果你用旧工程文件来制作升级包一定要检查这个 GUID 和上一次发布是否一致不一致会导致控制面板里出现两个卸载条目。这里有一个容易被忽略但非常实用的逻辑升级代码Upgrade Code是 Windows Installer 用来识别“同一个产品不同版本”的标识符。你的安装包从 1.0 升级到 1.1产品代码不变、升级代码不变安装器才能正确执行“覆盖安装”。如果产品代码变了安装器会认为这是两个完全不同的软件旧版本不会被卸载新版和老版的文件混在同一目录里各种诡异问题就来了。我用过很多打包工具这个点没搞清楚的团队不在少数往往要等用户报“装完新版本程序打不开”才发现是两个版本文件混在一起。字段作用升级时的规则产品名显示在控制面板里的名称保持一致版本号用于判断新旧版本递增产品代码标识唯一安装实例保持不变升级代码关联版本进行覆盖保持不变2.4 生成安装包Debug 与 Release 的差异、签名与输出路径配置左侧树里找到“构建”节点展开后能看到发布类型列表默认是“可本地安装”。双击它右侧弹出构建配置面板。在这个面板里你要设置的是输出目录和安装包文件名格式。我建议把输出文件名的格式设为{产品名}_{版本号}_x64这样你在交付多个版本时不会出现“最终版 1.0”这种文件名。构建配置里有一个选项叫“生成 MSI 时同时生成 EXE 引导程序”建议勾选。这个 EXE 不是另一个安装方式而是一个引导壳它会检查目标机器上的 Windows Installer 版本和 .NET Framework 版本不满足条件时先补环境再解包执行里面的 MSI。对于给非技术用户分发直接给 EXE 更省事静默安装参数也能透传。签名这一步我单独强调如果你的公司有代码签名证书在“安全”节点里导入 pfx 文件然后勾选“在构建时签名”。没签名的情况下安装包在 Win10/Win11 上会被 SmartScreen 拦截一次用户需要手动点“仍要运行”这直接拉低体验。没有证书的话建议至少做哈希校验文件后面也能给用户一个验证手段虽然不是真正的信任链。20.7.1 版本支持 SHA-256 签名相比旧版强制 SHA-1 是一个升级点。构建配置设置完成后点击顶部菜单栏的“构建”按钮Advanced Installer 开始编译安装包。完成后到输出目录看到生成的 .msi 和 .exe 文件这两个文件就是最终交付物。把 MSI 发给企业 IT 用户用于静默部署EXE 发给个人用户安装。3. 安装流程定制与参数配置从交互界面到静默安装的完整链路3.1 安装过程界面怎么定制对话框顺序与被隐藏的页面Advanced Installer 20.7.1 的免费版允许修改一部分安装界面文本但你能控制的不是 UI 设计而是对话流程的增删。在左侧树“安装程序界面”节点下能看到安装过程中会出现的一系列对话框页面欢迎页、信息页、许可协议页、安装类型页、目标文件夹页、就绪页、安装进度页、完成页。这里我做一个实用推荐面向企业内部分发时建议把“安装类型页”去掉因为绝大多数用户不需要选择“典型/自定义/完整”自定义安装只会在后续升级时带来“某些组件没装上”的工单。去掉方法是选中该页面右键选择“禁用”。目标文件夹页看情况保留如果应用不支持任意盘符安装比如连的是相对路径的本地数据库就固定安装路径此时禁用该页面并把安装路径写死到“产品信息 - 属性信息 - 安装路径”里。另一个关键配置是“完成页”的选项——这里可以设置安装完成后是否立即运行程序。我建议设置为“不运行”除非你的程序有首次启动引导配置要跑。原因很简单安装完自动弹出来的第一视觉如果出现的是程序主界面而不是用户预期的东西反而会增加困惑。推荐保留的安装页面顺序 欢迎页 - 许可协议页 - 就绪页 - 安装进度页 - 完成页 禁用安装类型页、目标文件夹页当安装路径固定时这个顺序能保证安装步骤最少用户操作最少出错概率最低。Advanced Installer 里保存了所有这些设置后CtrlS 保存工程文件.aip备份好这个文件后面做升级包直接基于它改版本号即可不要每次从零建工程。3.2 先决条件配置让安装包自动带上 VC 运行库和 .NET Framework前面提到过“先决条件”节点这里把参数一次说清楚。在左侧树里展开“先决条件”右侧会列出大量可勾选的组件包括 .NET Framework、VC Redistributable、DirectX、WebView2 等。每个组件有两种处理方式“从网络下载”和“从本地合并”。20.7.1 里默认是下载方式即安装时从微软官方源获取并安装好处是安装包体积小坏处是目标机器没外网时安装直接卡死。内网企业用户建议切换为“从本地合并”前提是你把对应的安装引导文件放到 Advanced Installer 指定的文件夹里。合并后安装包体积可能增加 20 MB 到 80 MB换来的是离线可装这个代价值得。选先决条件这个环节必须克制。很多人的习惯是看到运行库就全勾上实际上会造成安装时间翻倍。以我的经验大多数 VC 应用只需要一个vc_redist.x64.exe用 .NET 开发的程序则只需要对应的 .NET Runtime 或 Desktop Runtime。判断标准很简单在你干净的 Windows 测试虚拟机上装一次运行你的程序报什么缺什么就勾什么不预判需求。3.3 注册表与快捷方式安装逻辑中最容易被忽视的两个部分打包工具最核心的价值不只是把文件拷过去还在于把软件运行的“周边环境”建好。注册表这部分Advanced Installer 的“注册表”节点里你可以预定义安装时写入的键值。我在实际项目中遇到的一个典型需求是程序需要写HKEY_LOCAL_MACHINE\SOFTWARE\MyCompany\MyApp下的数据库连接字符串或者需要在注册表里登记一个版本号供外部脚本查询。在注册表节点里操作方式和 regedit 一致右键新建键、新建值支持字符串和 DWORD 类型。注意 x64 程序要写在SOFTWARE\WOW6432Node下还是标准路径下取决于目标程序是 32 位还是 64 位这个区分错了注册表读不到。快捷方式不是简单地把桌面快捷方式和开始菜单快捷方式建好而是要考虑卸载时的清理。你需要选中主程序的 exe 文件右键选择“创建快捷方式”这样创建的快捷方式和文件是绑定关系卸载时自动识别删除如果手动去模拟创建卸载后桌面上会遗留坏掉的快捷方式。如果你的程序是 64 位版本要为shellexecute参数设置工作目录部分程序双击快捷方式找不到配置文件就是因为启动时的当前目录不对。在快捷方式属性里把“开始位置”填成主程序所在目录这个问题直接解决。3.4 静默安装与常用命令行参数给运维兄弟留一条路Advanced Installer 生成的 MSI 安装包天然支持 Windows Installer 的标准命令行参数这个能力不需要额外配置。测试静默安装时在命令行里输入下面这段msiexec /i MyApp_1.0.0_x64.msi /qn /norestart参数说明/i表示安装/qn表示完全静默不显示任何 UI/norestart表示安装完成后不自动重启。如果 MSI 里包含先决条件并且配置为“从本地合并”静默安装会一次性处理完所有内容如果配置为“从网络下载”静默模式下仍会弹出下载提示因为网络下载需要用户确认所以在企业环境里必须先做本地合并。卸载同样走命令行msiexec /x MyApp_1.0.0_x64.msi /qn如果要给某些需要指定安装路径的场景设置参数在构建配置里启用“公开属性”支持就能通过命令行传INSTALLDIR属性msiexec /i MyApp_1.0.0_x64.msi INSTALLDIRD:\MyApp /qn这个功能必须在 Advanced Installer 的“属性信息”里把INSTALLDIR注册为公开属性否则 MSI 会忽略命令行传入的路径值命令行属性直接失效。这是一个非常典型的配置坑后面我会放在避坑清单里再提一次。4. 避坑指南四个最常见的 Advanced Installer 翻车现场、原因与补救4.1 安装包双击没反应日志全在事件查看器里现象生成好的 MSI 在 Windows 10 企业版上双击之后没有任何界面弹出进程列表里 msiexec 闪一下就消失。原因通常有两个一是目标机器上 Windows Installer 服务被组策略禁用二是安装包启动了提升权限提示当前账号权限不够UAC 默认策略下直接被忽略。解决先确认 msiexec 服务存在再检查事件查看器里的安装日志。我的习惯是第一时间用带日志的方式重跑安装命令把日志写到本地文件再逐行排查。从事件查看器定位到 MSI 的MsiInstaller事件报错代码能直接指示问题方向。注意免费版不提供可视化日志分析器只能靠 Windows 系统日志这一点要提前想清楚别现场抓瞎。4.2 升级安装后桌面出现两个快捷方式现象用户从 1.0 升级到 1.1 后桌面没有出现新版快捷方式反而出现两个名字只差一点点旧版快捷方式。原因1.1 版本打包时修改了产品代码或升级代码Windows Installer 没有把它识别为“同一产品版本升级”而是当成两个独立软件分别安装了各自的快捷方式。解决回到 1.1 工程文件核对“产品信息”中的产品代码与 1.0 保持一致重新构建发布。在那之后我形成了强制习惯每次为老工程做新版本第一步先打开工程文件确认产品代码再改版本号和文件内容不再临时新建一个工程来碰运气。4.3 静默安装时 INSTALLDIR 属性被忽略现象用命令行传INSTALLDIRD:\MyApp执行静默安装装完发现程序还是装到了默认的 Program Files 目录。原因MSI 默认只允许二分之一的属性从命令行传入属性必须是“公开属性”即属性名全大写且出现在Property表里。解决Advanced Installer 里打开“属性信息”点击属性列表右上角的“编辑”找到INSTALLDIR这一行勾选“公开”列然后重新构建。另一个办法是直接传APPDIR因为安装包默认把安装目录的公开属性名定为APPDIR这是 Advanced Installer 的默认行为用APPDIR传参大概率可以直接生效。我遇到一次后用回APPDIR参数之后所有工程统一用这个不再依赖自动检测逻辑省事省得再踩坑。4.4 64 位程序在 32 位系统上直接安装失败现象安装包在特殊环境如某些低配测试机上安装报错提示不是有效的 Win32 应用程序安装终止。原因目标系统是 32 位 Windows而安装包中没有任何引导逻辑判断系统架构也没有禁用安装或替换为 32 位版本。解决在 Advanced Installer“启动条件”里添加一条“操作系统类型”检测规则设置为“64 位操作系统”并在“不满足条件时显示的消息”里写上“当前系统为 32 位无法安装本软件”。如果你同时维护 32 位和 64 位两个版本更好的方案不是在安装阶段拒绝而是生成两个独立的安装包分别分发。这条规则在构建配置里是“系统架构”每次新建工程我都会先确认这个条件避免后续安装到一半才报错回滚麻烦得多。5. 命令行打包与高级构建配置把 Advanced Installer 20.7.1 接入持续集成流程5.1 命令行编译工具 aic.exe 的基本用法与参数说明Advanced Installer 20.7.1 自带命令行工具aic.exe路径通常在安装目录的bin\x86子文件夹下。它的作用是让你摆脱手动点击“构建”按钮通过脚本完成打包流程。这在需要每日构建或频繁发版时很有价值人肉点按钮永远不会比脚本构建更稳定尤其当你有多个版本的工程文件要分别打包时。用法很简单C:\Program Files (x86)\Caphyon\Advanced Installer 20.7.1\bin\x86\aic.exe /build MyApp.aip/build后会直接按照工程文件里最后一次保存的构建配置生成安装包。aic.exe在没有安装完整 Advanced Installer 的环境中不可用它依赖注册的 COM 组件和许可证状态。所以无论你用 Jenkins 还是 GitLab CI构建机都必须完整安装 Advanced Installer并在首次启动时完成许可证登录。这一步常常被忽略是 CI 接入过程中最常见的断点。5.2 构建前自动更新版本号利用构建事件执行 PowerShell 脚本如果你不想每次都手工在工程文件里改版本号20.7.1 支持“构建”节点下的“外部工具”和“事件”配置。在“构建”节点的“事件”页面中可以配置构建开始前执行一段命令行脚本。我在这里做的是构建前运行一个 PowerShell 脚本读取工程文件里的版本号并做增量更新然后重新写入.aip文件。一个可参考的脚本结构如下# 自动将 1.0.0 递增为 1.0.1 的示例脚本供 Advanced Installer 构建事件调用 $path C:\Build\MyApp.aip $content Get-Content $path -Raw # 匹配类似 Version1.0.0/Version 的节点并递增修订号 $content $content -replace (Version)(\d\.\d\.)(\d)(/Version), { $prefix $_.Groups[1].Value $middle $_.Groups[2].Value $rev [int]$_.Groups[3].Value 1 $suffix $_.Groups[4].Value $prefix$middle$rev$suffix } Set-Content $path -Value $content这段脚本做的事是按正则匹配替换.aip文件中的版本号。(\d\.\d\.)匹配前两位数字加句点(\d)匹配当前修订号替换时加一。运行后工程文件版本号变化随后触发的构建命令会直接产出新版本的安装包。注意脚本执行时.aip文件不能被 Advanced Installer GUI 打开着否则文件被锁定写入失败会是预期之外的报错。这是唯一的注意点其他没有坑。使用该方案的逻辑是发布版本由 CI 构建次数驱动避免手工修改版本号造成的漏改或重复。大批量使用时你也可以把版本号来源改成一个独立文本文件让构建脚本从文本读取并填入而不是每次改工程文件后期更灵活不至于版本冲突。5.3 构建产物自动复制到发布目录后续步骤直接接上传流程打完包之后把产物复制到共享目录或 FTP还有一个更直接的思路在 Advanced Installer 的构建配置中指定输出目录并配合同一脚本把 MSI 和 EXE 复制到最终发布目录。一个完整构建脚本段落大致如下# 编译并复制安装包到发布共享目录 $AI_BIN\aic.exe /build MyApp.aip $version (Select-String -Path MyApp.aip -Pattern Version.*/Version).Matches[0].Value $dest \\build-server\releases\MyApp_$version New-Item -ItemType Directory -Path $dest -Force Copy-Item Output\*.msi $dest Copy-Item Output\*.exe $dest这段脚本的要点是$version从工程文件里重新提取一次保证目录名和实际包内的版本号一致。Copy-Item会把所有安装包复制过去。使用文件服务器作为发布目录的好处是后续测试团队可以直接从这个目录获取版本不需要让运维手动拷贝分发。如果你用的是 CI 内置的产物存档功能这一步可以省略但仍然建议至少把安装包统一命名方便后续追溯。这个环节的唯一禁忌是重复构建时覆盖旧安装包生产环境说不清哪个版本在用。所以我在复制命令之前会先建带版本号的子目录避免覆盖。6. 安装包质量验证的实用技巧虚拟机快照、日志对比与卸载干净度检查6.1 用虚拟机维护一个“已验证环境”不要用你自己的工作机测试安装包我坚持的验证方法是维护两台虚拟机一台是干净的 Win10 21H2 x64另一台是干净 Server 2019 x64。每台机器上只安装最基础的运行库和出厂补丁不做任何额外环境配置。验证打包结果前先给虚拟机拍一个快照然后在此快照基础上测试安装。测试内容有三项安装成功后检查“程序和功能”里是否有你要的条目安装目录下文件数量是否和打包源一致并手动打开程序确认功能正常。测试完成回滚快照再测下一个版本安装包。这样做有两个好处一是保证每次验证的环境一致不会因为目标机器残留旧版本软件而污染测试结果二是快速定位问题时排除环境因素干扰。不使用工作机直接测安装包因为开发机上装了 VS、各种 SDK 和运行库缺什么依赖都会因为系统里已有环境而被隐藏测不出真实用户的环境问题。6.2 通过 MSI 日志对比找到安装失败真实原因不要靠猜当安装失败时用日志定位比读事件查看器高效得多。手动安装时加上日志参数msiexec /i MyApp_1.0.0_x64.msi /l*v install_log.txt/l*v表示输出详细日志install_log.txt是日志文件路径。用文本编辑器打开日志后搜索Return value 3这个关键字这是安装失败的通用标志。再从它的上下文往上翻几百行找到MainEngineThread is returning之前的最后一行错误描述。常见错误是Cannot find a file说明文件缺失The installer has insufficient privileges说明权限不足。对比正常安装日志和失败日志差异只集中在报错位置附近的几十行这种对比能快速定位是权限问题还是文件缺失不再靠直觉猜。建议对每次失败都保留日志下次再遇到类似报错时直接找规律效率高很多。6.3 卸载干净度检查卸载后是否残留注册表和目录很多人验证安装包只测“装上能不能用”忽略了卸载后系统是否被污染。我会在 VirtualBox 快照环境里安装完再卸载然后检查三处注册表HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall下是否还有该产品的条目安装目录是否还残留文件开始菜单快捷方式是否还被留下。如果卸载不干净用户重装时遇到旧配置文件残留会导致奇怪问题这种问题最难排查。要解决卸载残留需要回到 Advanced Installer 工程文件检查是否设置了“删除安装目录”选项。具体的做法是在“文件”节点里右键你的应用程序文件夹属性面板中勾选“卸载时移除整个文件夹”。这一步很容易漏掉尤其在简单版工程里默认识别的移除范围只有你安装时新建的文件如果程序运行后在安装目录下生成了缓存文件卸载后它会被留下。注意config和logs目录不建议勾选删除因为卸载软件不应该删掉用户数据和配置信息但主程序目录要清理干净。这个取舍做完之后再做卸载验证才敢把安装包放出去。从那以后我每次打完安装包都强制在虚拟机里走一遍完整流程装、开、卸、查注册表、查残留目录所有验证过了才往发布目录放。这套流程虽然半天时间搭好虚拟机但换来的是发布后用户环境零报错希望这一整套从建工程到验证的流程帮到你也帮你少走几次我走过的弯路。本文还有配套的精品资源点击获取