PowerShell 7.4.6 的 MSIXBundle 安装包丢了三步定位到构建流水线【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell7.4.6 的 Releases 页面翻了一圈Windows 平台只有.msi、.zip和 tar 包唯独 PowerShell 7.4.6 的 MSIXBundle 安装包.msixbundle不在列表里。自动化部署脚本按固定 URL 拉包直接 404走 MSIX 通道的安装流程整体卡死手工下载又得被迫改走 zip 方案。这篇文章带你从产物缺失的表象出发顺着 CHANGELOG、manifest 和安装脚本把原因挖出来并给出最小改动集。01 症状清单谁会被卡住发布页找不到.msixbundlemsi / 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 its already there (#24353)这类构建缓存清理逻辑写得不严谨时最容易把真正的发布产物一起误删。看到它先怀疑流水线。2.2 再看打包配置manifest 版本约束没跟上msix 打包的元数据模板在 assets/AppxManifest.xml。打开文件第 23 行TargetDeviceFamily NameWindows.Universal MinVersion10.0.17763.0 MaxVersionTested10.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 NameWindows.Universal MinVersion10.0.17763.0 MaxVersionTested10.0.18362.0 / TargetDeviceFamily NameWindows.Universal MinVersion10.0.17763.0 MaxVersionTested10.0.22621.0 /为什么MaxVersionTested决定 makeappx 在新环境上的兼容性判定不抬到 22621.0Windows 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 升了 SDKMaxVersionTested却没跟着动校验静默跳过打包依赖升级清单里应包含 manifest 版本约束扫描7.4.7 的发布流水线回补修复CHANGELOG/7.4.md 中 #24835 Fix backport issues with release pipeline也印证了这条路径。验证通过即收工。【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
