简介Advanced Installer 22.5 打包 Windows 安装包资源面向需要制作专业安装程序的软件开发者与运维人员帮助将应用程序、依赖文件及安装配置整合为可安装、可卸载、易管理的 Windows 安装包。压缩包共约 2000 个文件整体约 229.56MB以 png、jpg、ico 等界面与图标素材aip、aitemplate 等工程模板xsd、xml、json 等配置与架构文件以及 msi、msm、exe 等安装产物为主另含多语言 ail 本地化文件与 rtf、html 说明文档覆盖打包流程所需的资源与模板。已有 1432 人学习下载。借助其中的工程模板、多语言资源与配置示例读者可快速熟悉产品信息定义、文件与注册表管理、快捷方式创建、GUI 与静默安装模式设置及安装条件校验等关键环节并参考测试与编译思路提升安装包制作效率与发布质量。1. 从一份“装不上”的安装包说起Advanced Installer 22.5 到底解决什么问题给客户交付 Windows 桌面软件最尴尬的不是功能有 bug而是对方双击安装包弹出一句“此应用无法在你的电脑上运行”或者装到一半报缺少VCRUNTIME140.dll再或者装完了发现配置文件写到了C:\Program Files下导致普通用户改不了。这类问题我在交付现场遇到过不止一次血泪经验就是功能做得再好安装包翻车一样会被打回。Advanced Installer 22.5 就是用来把这类交付问题一次性收口的工具——它是一款 Windows 平台的安装包制作工具能生成 MSI 和 EXE 两种主流格式支持先决条件检测、自定义操作、升级与卸载逻辑、数字签名等一整套企业级交付能力。它适合谁适合需要把 .NET、C、Python 打包成桌面程序交付给客户或内部运维的工程师也适合做 Windows 系统集成、需要批量分发软件的技术人员。这一章先把“它是什么、能解决什么”讲清楚后面几章再落到具体怎么配、参数怎么设、坑在哪。2. 用 Advanced Installer 22.5 建一个能装能卸的最小工程2.1 先想清楚MSI 还是 EXE32 位还是 64 位打开 Advanced Installer 22.5 新建工程时第一个要做的决策不是界面怎么配而是安装包类型。很多人上来就选 EXE觉得双击方便结果后面要做静默部署、组策略分发时才发现 MSI 才是企业环境里的硬通货。我的建议是面向个人用户、需要自定义引导界面的选 EXE面向企业 IT 批量推送、需要走域策略的选 MSI。Advanced Installer 支持在同一个工程里同时输出两种格式所以不必二选一但主工程类型决定了你后面能用的功能面板。第二个决策是架构。现在还在交付纯 32 位程序的场景已经很少了但如果你打包的是老旧的 C 组件或者依赖某个只有 x86 版本的第三方库就必须在工程里明确指定。Advanced Installer 的“Product Details”页里可以设置目标平台选 x64 后安装路径默认会落到Program Files而不是Program Files (x86)这个细节如果配错程序运行时找不到依赖表现就是启动闪退。第三个决策是安装范围。Per-machine 安装需要管理员权限装到Program Files所有用户可用Per-user 安装不需要提权装到用户目录但只对当前用户生效。企业交付一般选 Per-machine个人工具类可以选 Per-user 降低安装门槛。这三个决策定下来工程骨架就稳了。2.2 把文件、快捷方式和注册表项配到位新建工程后核心操作集中在“Files and Folders”和“Shortcuts”两个面板。把编译好的程序目录拖进“Application Folder”Advanced Installer 会自动建立文件树。这里有个容易忽略的点如果你打包的是 .NET 程序依赖的 DLL 要一起拖进去不要指望目标机器上一定有对应的运行时。下面是一段用 Advanced Installer 命令行工具AdvancedInstaller.com构建工程的示例适合把打包流程接进 CI# 用命令行加载工程并构建适合 Jenkins/GitLab CI 调用 # /build 指定工程文件输出路径在工程里已配置 C:\Program Files (x86)\Caphyon\Advanced Installer 22.5\bin\x86\AdvancedInstaller.com ^ /build D:\projects\MyApp\MyApp.aip # 如果只想重新生成 MSI 不弹界面加 /quiet C:\Program Files (x86)\Caphyon\Advanced Installer 22.5\bin\x86\AdvancedInstaller.com ^ /build D:\projects\MyApp\MyApp.aip /quiet这段命令的逻辑是AdvancedInstaller.com是 Advanced Installer 的命令行入口/build触发构建/quiet抑制交互。参数说明工程文件.aip里已经保存了输出格式、路径、签名配置所以命令行只需要指定工程路径即可。实际接 CI 时建议把版本号做成变量在构建前用脚本替换.aip里的版本字段避免每次手动改。快捷方式配置在“Shortcuts”面板可以指定开始菜单和桌面快捷方式。注意桌面快捷方式在企业环境里经常被 IT 策略禁止所以不要把它当成唯一入口开始菜单快捷方式才是保底。注册表项在“Registry”面板配置。如果你的程序需要写注册表建议只写HKCU下的键避免提权问题。写HKLM的键会在卸载时残留除非你在“Uninstall”里显式清理。2.3 先决条件检测别让用户自己装 .NET 运行时先决条件Prerequisites是 Advanced Installer 最实用的功能之一。你可以在“Prerequisites”页里勾选 .NET Framework、.NET Runtime、VC Redistributable 等常见依赖安装包会在安装前自动检测缺失时引导下载或从本地包安装。配置步骤进入“Prerequisites”页点击“New”添加先决条件选择对应的运行时版本然后在“Options”里设置“Run as prerequisite”和“Install before main installation”。如果目标环境不能联网把“Download URL”换成“Local file”把离线安装包一起打进 EXE 引导程序里。这里有个参数要特别注意VC Redistributable 分 x86 和 x64 两个版本如果你的程序是 64 位但依赖了 32 位组件两个都要勾。漏勾的表现是安装成功但程序启动报0xc000007b这个错误码在 Windows 上就是典型的位数不匹配。3. 升级、卸载与数字签名交付后最容易翻车的三件事3.1 升级逻辑ProductCode 和 UpgradeCode 的区别Advanced Installer 里有两个 GUID 必须搞清楚ProductCode 和 UpgradeCode。ProductCode 标识“这一个版本”每次发版都应该换新的UpgradeCode 标识“这一条产品线”所有版本必须保持一致。升级能不能成功取决于新旧安装包的 UpgradeCode 是否相同、ProductCode 是否不同。在“Product Details”页里UpgradeCode 一般建工程时生成一次就不再动。ProductCode 可以在“Build”时自动生成勾选“Generate new ProductCode on each build”即可。如果你手动改 ProductCode 但忘了改版本号Windows Installer 会认为这是同一个产品升级时可能直接跳过。升级方式有两种Major Upgrade 和 Minor Upgrade。Major Upgrade 会先卸载旧版本再装新版本适合版本跨度大的场景Minor Upgrade 只替换文件速度快但要求版本号只改最后一位。我一般用 Major Upgrade配置在“Upgrades”页勾选“Customize”后设置“Remove older versions”这样用户装新版本时旧版本会被自动清理。3.2 卸载残留哪些目录和注册表项必须手动清Windows Installer 的卸载逻辑只清理它自己记录的文件和注册表项。如果你的程序在运行时生成了日志、缓存、用户配置这些不会被自动清理。常见残留位置包括%APPDATA%、%LOCALAPPDATA%、C:\ProgramData下的产品目录。处理方式是在“Custom Actions”里加一个卸载时执行的动作。下面是一段用 PowerShell 清理残留目录的自定义动作示例# 卸载时清理用户数据和缓存目录 # 这段脚本通过 Advanced Installer 的 Custom Action 调用 $paths ( $env:APPDATA\MyApp, $env:LOCALAPPDATA\MyApp, $env:ProgramData\MyApp ) foreach ($p in $paths) { if (Test-Path $p) { Remove-Item -Path $p -Recurse -Force -ErrorAction SilentlyContinue } }逻辑说明脚本遍历三个常见残留路径存在就递归删除。参数说明-ErrorAction SilentlyContinue保证某个目录被占用时不会中断整个卸载流程。在 Advanced Installer 里把这个脚本加到“Custom Actions”页执行时机选“Uninstall”执行条件设为“REMOVEALL”这样只有完全卸载时才触发升级时不触发。注意不要删%APPDATA%下用户自己创建的文件除非产品文档明确说明。我见过一个工具卸载时把用户导出的配置一起删了客户直接投诉。3.3 数字签名没有签名的安装包会被 SmartScreen 拦截Windows 10/11 对未签名安装包的拦截越来越严用户双击后看到“Windows 已保护你的电脑”蓝色弹窗转化率直接掉一半。解决办法是给安装包做代码签名需要一张代码签名证书OV 或 EV。在 Advanced Installer 的“Digital Signature”页里选择证书文件.pfx或从证书存储里选输入密码然后勾选“Sign the MSI”和“Sign the EXE”。如果同时输出 MSI 和 EXE两个都要签因为 EXE 引导程序会先被检查。签名时间戳很重要。不加时间戳的话证书过期后已签名的安装包会失效。在“Timestamp”里填一个时间戳服务器地址Advanced Installer 22.5 支持 RFC 3161 标准的时间戳。签名失败最常见的原因是证书链不完整建议在签名前用certutil -verify检查证书。4. 避坑与排查Advanced Installer 22.5 打包时最容易踩的五个坑4.1 安装时报 1603 错误日志里看不出原因现象安装进度条走到一半回滚提示“安装失败错误代码 1603”但界面上没有更多信息。原因1603 是 Windows Installer 的通用错误码真正原因藏在 MSI 日志里。常见触发点包括自定义动作脚本报错、文件被占用、权限不足。解决用命令行带日志安装msiexec /i MyApp.msi /l*v install.log然后打开install.log搜索“Return value 3”那一行前面就是真正的失败点。如果是自定义动作报错检查脚本里的路径是否用了硬编码改用[INSTALLDIR]这类属性。4.2 升级后旧版本文件还在程序加载了错误的 DLL现象装完新版本程序启动后行为异常排查发现加载的是旧版本 DLL。原因Major Upgrade 默认先装新版本再卸旧版本如果新旧版本文件路径相同旧文件可能覆盖新文件。或者 UpgradeCode 配错Windows Installer 没识别出这是升级。解决在“Upgrades”页确认 UpgradeCode 一致、ProductCode 不同、版本号递增。如果文件路径有冲突把新版本文件装到带版本号的子目录或者用“File Replacement”规则强制覆盖。4.3 先决条件检测通过但运行时仍缺 DLL现象安装时 .NET 检测通过程序启动报缺少某个 DLL。原因先决条件只检测了运行时框架没有检测你的程序依赖的第三方原生 DLL。或者检测的是 x86 版本实际需要 x64。解决把第三方 DLL 直接打进安装包不要依赖目标机器已有。在“Prerequisites”里同时勾选 x86 和 x64 版本的 VC Redist。用dumpbin /dependents检查你的 EXE 到底依赖哪些 DLL。4.4 静默安装参数不生效现象用msiexec /quiet静默安装结果还是弹出了界面或者安装到了默认路径而不是指定路径。原因MSI 的静默安装需要属性配合/quiet只是不显示 UI但路径、许可协议等属性如果没有通过命令行传入会走默认值或卡在许可协议页。解决用msiexec /i MyApp.msi /quiet INSTALLDIRD:\MyApp ACCEPT_EULA1这种方式传属性。属性名在 Advanced Installer 的“Dialogs”页里能看到每个输入框对应的属性名就是你要传的参数。4.5 签名后安装包体积暴涨现象签名前安装包 50MB签名后变成 150MB。原因签名工具在某些配置下会把整个文件重新打包或者你同时签了 MSI 和 EXE 但 EXE 里又嵌了一份 MSI导致重复。解决确认签名只做一次EXE 引导程序签名后不要再对内部 MSI 单独签名。如果体积仍然异常检查“Build”页里的压缩选项选“Best compression”而不是“None”。5. 把打包接进 CI用命令行和版本号变量做自动化交付前面几章讲的都是手动配置但真实项目里安装包应该跟代码一起构建。我的习惯是把.aip工程文件放进 Git用 CI 在每次打 tag 时自动构建安装包并上传到制品库。具体做法是在 CI 脚本里先用 PowerShell 替换.aip里的版本号再调用AdvancedInstaller.com /build。下面是一段在 CI 里替换版本号并构建的示例# 从 Git tag 提取版本号替换 .aip 工程里的版本字段 $version $env:CI_COMMIT_TAG -replace ^v, $aipPath D:\projects\MyApp\MyApp.aip (Get-Content $aipPath) -replace ROW PropertyProductVersion Value[^]*, ROW PropertyProductVersion Value$version | Set-Content $aipPath # 调用 Advanced Installer 命令行构建 C:\Program Files (x86)\Caphyon\Advanced Installer 22.5\bin\x86\AdvancedInstaller.com /build $aipPath /quiet逻辑说明先从 CI 环境变量里拿到 tag去掉前缀v然后用正则替换.aip文件里的 ProductVersion 字段。参数说明.aip本质是 XMLProductVersion 是其中一个属性行替换时注意保留引号转义。构建完成后把生成的 MSI 和 EXE 上传到制品库文件名带上版本号方便追溯。验证方法每次构建后用msiexec /i MyApp.msi /l*v install.log在干净虚拟机上装一遍确认版本号正确、升级逻辑正常、卸载无残留。我一般会准备一个 Windows Sandbox 或者 Hyper-V 快照专门用来做安装包验收避免在开发机上反复装卸污染环境。最后一个技巧Advanced Installer 22.5 支持“Repackager”功能可以把现有的 EXE 安装程序重新打包成 MSI。如果你接手的是别人做的老安装包没有源码可以用这个功能抓取安装过程生成可编辑的工程。但要注意Repackager 抓取的是文件系统和注册表快照自定义动作和条件逻辑可能丢失抓完必须手动补。我自己踩过最深的坑是升级时忘了改 ProductCode结果新旧版本在控制面板里显示成两个条目客户以为装重了。从那以后我在 CI 里加了一步校验构建前检查 ProductCode 是否与上一版本不同不同才允许发版。希望帮到你。本文还有配套的精品资源点击获取