简介Advanced Installer 20.7.1 是一款面向软件开发者与打包工程师的 Windows 安装包制作工具提供直观友好的图形用户界面可生成符合 MS Windows 认证的 MSI 安装文件并支持自定义欢迎页、安装流程、界面语言等交互环节无论是小型工具还是大型商业软件都能借助其可视化向导快速构建标准部署包。压缩包共包含2000个文件整体约161.36MB主要文件类型包括 aip 工程文件、png/jpg 图像素材、ico 图标、xsd/xml 配置定义以及少量 msi/msm 安装包示例其中大量 aip 文件是已经配置好的打包方案图片与图标素材可直接用于界面美化配置类文件则帮助理解组件依赖与注册表写入规则。目前已有941人学习/下载资源内容丰富适合需要发布商业软件、制作规范化安装程序的开发与运维人员学习参考和二次开发通过研究内置工程可快速掌握 Advanced Installer 的高级用法与部署逻辑。1. Advanced Installer 20.7.1一个打包老手为什么还在用它做 Windows 软件分发的工程师多半被安装包折磨过文件拷贝路径写错、注册表残留导致升级失败、静默安装参数对不上最后被用户一句“装不上”打回原型。Advanced Installer 20.7.1 是一款老牌 Windows 安装包制作工具它把 MSI、EXE、App-V 这些格式的打包过程从“手写 XML 配置”拉回到了可视化操作同时保留了足够深的自定义空间。这篇笔记不聊宣传语只讲我怎么用它把一套带服务、驱动、多组件依赖的桌面客户端从零打成可交付的安装包以及那些文档里没写明、只有实际打包才会撞上的坑。适合谁看如果你正在 Windows 平台发布商业软件或内部工具需要同时支持交互安装、静默部署和自动升级而且项目里不止一个 exe——那这工具值得评估。下面每步操作基于 20.7.1 版本界面老版本菜单名略有差异但核心逻辑一致。2. 选型Advanced Installer 凭什么替代 Inno Setup 和 WiX2.1 三种打包工具的适用边界别指望一把梭先说结论没有万能打包工具只有合适当前项目的方案。Inno Setup 胜在轻量和脚本灵活几千行 Pascal 脚本能实现自定义安装界面和逻辑但它在 MSI 支持上先天不足。WiX 是纯 XML 方案组件规则、升级码、注册表操作都靠手写维护成本随着功能数量非线性上涨。Advanced Installer 走的中间路线用图形界面管理文件和注册表用对话框编辑器控制 UI需要深入时又有自定义操作和 PowerShell 脚本接口。我之前在金融客户端项目里用过 WiX——那个项目有 30 多个文件、4 个服务、2 个驱动WiX 的 XML 文件到了后期每次修改都要全局搜索依赖关系失误率很高。后来换到 Advanced Installer文件拖拽进去自动生成组件服务的安装和卸载参数直接填表单不用手写 ServiceInstall/ServiceControl 的 XML 节点。2.2 许可证模式与成本评估Advanced Installer 是商业软件分免费版Limited、专业版和 Architect 版。免费版能打包 MSI/EXE但功能受限——不能配置自定义操作、不能做驱动安装、没有命令行编译。如果要自动化打包流程至少要专业版。20.7.1 这个版本我做过的项目里主要用了它的高 DPI 感知配置和自定义对话框字体设置这俩功能不是新东西但解决实际问题之前用旧版打包的程序在 4K 屏上安装界面模糊用户以为是软件坏了。评估许可证时看两点一是团队里同时编辑项目的人数二是是否需要运行时的安装框架。如果只是一个人维护安装包配置专业版够用如果需要给不同客户定制 UI 和许可逻辑Architect 版才显价值。我的建议是先从专业版起步跑通主流程后再决定要不要升。3. 最小可复现路径从空项目到可运行的 MSI3.1 创建项目先定架构再拖文件打开 Advanced Installer 20.7.1欢迎界面选择“MSI - 专业版项目”。MSI 所以是首选是因为它支持增量升级、管理权限卸载、以及通过组策略推送——这些在政企客户环境里几乎是硬性要求。创建后先做三件事再拖文件1. 设置 Product Details - Product Name填写显示给用户的完整名称 - Version这是升级依据每次发布必须递增 - Upgrade Code保持同一产品生命周期内不变 - Manufacturer默认用于注册表路径 HKLM\Software\企业名\产品名 2. Organization / Support 选项卡里填公司名和官网这个会写进 ARP添加/删除程序的属性表别留空否则卸载时显示成未知发布者。 3. 在 Media 页面把 Compression 设为 High输出格式选 x86 或 x64。关键参数是 Upgrade Code同一个产品不管安装多少个版本这个 GUID 必须一致否则升级时旧版本不会被识别为同一个产品就会出现“装两个版本在库里”的脏状态。Product Code 则可以每次构建都换推荐启用项目的自动递增功能。3.2 Files and Folders目录结构决定卸载是否干净左侧面板选“Files and Folders”把应用目录拖进 APPLICATIONFOLDER 虚拟目录它默认解析成“Program Files文件夹\产品名”。注意一个容易被忽略的点不要直接在 Application Folder 下挂注册表文件或图标——图标文件单独放一个子目录或放在 SYSTEMFOLDER 下避免资源占用锁问题Application Folder │ App.exe │ Core.dll │ config.ini ├── Plugins │ ├── PluginA.dll │ └── PluginB.dll └── Resources ├── icon.ico └── banner.png这个结构会在安装时原样落到目标机器的 Application Folder 里。放好后右键每个文件检查属性面板里的“组件”Component归属。Advanced Installer 默认每个文件自成一个组件组件是 Windows Installer 的最小逻辑单位组件之间不能共享文件——如果你两个组件引用了同一个 dllMSI 验证会报错安装时提示“文件存在于另一个组件”。3.3 配置快捷方式和安装后动作左侧面板选“Shortcuts”新建“Desktop Shortcut”和“Start Menu Shortcut”。目标指向 Application Folder 中的 App.exe工作目录必须留空用默认它自动取目标文件所在目录不要把“在单独内存空间运行”勾上——那只对旧版 16 位程序有效。需要“安装后立即运行安装程序”的在“Install Parameters”面板中勾选“Install after installation”更可控的方式是用“Predefined Actions”里的“Launch Application”动作指定可执行文件和参数。我一般用后者因为它支持设置“运行起始时间”能精确控制发生在注册表写入完成后而不是之前。3.4 编译输出第一遍就出成品工具栏点 Build - Build MSI 输出目录为 项目目录\Media\MyApplication\ 默认生成 .msi 和 .exe 两个文件 .msi 用于组策略推送.exe 是自解压包编译失败时最常见错误是“ICE 94”或“ICE 38”。ICE 38 表示组件的目标目录未定义为组件所属目录多半是你把文件拖进了 Application Folder 的子目录但该子目录没有创建独立组件ICE 94 则表示快捷方式的目标未在同一组件下。遇到这两个回到 Files and Folders右键目录选择“Create Component”、“Assign to existing Component”。编译通过后拿一台干净 VM 或云主机装一遍不要在自己的开发机上验证——开发机上往往已经装了运行库和依赖装不出来的问题测不出来。4. 把 MSI 的“可维护性”吃透版本、升级与回滚4.1 升级策略区分补丁、小版本和大版本Windows Installer 的升级分三类小更新Minor Update、小修复Small Update、主要升级Major Upgrade。Advanced Installer 的“Upgrades”菜单里也有对应选项。我常用“Major Upgrade”做全量替代因为它相当于卸载旧版再装新版能确保二进制文件、注册表项、服务全部按新版本重建。操作路径Upgrades 页面 1. 点击 Create Major Upgrade 2. 指定升级代码Upgrade Code指向上一版本 3. 决定是否保留旧版本的可选组件用户自定义安装时装的选件 4. 高级设置里选 Remove older versions / 或 Keep current version一般选 Remove这里的核心坑是“移除旧版本”的时机。默认行为是安装新版本时先卸载旧版本如果你的旧服务正在运行卸载的时候会杀掉服务——如果没有预设好服务停止顺序数据库文件可能没来得及写完就被杀导致数据损坏。解决方案是在“Services”面板中对每个服务设置“Start/Stop on Install/Uninstall”的精确序列让旧服务在卸载前正常停止而不是任其被强杀。4.2 注册表和配置转移升级时别丢用户数据升级时最忌讳的是一刀切清空配置。用 Advanced Installer 的“Upgrades”面板“Files Removal”选项卡可以精确控制哪些文件在升级时删除、哪些保留。我的做法是配置文件config.ini 和用户数据目录从安装文件列表里单列不勾选“Remove on uninstall”而是用自定义操作里的“Set Property”和“Execute Custom Action”在安装起始阶段把 config.ini 拷贝到备份路径安装完成后再拷贝回来。具体配置 Upgrades Remove files: - 删除文件模式*.* - 排除文件config.ini、*.db、userdata\*这个思路避免一个血泪教训我曾有一版升级把用户本地缓存的数据库当普通文件删掉了事后被投诉数据丢失。从那以后所有涉及用户数据的路径一律走“先备份再删除”的流程。4.3 服务、驱动和文件关联三个高压区逐个处理服务安装在其他打包工具里是痛点在 Advanced Installer 里是表单操作。在“Services”面板新建服务填服务名称、显示名称、可执行路径关键是“Startup Type”和“Account”两个参数自动启动的服务选“Automatic”“Account”选“LocalSystem”能避免复杂的账户权限问题但如果服务需要访问网络共享或映射磁盘必须换成指定域账号并测试。驱动安装更麻烦驱动没有标准 MSI 组件支持需要用到“Driver Package”选项卡加载 .inf 文件选择“文持 x64 和 x86”并勾选“Include driver in MSI”。这里最容易翻车的是驱动签名——测试模式下装的驱动没问题但生产机器强制签名验证安装会失败或蓝屏。打包之前一定确认驱动是否经过 WHQL 或至少是微软签名。文件关联在“File Associations”面板配置扩展名、描述、图标、默认打开命令。参数注意要带引号不然路径带空格就崩默认命令”C:\Program Files\MyApp\App.exe” “%1” 不要写成C:\Program Files\MyApp\App.exe %15. 打包避坑清单20.7.1 实战里最常见的 5 个问题5.1 升级后旧版本仍在“添加删除程序”列表里现象用户执行新版本安装包装完后控制面板里出现两个相同产品名版本号不同的条目。原因Upgrade Code 没匹配上或 Update Mode 设成了“不同产品”。解决在 Upgrades 页面确认“Upgrade Code”和上一个版本完全一致含大小写和花括号。批量分发时可在安装参数里加“REINSTALLMODEamus”强制刷新已安装组件。5.2 “Error 1001: Fail to initialize MSI”现象安装程序提示 1001 错误安装立即回滚。原因大多是自定义操作里的 PowerShell 脚本执行时间过长或安全策略禁止 PowerShell 脚本。解决自定义操作改为“延迟执行deferred”模式或以“系统账户”身份运行并且不要用 PowerShell 直接访问网络路径。更稳的做法是改成批处理内联调用 PowerShell 时先 Set-ExecutionPolicy Bypass -Scope Process。5.3 64 位机器上文件被装到了“Program Files (x86)”现象明明是 x64 程序安装路径却是 Program Files (x86)。原因项目默认模板是 x86 架构MSI 的属性表里没有设置“msidbProperties”为 64 位。解决在“Install Parameters”中选择“x64 或 64-bit”目标架构并把“Program Files 文件夹”属性手动重定向为“Program Files64”。检查这个的快捷方法是查看 MSI 属性表里的“VersionNT64”和“ProgramFilesFolder”值。5.4 卸载时总提示“安装源不存在”现象用户卸载软件时弹窗说“请插入安装源磁盘”。原因安装包改过版本号但缓存路径Windows Installer Cache没同步这类问题常见于 base MSI 找了自己的源文件找不到。解决在“Media”页面中把“Cache Installation on the Machine”勾选为“Always Cache”同时不要随意降低版本号回退。卸载时 MSI 需要原始 MSI 文件做回滚回缓存后它就能从本地找而非网络。5.5 静默安装参数 u/i 失效现象命令 msiexec /i myapp.msi /quiet 执行完但桌面没有快捷方式重启后服务也未启动。原因配置的是“交互式 UI”里的自定义操作静默模式下没有对应的“安静安装”操作作为替代。解决在每个自定义操作的“有条件执行”里加上“Not Installed”和“Quiet 模式”处理——具体在高级设置里勾选“Skip this action if installing silently”然后单独配置一个静默分支用于写注册表和创建快捷方式。X 检查和验证msiexec /i myapp.msi /qn /l*v install.log日志里搜“Return value 3”表示操作失败看到“Return value 1”才算成功。6. 自动化打包把 Advanced Installer 塞进 CI/CD 流水线6.1 命令行编译IDE 之外的真相依赖界面打包成熟后下一步是把构建过程交给流水线。Advanced Installer 自带命令行工具 AdvancedInstaller.com它可以在不打开 IDE 的情况下从工程文件编译 MSI。常用命令示例Windows 环境下C:\Program Files (x86)\Caphyon\Advanced Installer 20.7.1\bin\x64\AdvancedInstaller.com ^ /build C:\build\MyProject.aip ^ /buildname x64 Release ^ -out C:\output\MyApp.msi逻辑说明/build指定项目文件路径/buildname指定要编译的构建方案对应 IDE 里的 Build Configuration-out指定输出路径不指定时默认输出到项目目录。返回码 0 表示构建成功非 0 返回值按错误级别输出到 stderr——流水线里一定要检查退出码不要只看日志里有没有“success”。6.2 集成到 Jenkins / GitLab Runner 的脚本骨架echo off set AIP_TOOLC:\Program Files (x86)\Caphyon\Advanced Installer 20.7.1\bin\x64\AdvancedInstaller.com set PROJC:\build\MyProject.aip set OUTC:\artifacts\MyApp-%VERSION%.msi % AIP_TOOL% /build %PROJ% /buildname Release -out %OUT% if errorlevel 1 ( echo Build failed with errorlevel %errorlevel% exit /b 1 ) rem 产物签名 signtool sign /fd SHA256 /a %OUT% exit /b 0参数说明VERSION是流水线里传入的环境变量建议和项目文件里的版本号做一致性校验。签名这一步不能省从 2023 年以后微软对未签名 MSI 的 SmartScreen 拦截明显加强企业客户内部也会有安全扫描。签名证书最好用 EV 证书扩展验证普通 OV 证书也能签名但信任度低一层。6.3 自动生成 Release Notes 与默认安装参数我的习惯是在构建前用 PowerShell 脚本从 Git 标签生成版本号同时生成一个安装参数文件$version git describe --tags --abbrev0 (Get-Content MyProject.aip.template) | ForEach-Object { $_ -replace __VERSION__, $version } | Set-Content MyProject.aip逻辑说明项目文件本质是 XML/二进制混合格式做简单的字符串替换来更新版本号可行前提是模板文件保持结构稳定。如果你在 IDE 里调整了界面布局导致文件结构变化模板替换可能会失败——建议用 Advanced Installer 自带的“命令行构建参数”功能传版本号而不是替换文件文本。命令行传版本号的方式是AdvancedInstaller.com /setversion %VERSION% %PROJ%这条命令修改项目文件里的版本号再构建干净且不容易破坏结构。用它替代文本替换是更稳的实践。6.4 最后的教训版本号管理不是小事我见过最严重的翻车事故是版本号被 CI 进程改错导致所有用户的自动升级检查认为“已是最新版本”而拒收补丁。后来我养成一个习惯每次构建开始前先解析出预期的版本号再调用/getversion参数读取项目里的旧版本两者对比确认无误后才编译。AdvancedInstaller.com /getversion %PROJ%这个命令会把当前项目内版本号打印到 stdout——把它和流水线的期望值做字符串比对哪怕脚本写挫一点也比不检查强。如果你在团队里一定要把版本号规则写进构建脚本注释里否则下个接手的人一定会踩同一个坑。以上是 Advanced Installer 20.7.1 从选型、打包、升级到自动化集成的完整路径。中间绕不开的坑基本都在这里了希望帮到你。本文还有配套的精品资源点击获取