PowerShell 7.4.6 缺 .msixbundle四步修复 三条验证命令【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell跑完 Release 构建产物目录里躺着 .msi 和 .zip唯独 .msixbundle 不见踪影。这是 PowerShell 7.4.6 版本一个让不少部署团队卡住的坑官方渠道少了 MSIXBundle 包企业批量装机脚本直接报错。本文带你把根因钉在仓库文件上再用四步改动和三条命令把这个包找回来。30秒看懂这个包为什么不见了MSIXBundle 是 Windows 上的多架构安装包一个 bundle 里装着各 CPU 架构的 .msix安装器按机器自动挑。7.4.6 的构建记录里有条已存在就删旧 msix 缓存的清理规则#24353加上打包链路里 bundle 环节的薄弱最终让发布产物里少了一个格式。先自检三个信号确认你踩的是同一个坑信号一msix 包只pack不bundle先看一个现象本地构建出的 Windows 产物只有 .msi 和 .zip。结论先行——本地打包链路根本没写 bundle 环节。证据在 tools/ci.psm1 第 620 行Windows 的打包清单里就这三样$packageTypes zip, zip-pdb, msix再往下看 tools/packaging/packaging.psm1 第 3609 行msix 分支只执行了makeappx pack $makeappx pack /o /v /h SHA256 /d $ProductSourcePath /p .../$packageName.msixpack只产单个架构的 .msix而 .msixbundle 需要额外的makeappx bundle一步。链路里没有这一步bundle 自然缺失。信号二manifest 的版本约束停在 2019 年第二处疑点在 assets/AppxManifest.xml 第 23 行TargetDeviceFamily NameWindows.Universal MinVersion10.0.17763.0 MaxVersionTested10.0.18362.0 /MaxVersionTested10.0.18362.0对应的是 2019 年的 Windows 10 版本。它名义上只是记录值但部分打包工具会据此判断兼容性范围数值过旧时校验环节会直接跳过后续打包步骤。一句话结论版本约束没跟上验证阶段悄悄劝退了 bundle。信号三安装脚本的分支里没有 MSIX 这条路自动化装机脚本 tools/install-powershell.ps1 第 280-284 行Windows 分支只有两个出口if ($UseMSI) { $packageName PowerShell-${release}-win-${architecture}.msi } else { $packageName PowerShell-${release}-win-${architecture}.zip }else一把兜底成 zip脚本不认 .msixbundle。结论就算发布页补上了包脚本也没法走 MSIX 这条路只会退回 zip。跟做四步把 MSIXBundle 找回来仓库本身只读建议git clone https://gitcode.com/GitHub_Trending/po/PowerShell到本地工作目录再按下面顺序改。第 1 步给打包链路补上 bundle 环节。打开 tools/packaging/packaging.psm1在第 3609 行makeappx pack之后追加一行 $makeappx pack /o /v /h SHA256 /d $ProductSourcePath /p ...$packageName.msix $makeappx bundle /d $ProductSourcePath /p ...$packageName.msixbundle白话pack 完单个 .msix 后再让 makeappx 把它们捆成 .msixbundle。第 2 步收紧清理规则别把 bundle 当旧缓存删掉。改动点在 CHANGELOG/7.4.md 第 552 行记录的 #24353 对应的流水线清理逻辑在打包工程的目标里改- Target NameCleanMsixBlob ... / Target NameCleanMsixBlob Condition!$([IO.File]::Exists($(OutputPath)PowerShell.msixbundle)) ... /白话只要 bundle 文件存在就跳过清理动作避免被误删。第 3 步把 manifest 版本约束抬到 Windows 11。打开 assets/AppxManifest.xml 第 23 行- TargetDeviceFamily ... MaxVersionTested10.0.18362.0 / TargetDeviceFamily ... MaxVersionTested10.0.22621.0 /白话22621 是 Windows 11 的版本号校验工具不再认为环境未测试打包步骤得以继续。第 4 步安装脚本加上 MSIX 这条路。打开 tools/install-powershell.ps1参数块第 44 行[switch] $UseMSI旁加一行[switch] $UseMSIX再把第 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 }白话优先判断 MSIX 开关命中才生成 .msixbundle 文件名否则维持原来的 msi/zip 行为。改完别急着发布三条验证命令命令一确认 bundle 产物存在Test-Path .\PowerShell-7.4.6-win-x64.msixbundle命令二拆开看 bundle 内部是否装着对应架构的 .msixmakeappx extract /f .\PowerShell-7.4.6-win-x64.msixbundle /o .\bundle_check Get-ChildItem .\bundle_check -Filter *.msix命令三确认安装脚本走的是新分支$script Get-Content tools/install-powershell.ps1 $script | Select-String UseMSIX为什么这三步能证明修好了第一条排除根本没生成第二条排除生成了但是空壳第三条排除脚本不认识这个包。三条全过才说明 MSIXBundle 从生成、内容到消费链路是完整的。四条防坑约定发布产物清单必须含 .msixbundle 的Test-Path断言参考 test/packaging/windows/ 的现有测试结构补一条。打包逻辑每次改动CI 里同时对比改动前后的产物清单别让少一个文件溜过 tools/releaseBuild/setReleaseTag.ps1 所在的发布流程。manifest 的MaxVersionTested跟着 CI 构建镜像的 Windows 版本一起更新发布流程见 docs/maintainers/releasing.md。安装脚本的包名分支要覆盖全部发布格式加新格式前先跑一遍 tools/install-powershell.ps1 的分支检查。写在最后根因是打包链路缺 bundle 步骤清理逻辑又帮倒忙。官方在 7.4.7 起已陆续修复发布流水线#24835见 CHANGELOG/7.4.md能升级就升级急着用 7.4.6 的环境照上文四步改完、三验通过再发布。【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考