PowerShell 7.4.6 的 MSIXBundle 安装包丢了？三步定位到构建流水线-平芜编程栈

PowerShell 7.4.6 的 MSIXBundle 安装包丢了？三步定位到构建流水线

【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell

7.4.6 的 Releases 页面翻了一圈，Windows 平台只有.msi、.zip和 tar 包，唯独 PowerShell 7.4.6 的 MSIXBundle 安装包（.msixbundle）不在列表里。自动化部署脚本按固定 URL 拉包直接 404，走 MSIX 通道的安装流程整体卡死；手工下载又得被迫改走 zip 方案。这篇文章带你从产物缺失的表象出发，顺着 CHANGELOG、manifest 和安装脚本把原因挖出来，并给出最小改动集。

01 症状清单：谁会被卡住

发布页找不到.msixbundle，msi / zip / tar 包都正常
部署脚本按惯例拼出的下载 URL 返回 404
企业内走 MSIX 分发的机器无法完成静默安装
被卡住的通常是：自动化部署流水线维护者、需要无管理员权限装 PowerShell 的运维

02 排查路径：从 CHANGELOG 一路挖到安装脚本

2.1 先翻 CHANGELOG，锁定嫌疑变更

打开 CHANGELOG/7.4.md 的[7.4.6]章节（该版本 2024-10-22 发布），标题是"Build and Packaging Improvements"，变更集中在构建与打包：.NET SDK 升到 8.0.403、NuGet 源调整、vpack 流水线更新……其中第 552 行这条最扎眼：

Delete the msix blob if it's already there (#24353)

这类"构建缓存清理"逻辑写得不严谨时，最容易把真正的发布产物一起误删。看到它，先怀疑流水线。

2.2 再看打包配置：manifest 版本约束没跟上

msix 打包的元数据模板在 assets/AppxManifest.xml。打开文件，第 23 行：

<TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.17763.0" MaxVersionTested="10.0.18362.0" />

7.4.6 同步升级了 .NET SDK，但 manifest 的MaxVersionTested还停在 18362.0，没覆盖 Windows 11 的构建环境。makeappx 校验时看到目标系统高于声明值，会判定不兼容，于是整段 msix 打包分支被静默跳过——包消失，构建却报成功，这就是"发布页没有包但流水线是绿的"的直接原因。看到它，再怀疑 manifest。

2.3 最后看安装脚本：分支根本没留 msix 的位置

顺手查 tools/install-powershell.ps1 第 280-284 行的包名拼接逻辑，Windows 分支只有两条路：

if ($UseMSI) { $packageName = "PowerShell-${release}-win-${architecture}.msi" } else { $packageName = "PowerShell-${release}-win-${architecture}.zip" }

没有 msix 分支，脚本拼不出.msixbundle的包名。这不是 bug，而是上游产物本来就没生成，脚本只是"忠实反映"了这一点。三个环节互相印证，排查闭环。

03 最小改动集：三处修复，每处都有理由

3.1 流水线：给 blob 清理加白名单

改哪里：发布流水线中执行"删除已存在的 msix blob"的清理步骤（即 #24353 对应的实现）。

改什么：清理逻辑排除.msixbundle，只清散包、保留 bundle。

为什么：缓存清理是性能优化，发布产物是最终交付，两者不该共用一条删除路径。

3.2 manifest：把版本上界抬到 Windows 11

改哪里：assets/AppxManifest.xml 第 23 行。

改什么：

- <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.17763.0" MaxVersionTested="10.0.18362.0" /> + <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.17763.0" MaxVersionTested="10.0.22621.0" />

为什么：MaxVersionTested决定 makeappx 在新环境上的兼容性判定，不抬到 22621.0，Windows 11 构建机上的打包校验永远过不了。

3.3 安装脚本：补上 msixbundle 分支

改哪里：tools/install-powershell.ps1 第 280-284 行（示例改法，仓库只读）：

if ($UseMSI) { $packageName = "PowerShell-${release}-win-${architecture}.msi" + } elseif ($UseMSIX) { + $packageName = "PowerShell-${release}-win-${architecture}.msixbundle" } else { $packageName = "PowerShell-${release}-win-${architecture}.zip" }

同时在参数区加一个[Parameter(ParameterSetName = "MSI")] [switch] $UseMSIX。为什么：产物恢复之后，脚本得能真正拉到它，否则用户侧体验还是断的。

04 验证闭环：手动构建，看输出下结论

在 Windows 打包机上手动跑一遍 MSIX 打包（👇 命令来自 tools/packaging/packaging.psm1 中New-MSIXPackage的示例用法）：

Start-PSBuild -Clean Start-SPBuild -Package msix -ProductArchitecture x64

然后验证产物：

Test-Path .\src\powershell-win-core\bin\Release\net8.0\win-x64\publish\PowerShell.msixbundle

输出True即说明打包链路恢复；再用Get-Item看一眼大小（正常是上百 MB 级别）。如果False，顺着上面三处排查：编译失败看编译日志，签名失败看签名步骤，bundle 缺失就看MakeAppx那一步的退出码。

05 避坑清单：这次踩过的坑，列出来

#	坑	应对
1	打包产物无专项测试兜底	test/packaging/windows/ 目前只有`msi.tests.ps1`与`exe.tests.ps1`，建议补一个 msixbundle 生成与可安装性测试
2	流水线"删除类"变更不带产物验证	#24353 只删不验，直接造成发布缺包；凡是涉及清理的逻辑，变更必须附产物存在性断言
3	.NET SDK 升级不看 manifest 约束	7.4.6 升了 SDK，`MaxVersionTested`却没跟着动，校验静默跳过打包；依赖升级清单里应包含 manifest 版本约束扫描