简介Advanced Installer 22.5 打包 Windows 安装包的完整资源集主要面向需要制作或维护安装程序的软件开发者、IT 运维与打包工程师可帮助快速搭建专业、稳定的 Windows 安装部署方案。包内共收录 2000 个文件压缩后大小约 229.56MB包含 623 个 png 图片、419 个 aip 项目文件、321 个 jpg 图片、136 个 ico 图标以及 75 个 xsd 与 61 个 xml 配置模板、61 个 rtf 说明文档、47 个 ail 语言资源等基本覆盖安装包界面素材、脚本配置、多语言支持和帮助文档等各类要素。目前已有 1428 人学习/下载适合需要离线使用或系统研究 Advanced Installer 打包流程的技术人员。通过该资源读者可获得完整的工具组件、示例项目与本地化语言文件既能参考现有配置快速生成自定义安装包也能用于排查打包问题或进行二次开发从而提升 Windows 软件分发的规范性和交付效率。1. 为什么你的下一个工具要用 Advanced Installer 22.5 打 Windows 安装包当你负责的 Windows 程序需要从“发文件夹”进化成“发安装包”时第一版往往很简单复制文件、加个快捷方式就完事了。但放到几十台机器上缺 VC 运行库、注册表写了读不到、服务一启动就退出问题会在交付现场连着翻车。Advanced Installer 22.5 的价值是把文件、先决条件、注册表、服务、构建和签名这些散点收进同一个图形工程最终产出一个能被 msiexec 静默分发、能被 Windows 正常识别和卸载的 MSI 安装包。我最早用它是为了给内部工具集成 WebView2 运行库后来发现更值钱的是命令行接口能让构建机在 CI 里自动出包。这篇文章按我的实际打包顺序展开先选对项目类型再填产品信息和文件目录接着处理先决条件、注册表和服务最后讲构建、签名和命令行自动化的坑。适合手里有 Windows 程序要打安装包又不想去啃 WiX 和 MSI 表结构的开发或运维。2. 项目类型和产品信息先锁定升级代码再谈文件打包2.1 不要一上来就选 Simple项目类型决定你能用哪些页面打开 Advanced Installer 22.5 后第一个决定是新建什么项目。我默认选“专业项目”理由是简单项目只保留文件和快捷方式这类基础页面注册表、服务、先决条件这些页面要么没有、要么被折叠。实际做安装包的时候需求往往来得比想象中晚今天只说复制文件明天就要加 .NET 4.8 检测后天要把某个服务装上并把启动类型改成手动。一开始选了简单项目后面为了一个功能重建工程是常有的事。还需要了解的是“套件项目”。当交付物必须是 EXE 引导程序——先装 VC 运行库再装主程序最后弹用户协议——套件项目负责把多个 MSI/EXE 打包成一个可执行文件。业务上其实两种包不冲突主程序和先决条件各自打 MSI套件只负责串联。如果你同时维护三五个不同的分发包建议用套件项目把“安装序列”固定下来如果日常就一个产品专业项目出 MSI 就够了。提示项目类型选好后可以在“文件 → 另存为”里变更类型但功能页面迁移偶尔会丢自定义配置我一般不再换类型前期就按最终需求选。选好专业项目后左侧项目树会出现应用信息、文件、注册表、启动条件、先决条件、操作、系统更改、参数、构建这些页面。其中“应用信息”是入口几乎每个页面都依赖里面定义的产品身份。2.2 产品信息产品代码与升级代码各管什么事进入“应用信息 → 产品信息”页面这里的几个值决定安装包在 Windows 眼中的身份。产品名称比如“InternalWorkbench”建议与业务一致因为卸载面板里显示的就是它。制造商字段会生成身份目录影响安装路径一般填公司内部名不要带中文。版本号遵循“主.次.修订”格式例如 1.0.0每发布一个版本都要递增。最关键的是两个 GUID产品代码ProductCodeMSI 把每个版本当成独立产品来区分的 GUID发新版时必须重新生成。升级代码UpgradeCode同一个产品系列的“家谱”GUID保持一辈子不变。我项目里第一个翻车点就在这。第一版用了默认生成的两个 GUID之后没动过第二版 MSI 放到机器上出现了两个并列图标。原因在于 MSI 标准下产品代码相同意味着“同一个版本”Windows 会把它当成同版本更新来比较升级代码相同而产品代码不同才进入“大版本升级”检测。我的习惯是每次升版本在产品信息里点“生成新 GUID”只换产品代码升级代码保持初始值。“升级”页面还要检查一下。专业项目通常会生成一条大版本升级规则新版本比当前高就卸载旧版再装新版版本相同则提示“请先卸载”。如果没有看到这条规则需要手动添加并把执行动作设为“卸载旧版本并安装新版本”。这一步不做后面 5.4 的问题就会找上门。2.3 文件打包让安装目录和你本机的目录结构对上“文件”页面是打包的主战场。右键“应用程序文件夹”选择“添加文件”把主程序和依赖的 DLL 一起拖进去。如果你的程序有 bin 目录最好“添加文件夹”保持子目录相对关系因为程序里的相对路径不会因为到了客户机器就自动改变。安装后的实际结构是“Program Files 文件夹 → 制造商 → 产品名 → bin”。安装包里主可执行文件要标出来右键那个 EXE选择“设置为主可执行文件”。这一步不仅会在开始菜单生成启动项和卸载入口还会让产品图标、版本号自动取到 EXE 的资源信息。文件版本冲突是打包时常见但容易被忽略的问题。Advanced Installer 22.5 检测到同名文件时默认按版本策略处理但如果你之前的软件包把多个版本的本地开发运行时都带上了安装包体积会膨胀得厉害。我习惯在“移除文件”里做一次清理把不需要的旧版 DLL 排除掉。换版本后只要再次构建升级规则会自动对比文件列表完成差异替换不必手动删旧文件。安装包还需要确认默认安装目录。在“文件”页面的“目标文件夹”组合框里可以把默认的“Program Files 文件夹 → 制造商 → 产品名”改成仅“Program Files 文件夹 → 产品名”。注意如果改成不是 Program Files 的目录比如用户目录或自定义目录权限和升级路径都会不一样。一般企业内部工具用默认目录就好少改动少出错。# 用 msiexec 静默安装验证 MSI 最基本的安装入口 msiexec /i D:\build\MyApp.msi /qn /norestart/qn表示不显示任何 UI 并同步执行/norestart禁止安装完成后自动重启避免干扰测试。返回值是 0 说明基础安装路径没断。每次改完“文件”页面我都要跑一遍这条命令比在图形界面里反复点“安装”快得多。如果目录设计有问题这一步会立刻暴露。3. 把运行环境装进安装包先决条件、注册表和服务3.1 先决条件离线环境最怕“在线下载”四个字安装包最常遇到的抱怨是“我装了你的程序但打开少个 DLL”。这个 DLL 多数时候是 VC 运行库或 .NET Framework。在 Advanced Installer 22.5 里“先决条件”页面维护着一个预置清单.NET Framework 3.5/4.8、Visual C 2015—2022 Redistributablex64/x86、WebView2 Runtime 等。打勾选中安装包会在主程序之前先装它们。具体到设置在“先决条件”页面检查条目上的“安装条件”是否与目标系统匹配。如果客户机器是 Win10 64 位VC 运行库选择 x64 版本不要图省事把 x86 和 x64 都选上双份会让安装时间和体积明显增多。如果程序用到了 WPF 或 WebView2 控件强烈建议勾选 WebView2 Runtime——现代 Windows 客户端应用几乎都会用到。想打离线安装包时用本地离线安装包而不是依赖目标机器在线下载。部署到内网机器时要注意条目默认可能选择了在线下载方式也就是安装时从微软官方拉取运行库。内网机器没有外网安装就会卡住或直接跳过。正确做法是把这些运行库设为“本地文件”并指向提前下载好的文件例如 VC_redist.x64.exe、webview2 离线安装包。这样 MSI 变成“自足型”包安装时不依赖网络企业分发才算完整。如果你同时要管 32 位和 64 位两套主程序先决条件也要区分x86 MSI 配 x86 运行库x64 MSI 配 x64 运行库。曾经遇到过同事把两个都勾上结果安装包体积从 80MB 变成 130MB安装时间翻倍还没解决任何实际需求。3.2 启动条件设定系统门槛别让安装包在旧系统上裸奔“启动条件”页面用于设定安装包的系统门槛条件不满足就直接弹提示中止安装。典型配置是一条 Windows 版本条件版本“ 6.1”代表 Windows 7 及以上。如果程序用了较新的系统 API再往上加不确定就保持这条件。如果业务有更硬性的依赖——比如目标机器必须装了某个第三方软件——可以新建“文件存在”或“注册表项存在”的检测。但条件过多会把安装包变成“黑匣子”安装失败时用户根本猜不出哪一条没过。我建议优先保证两条系统版本和 VC 运行库。其余依赖靠程序启动时的自检来做更灵活也更容易把错误提示写清楚。启动条件里还有一个容易踩的地方64 位系统上装 32 位包Windows 版本检测默认按 64 位系统属性判断如果你的程序只能跑在支持 32 位子系统的系统上反而要多加一条处理器架构检测。不过现在 Windows 10/11 都默认支持 WoW64这条一般不用管。3.3 注册表先想清楚程序是 32 位还是 64 位在“注册表”页面下可以新建键值。最常见的就是把安装目录或版本号写进“HKLM\Software\公司\产品”程序运行时读取配置。操作不复杂右键“我的电脑”新建键和值把值类型选为字符串或 DWORD下方填入数据。麻烦出在 Windows 的注册表重定向。64 位系统上同一个“Software”分支会被分成 64 位视图和 32 位视图32 位程序读取“HKLM\Software\Foo”实际落到“HKLM\Software\WOW6432Node\Foo”。如果你的安装包是 64 位 MSI在注册表页默认写的是 64 位视图那么同一台机器上装的 32 位程序读不到这个键。我的经验是注册表页面顶部有“视图”下拉框可以切“64 位视图”和“32 位视图”。新建键之前先问这个键是给哪个程序读的主程序是 x64 还是 x86然后按程序位数选对应视图。如果历史包袱全是 32 位程序整包都按 32 位处理也未尝不可安装包还是 64 位的注册表键落到 32 位视图即可。这个细节不加注意部署后会出现“注册表看到了但程序就是读不到”的玄学问题。值类型也要注意。字符串用“字符串值”数值用“DWORD”路径类用“可扩充字符串值”并填 %SystemRoot% 这类变量。写错类型会导致程序运行时类型转换异常C 程序尤其敏感。# 安装后检查注册表键是否真的存在 Get-ItemProperty -Path HKLM:\Software\MyCompany\MyApp -ErrorAction SilentlyContinue这条命令适合在验证阶段用返回空说明键没写进去返回了值说明键存在接下来再去核对位数视图和值类型。3.4 服务启动类型和运行账户决定了能不能开机自启如果你的程序带一个常驻服务进入“系统更改 → 服务”页面。添加服务时至少设置四个值服务名服务控制管理器里显示的内部名例如“InternalWorkSvc”不要带空格。可执行文件路径必须填绝对路径常见写法是“[INSTALLDIR]\bin\InternalWorkSvc.exe”。相对路径在服务管理器里会直接失败。启动类型自动、手动、禁用。要求开机自启选“自动”。运行账户默认“本地系统账户”通常够用如果服务需要访问网络共享或特定数据库改成“NETWORK SERVICE”或指定账户。还要看一眼“依赖关系”。服务依赖的 DLL 或数据库服务若没就绪启动时会报“服务已启动但很快停止”。比如把 Redis 的 Windows 版本从网上拉下来自己封装成安装包时日志目录、数据目录、端口占用这些先决条件经常导致服务启动失败。以下两行命令是排查这类问题最快的方式# 查看服务当前状态 Get-Service -Name InternalWorkSvc # 查看服务控制管理器最近 50 条事件里的报错 Get-WinEvent -LogName System -FilterXPath *[System[Provider[NameService Control Manager]]] -MaxEvents 50 | Where-Object { $_.Message -like *InternalWorkSvc* }用Get-Service确认服务状态是否停在“已停止”用系统日志查出具体错误码而不是看到“启动失败”就认定是权限问题。绝大多数服务启动失败的根因是路径不存在或依赖库缺失跟权限关系不大。4. 构建与发布MSI、EXE、签名和升级策略4.1 MSI 与 EXE先确定交付形式再谈打包专业项目底层生成 MSI。MSI 的优势很明确可以用 msiexec 做静默安装和卸载可以被组策略和 SCCM 接管可以在“程序和功能”里被正常识别和移除升级时还能走标准的大版本升级流程。对企业分发来说MSI 是更省事的格式。EXE 引导程序则更友好双击就能装还能把多个组件和先决条件串联成一个安装序列。但 EXE 包的静默参数、卸载行为通常不统一对自动化和资产管理来说是个负担。交付格式优势典型场景MSI支持 msiexec 静默、可被组策略/SCCM 接管企业批量部署、脚本自动化EXE 引导程序双击即装可串联多个组件和先决条件官网下载、客户手动安装我的建议是内部工具直接交付 MSI。无论是给同事用还是给客户现场部署MSI 对工程师调试更透明。EXE 留给那些明确要求“双击安装”的场景比如售前演示包或下载站安装包。4.2 构建配置架构、输出目录、执行级别进入“构建”页面默认有一个 MSI 配置。构建前需要确认几件事。架构在构建类型里选“x64”还是“x86”要与主程序位数一致。如果主程序是 32 位部署到 64 位系统x86 MSI 运行没问题WOW64 在系统层面负责兼容但注册表位数和安装目录要按上一章的规则处理。输出目录设置输出目录为固定发布路径例如D:\release\out。CI 构建时改成共享目录或按日期生成。如果输出目录下已经有旧 MSI建议先清空避免把旧产物当成新版本发出去。执行级别在构建设置里找到“安装程序权限级别”选“管理员”。如果程序只装到用户目录、不需要管理员权限选“最低权限”并配合“按用户”安装模式。企业内部软件默认选管理员最省心否则写 Program Files 目录时会中途报权限不足。语言在“产品信息 → 语言”中确认默认语言为“中文简体”。如果只装了英文语言中文系统上可能会出现安装界面缺字或无法显示的问题。中英双语包则两种语言都添加。4.3 数字签名没有签名企业分发多出一堆事构建选项卡的“代码签名”可以加载 PFX 证书和密码。如果公司有正规代码签名证书必须在打包阶段就做进去。签名的 MSI 能过 SmartScreen、能通过企业软件分发代理的安全扫描也能少掉一大半“安装被系统拦截”的投诉。如果暂时没有正式证书——比如内部工具只在公司域内分发——至少建一个内部 CA 的测试证书并把根证书推送到各客户机的信任区。但要注意SmartScreen 的“不信任”不等于“程序不能用”有条件还是买正式证书。签名引擎选 SHA256SHA1 已经被现代 Windows 和不少安全软件视为可疑。4.4 验证构建产物脚本回读升级代码构建完成后我习惯用 PowerShell 从 MSI 里读一次关键属性确认升级代码没被误改、产品代码确实是新值。这一步比打开工程看“产品信息”更接近最终产物。# 从构建出的 MSI 里读出 UpgradeCode 和 ProductCode $installer New-Object -ComObject WindowsInstaller.Installer $db $installer.OpenDatabase(D:\release\out\MyApp.msi, 0) $view $db.OpenView(SELECT Value FROM Property WHERE PropertyUpgradeCode) $record $view.Fetch() if ($record) { Write-Host UpgradeCode: $($record.StringData(1)) } $view2 $db.OpenView(SELECT Value FROM Property WHERE PropertyProductCode) $record2 $view2.Fetch() if ($record2) { Write-Host ProductCode: $($record2.StringData(1)) }这段代码用 Windows Installer COM 接口打开 MSI查询 Property 表里的对应 GUID。每次构建后跑一下比在项目里翻“产品信息”更直接。如果两个代码在新旧版本之间不符合规则说明构建配置出了问题在发布前就能发现。5. 安装包实战避坑五条能让交付翻车的常见问题5.1 先决条件走在线下载内网安装直接卡死现象安装到一个内网机器时进度条走了一会儿就卡住完成后程序却没装上。原因先决条件配置的是“从互联网下载”运行库而内网隔离没有外网MSI 一直在等下载超时。解决在“先决条件”页面把相关运行库全部改为“本地文件”并指向提前下载的离线包例如 VS2019 离线安装包里的 VC_redist、提前备好的 webview2 离线安装包。验证方式很简单看 MSI 构建后的体积是否比只含主程序时大出对应运行库的大小没变大说明没嵌进去。5.2 注册表写进去了程序却读不到现象regedit 里能看到键程序一运行还是用默认值像没写进去一样。原因64 位系统存在注册表重定向。MSI 按 64 位视图写入 HKLM\Software\MyCompany\MyApp32 位程序读取时被 WOW64 重定向到 HKLM\Software\WOW6432Node\MyCompany\MyApp两个位置互不干扰。解决在注册表页面顶部切换视图。给 32 位程序用的键建立在 32 位视图给 64 位主程序用的键建立在 64 位视图。如果 32 位和 64 位程序确实需要不同的配置值就建两个同名键分别写值。5.3 服务安装成功但启动就停现象安装时服务被创建点“启动”立即变回“已停止”。原因服务可执行文件路径是相对路径或依赖的 DLL 缺失。服务管理器启动它时找不到绝对路径或者路径下缺少运行库。解决把服务属性里的执行路径改成“[INSTALLDIR]\bin\svc.exe”这种绝对路径发布前用事件日志查错误码再检查文件打包是否完整带上 bin 目录。如果服务是 .NET Core 程序别忘了先决条件里要勾上对应的 .NET 运行时。5.4 新版 MSI 装不上提示旧版未卸载现象双击新版 MSI提示“请先卸载旧版本”或者弹“系统已经安装了相同版本”然后退出。原因升级代码不一致而不是真的“旧版没卸”。当你改了产品代码却没保持升级代码一致时MSI 把新版本当成别的产品当产品代码一致时又触发“同版本已存在”。解决每次发新版只换产品代码升级代码保持不变在“升级”页面确认存在大版本升级规则并把动作设为“删除旧版本并安装新版本”必要时在测试机上手动卸载旧版验证。5.5 1603 安装失败且日志定位不到具体错误现象msiexec /i 返回 1603默认日志只有一行“安装未完成”。原因最常见是安装目录权限不足、存在残留临时文件或另一个 msiexec 进程正在运行。企业环境里用户账户不是本地管理员也会触发。解决用/l*v生成详细日志日志里会写到最后失败的文件或操作。命令如下# 静默安装并保留详细日志 msiexec /i D:\release\out\MyApp.msi /qn /norestart /l*v D:\logs\install.log然后打开日志看最后二十行找到“Return value 3”或错误码位置。1603 若伴随“权限不足”用管理员身份重跑若伴随“另一个安装正在进行”先结束所有 msiexec 进程再试。6. 把打包接进 CI一条命令出安装包的进阶用法6.1 找到命令行工具Advanced Installer 22.5 安装目录下的 bin 文件夹里可以找到AdvancedInstaller.com这是命令行入口。基本用法是把工程文件路径传给它再带构建参数C:\Program Files (x86)\Caphyon\Advanced Installer 22.5\bin\x64\AdvancedInstaller.com \ D:\projects\MyApp.aip -build -outdir D:\release\out -log D:\logs\aip_build.log-build是构建动作-outdir指定产物目录-log保留构建日志。执行后返回码为 0 说明构建成功非 0 就打开日志看最后一段。这条命令在 Jenkins、GitLab CI 的 Windows 节点上直接可用。6.2 在 CI 里加一道产物校验把 .aip 工程文件和构建脚本放进仓库CI 执行上一条命令把 MSI 作为构建产物上传。我还会在构建后加一道校验防止“构建成功却变了产物名字”或“升级代码被误改”# 验证 MSI 中关键属性 $installer New-Object -ComObject WindowsInstaller.Installer $db $installer.OpenDatabase(D:\release\out\MyApp.msi, 0) $view $db.OpenView(SELECT Value FROM Property WHERE PropertyProductCode) $r $view.Fetch() Write-Host ProductCode: $($r.StringData(1))如果团队对版本有严格要求还可以在构建脚本里用参数覆盖工程中的版本号。每次 Release 构建用同一套工程文件和参数输出包的唯一差异是版本号。6.3 静默安装与卸载验证最后一步在干净虚拟机里执行msiexec /i D:\release\out\MyApp.msi /qn /norestart /l*v D:\logs\verify.log Start-Sleep -Seconds 10 Get-Service InternalWorkSvc | Select-Object Status这是我最常用来验收的三个命令静默装上、等服务启动、确认状态。服务起来后再测卸载确认卸载后注册表项、安装目录和服务都被清理干净。把这套流程固定下来以后每次发布都在干净的 Win10/11 VM 里跑一遍加上 CI 的自动构建基本能把环境差异带来的问题挡在交付前。提示MSI 的卸载命令是msiexec /x。CI 里验证完顺手跑一遍卸载能避免开发机上堆出好多残留服务。我写打包工程时有个习惯先在纸上写下升级代码、注册表视图、先决条件离线文件这三个点。这三个点在打包项目里解决得越早后面反复打包的次数越少。按这个顺序做希望帮到你。本文还有配套的精品资源点击获取