PowerShell 7.4.6 MSIXBundle 发布缺失排查实录从流水线到 makeappx 补回 msix 生成链【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell现场还原7.4.6 发布2024-10-22之后用微软商店式现代安装器部署 PowerShell 的 Windows 用户开始报同一个问题官方发布页里PowerShell-7.4.6-win-x64.msixbundle不见了只剩 zip 和 msi按 URL 拉取该文件的自动化脚本直接 404。没有崩溃日志可读产物不存在本身就是全部报错。读完你能带走什么从 CHANGELOG 反查发布管线断点手动跑通 makeappx pack/bundle 验证产物把产物存在性断言写进打包脚本当硬卡点。沿证据链倒推排查顺序是固定的先看发布页现象再翻 changelog 找可疑变更最后才动配置文件和脚本。别一上来就改AppxManifest.xml那个坑我替你走过后面会讲。第一个线索藏在 CHANGELOG不在构建日志里发布产物缺失这种问题构建日志往往全绿因为本地打包和发布页上有没有文件是两回事。翻 CHANGELOG/7.4.md 的 7.4.6 段落第 552 行liDelete the msix blob if its already there (#24353)/li这条变更的本意是好的——发布前把存储里遗留的旧 msix blob 删掉防止旧产物被误引用。但删这个动作没有配套删完再确认新产物已就位的检查。再往下对照 7.4.7 段落第 498、503、508 行三条记录拼在一起看liFix backport issues with release pipeline (#24835)/li liUse work load identity service connection to download makeappx tool from storage account (#24817) (#24820)/li liDownload package from package build for generating vpack (#24481) (#24801)/li连起来读7.4.6 回背时发布管线自身先坏了#24835makeappx 工具的下载方式换了服务连接#24817vpack 生成改为从 package build 阶段取包#24801。三个修复条目全是管线级动作没有一个碰本地打包脚本——这就是定位结论msixbundle 生成失败的断点在发布流水线不在你能dotnet build出来的那一段。AppxManifest 里哪个版本字段卡住了你顺着发布管线调 makeappx这条线自然会先看 assets/AppxManifest.xml。第 23 行TargetDeviceFamily NameWindows.Universal MinVersion10.0.17763.0 MaxVersionTested10.0.18362.0 /MaxVersionTested停在 10.0.18362.02019 年的 Win10 版本。在 Windows 11 上跑makeappx validate会因此产生警告属于该修的技术债。但这条走不通作为根因validate 警告不会让管线终止更不会让已生成并上传的 bundle 凭空消失。第 46–50 行的windows.appExecutionAlias执行别名配置也是完好的安装后pwsh.exe别名能正常挂上排除嫌疑。打包脚本里 msix 是不是唯一通路再看本地打包入口 tools/packaging/packaging.psm1确认 msix 这条链路本身是通的第 55 行$Type的ValidateSet包含msix第 286–288 行Windows 上未显式指定类型时默认就是zip, msix第 427 行msix分支调用New-MSIXPackage第 3609 行实际执行$makeappx pack /o /v /h SHA256 /d $ProductSourcePath /p ...$packageName.msix。注意一个关键区分这段脚本只产出单架构.msix。.msixbundle是发布管线的产物——用makeappx bundle把 x64/arm64 两个 msix 拼进一个文件再作为 VPack 发布后续 7.4.15 的 changelog 第 143 行 Publish .msixbundle package as a VPack (#27187) 可佐证 bundle 与 VPack 的绑定关系。所以修好本地脚本并不等于发布页恢复 bundlemakeappx bundle 报错这一层只能由管线侧的 #24835 修复我们本地能做的是把整条链手动复现出来验证断点确实已愈合。动手修以下都在你自己的构建检出里做仓库是只读的别动上游。四步之间有因果版本基线 → 单架构 msix → bundle 拼装 → 防删除再犯。抬升 AppxManifest 版本基线 → validate 不再警告编辑assets/AppxManifest.xml第 23 行把测试版本上限抬到 Windows 11- TargetDeviceFamily NameWindows.Universal MinVersion10.0.17763.0 MaxVersionTested10.0.18362.0 / TargetDeviceFamily NameWindows.Universal MinVersion10.0.17763.0 MaxVersionTested10.0.22621.0 /改完后你应当看到makeappx validate /p .\out\PowerShell-x64.msix不再输出 Max version tested 相关警告。用 makeappx pack 重建单架构 msix → 拿到 bundle 的原料照抄packaging.psm1第 3609 行的调用方式# 参数与 packaging.psm1 保持完全一致避免本地/管线行为漂移 makeappx pack /o /v /h SHA256 /d .\staging\x64 /p .\out\PowerShell-x64.msix改完后你应当看到.\out\PowerShell-x64.msix生成且 validate 退出码为 0。⚠️ 如果这步就报makeappx找不到工具先确认 SDK 命令行工具集里的 makeappx 在 PATH 上——这正是 #24817 要解决的下载问题。拼出 msixbundle → 补回缺失的发布产物# 把各架构 msix 放入同一目录再 bundle这是发布页要的那个文件 makeappx bundle /d .\out /p .\out\PowerShell-7.4.6-win.msixbundle改完后你应当看到PowerShell-7.4.6-win.msixbundle存在且makeappx validate /p通过。在删除逻辑前加产物断言 → 堵住 #24353 的隐患对应 changelog 里 Delete the msix blob if its already there 的删库动作在你的发布脚本里把它改成条件删除# 先确认新 bundle 就位才允许清理旧 blob顺序反了就是 7.4.6 的事故 if (Test-Path $NewBundlePath) { Remove-Item $OldBlob -ErrorAction SilentlyContinue } else { throw 新产物未生成拒绝删除旧 blob }改完后你应当看到人为让新构建失败时脚本直接抛错中止而不是静默把旧 blob 删掉。端到端验证一条命令链确认修复生效# 清理 → 重打 → 断言跑完全绿才算闭环 dotnet clean .\src\powershell-win-core\powershell-win-core.csproj; Start-PSBuild -Configuration Release; Start-PSPackage -Type msix -WindowsRuntime win-x64; makeappx bundle /d .\out /p .\out\PowerShell-7.4.6-win.msixbundle; Test-Path .\out\PowerShell-7.4.6-win.msixbundle # 期望输出 True ✅最后那行打印True这条修复链才算数。别让它再犯test/packaging/windows/ 目前只有exe.tests.ps1和msi.tests.ps1补一个msix.tests.ps1每次发布后抓取官方发布页文件列表断言*.msixbundle必须在场缺了就红。在 tools/packaging/packaging.psm1 的msix分支第 427 行New-MSIXPackage返回后立即Test-Path校验.msix文件缺失则throw让整个打包任务失败——断言写在生成处而不是等发布页 404 了再回头查。上游的修复对应 CHANGELOG/7.4.md 7.4.7 段落第 498 行的 Fix backport issues with release pipeline (#24835)配合 #24817、#24801 一起把管线补了回来。建议去 7.4.7 及以后版本的发布页确认msixbundle文件已恢复再更新你的自动化部署脚本里的版本号。【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
PowerShell 7.4.6 MSIXBundle 发布缺失排查实录：从流水线到 makeappx 补回 msix 生成链
PowerShell 7.4.6 MSIXBundle 发布缺失排查实录从流水线到 makeappx 补回 msix 生成链【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell现场还原7.4.6 发布2024-10-22之后用微软商店式现代安装器部署 PowerShell 的 Windows 用户开始报同一个问题官方发布页里PowerShell-7.4.6-win-x64.msixbundle不见了只剩 zip 和 msi按 URL 拉取该文件的自动化脚本直接 404。没有崩溃日志可读产物不存在本身就是全部报错。读完你能带走什么从 CHANGELOG 反查发布管线断点手动跑通 makeappx pack/bundle 验证产物把产物存在性断言写进打包脚本当硬卡点。沿证据链倒推排查顺序是固定的先看发布页现象再翻 changelog 找可疑变更最后才动配置文件和脚本。别一上来就改AppxManifest.xml那个坑我替你走过后面会讲。第一个线索藏在 CHANGELOG不在构建日志里发布产物缺失这种问题构建日志往往全绿因为本地打包和发布页上有没有文件是两回事。翻 CHANGELOG/7.4.md 的 7.4.6 段落第 552 行liDelete the msix blob if its already there (#24353)/li这条变更的本意是好的——发布前把存储里遗留的旧 msix blob 删掉防止旧产物被误引用。但删这个动作没有配套删完再确认新产物已就位的检查。再往下对照 7.4.7 段落第 498、503、508 行三条记录拼在一起看liFix backport issues with release pipeline (#24835)/li liUse work load identity service connection to download makeappx tool from storage account (#24817) (#24820)/li liDownload package from package build for generating vpack (#24481) (#24801)/li连起来读7.4.6 回背时发布管线自身先坏了#24835makeappx 工具的下载方式换了服务连接#24817vpack 生成改为从 package build 阶段取包#24801。三个修复条目全是管线级动作没有一个碰本地打包脚本——这就是定位结论msixbundle 生成失败的断点在发布流水线不在你能dotnet build出来的那一段。AppxManifest 里哪个版本字段卡住了你顺着发布管线调 makeappx这条线自然会先看 assets/AppxManifest.xml。第 23 行TargetDeviceFamily NameWindows.Universal MinVersion10.0.17763.0 MaxVersionTested10.0.18362.0 /MaxVersionTested停在 10.0.18362.02019 年的 Win10 版本。在 Windows 11 上跑makeappx validate会因此产生警告属于该修的技术债。但这条走不通作为根因validate 警告不会让管线终止更不会让已生成并上传的 bundle 凭空消失。第 46–50 行的windows.appExecutionAlias执行别名配置也是完好的安装后pwsh.exe别名能正常挂上排除嫌疑。打包脚本里 msix 是不是唯一通路再看本地打包入口 tools/packaging/packaging.psm1确认 msix 这条链路本身是通的第 55 行$Type的ValidateSet包含msix第 286–288 行Windows 上未显式指定类型时默认就是zip, msix第 427 行msix分支调用New-MSIXPackage第 3609 行实际执行$makeappx pack /o /v /h SHA256 /d $ProductSourcePath /p ...$packageName.msix。注意一个关键区分这段脚本只产出单架构.msix。.msixbundle是发布管线的产物——用makeappx bundle把 x64/arm64 两个 msix 拼进一个文件再作为 VPack 发布后续 7.4.15 的 changelog 第 143 行 Publish .msixbundle package as a VPack (#27187) 可佐证 bundle 与 VPack 的绑定关系。所以修好本地脚本并不等于发布页恢复 bundlemakeappx bundle 报错这一层只能由管线侧的 #24835 修复我们本地能做的是把整条链手动复现出来验证断点确实已愈合。动手修以下都在你自己的构建检出里做仓库是只读的别动上游。四步之间有因果版本基线 → 单架构 msix → bundle 拼装 → 防删除再犯。抬升 AppxManifest 版本基线 → validate 不再警告编辑assets/AppxManifest.xml第 23 行把测试版本上限抬到 Windows 11- TargetDeviceFamily NameWindows.Universal MinVersion10.0.17763.0 MaxVersionTested10.0.18362.0 / TargetDeviceFamily NameWindows.Universal MinVersion10.0.17763.0 MaxVersionTested10.0.22621.0 /改完后你应当看到makeappx validate /p .\out\PowerShell-x64.msix不再输出 Max version tested 相关警告。用 makeappx pack 重建单架构 msix → 拿到 bundle 的原料照抄packaging.psm1第 3609 行的调用方式# 参数与 packaging.psm1 保持完全一致避免本地/管线行为漂移 makeappx pack /o /v /h SHA256 /d .\staging\x64 /p .\out\PowerShell-x64.msix改完后你应当看到.\out\PowerShell-x64.msix生成且 validate 退出码为 0。⚠️ 如果这步就报makeappx找不到工具先确认 SDK 命令行工具集里的 makeappx 在 PATH 上——这正是 #24817 要解决的下载问题。拼出 msixbundle → 补回缺失的发布产物# 把各架构 msix 放入同一目录再 bundle这是发布页要的那个文件 makeappx bundle /d .\out /p .\out\PowerShell-7.4.6-win.msixbundle改完后你应当看到PowerShell-7.4.6-win.msixbundle存在且makeappx validate /p通过。在删除逻辑前加产物断言 → 堵住 #24353 的隐患对应 changelog 里 Delete the msix blob if its already there 的删库动作在你的发布脚本里把它改成条件删除# 先确认新 bundle 就位才允许清理旧 blob顺序反了就是 7.4.6 的事故 if (Test-Path $NewBundlePath) { Remove-Item $OldBlob -ErrorAction SilentlyContinue } else { throw 新产物未生成拒绝删除旧 blob }改完后你应当看到人为让新构建失败时脚本直接抛错中止而不是静默把旧 blob 删掉。端到端验证一条命令链确认修复生效# 清理 → 重打 → 断言跑完全绿才算闭环 dotnet clean .\src\powershell-win-core\powershell-win-core.csproj; Start-PSBuild -Configuration Release; Start-PSPackage -Type msix -WindowsRuntime win-x64; makeappx bundle /d .\out /p .\out\PowerShell-7.4.6-win.msixbundle; Test-Path .\out\PowerShell-7.4.6-win.msixbundle # 期望输出 True ✅最后那行打印True这条修复链才算数。别让它再犯test/packaging/windows/ 目前只有exe.tests.ps1和msi.tests.ps1补一个msix.tests.ps1每次发布后抓取官方发布页文件列表断言*.msixbundle必须在场缺了就红。在 tools/packaging/packaging.psm1 的msix分支第 427 行New-MSIXPackage返回后立即Test-Path校验.msix文件缺失则throw让整个打包任务失败——断言写在生成处而不是等发布页 404 了再回头查。上游的修复对应 CHANGELOG/7.4.md 7.4.7 段落第 498 行的 Fix backport issues with release pipeline (#24835)配合 #24817、#24801 一起把管线补了回来。建议去 7.4.7 及以后版本的发布页确认msixbundle文件已恢复再更新你的自动化部署脚本里的版本号。【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
