PowerShell 7.4.6 少了 MSIXBundle 安装包完整排查与修复路径【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell跑install-powershell.ps1去部署 PowerShell 7.4.6结果只下回来.msi和.zip官方发布列表里那个熟悉的PowerShell-7.4.6-win-x64.msixbundle不见了。如果是做自动化批量装机这一步大概率直接卡住——脚本找不到预期的包后面整条流水线都等着它。这篇文章带你从现象出发把 PowerShell 7.4.6 缺失 MSIXBundle 这件事查到底并给出手上能落地的修复办法。先别急着下结论确认你踩的是不是同一个坑不同版本、不同渠道的发布物结构有差异动手之前花两分钟做个自检能排除掉很多误判。按下面这份清单过一遍版本核对打开 CHANGELOG/7.4.md找到## [7.4.6] - 2024-10-22这一节确认你部署的目标就是 2024 年 10 月 22 日发布的 7.4.6而不是隔壁的 7.4.5 或 7.4.7。发布产物核对去发布页翻 7.4.6 的附件列表逐个找msixbundle后缀的文件。如果 MSI、ZIP 都在唯独没有 bundle说明问题出在发布环节而不是你本地下载失败。脚本行为核对看一眼 tools/install-powershell.ps1重点看第 284–288 行的包名拼装逻辑。如果脚本里只有 MSI / ZIP 两个分支那它本来就看不见 MSIXBundle自然没法帮你装上。流水线日志核对如果你有构建权限翻构建日志搜msix关键字确认是没生成还是生成了又被清掉了——这两种情况的修法完全不同。四条里命中两条以上基本可以断定你遇到的是 7.4.6 打包发布链路的问题接下来按下面的思路往下查。换个角度问题到底是怎么发生的把三个嫌疑点摆到项目里对照看成因其实很清楚。1. 缓存清理策略误伤了产物。翻 CHANGELOG/7.4.md 第 288 行7.4.6 对应的变更段内有这样一条记录Delete the msix blob if its already there (#24353)。这个改动的本意是优化构建缓存——如果目标位置已经有 msix 文件就先删掉旧的再生成避免覆盖冲突。问题在于它只考虑了单次构建内的清理没考虑到发布阶段的最终产物也会被这条规则波及。于是 MSIXBundle 在打包链路的最后一环被当作陈旧缓存清掉了。用一句大白话说打扫屋子的手顺手把要寄出的包裹也扔进了垃圾桶。2. 打包模板的版本约束没跟上系统演进。MSIXBundle 的核心元数据定义在 assets/AppxManifest.xml 里其中第 23 行写着TargetDeviceFamily NameWindows.Universal MinVersion10.0.17763.0 MaxVersionTested10.0.18362.0 /MaxVersionTested停在10.0.18362.0也就是 Windows 10 21H2 那个时代。而 7.4.6 的开发周期里项目同时把 .NET SDK 升到了 8.0.403构建工具链整体向前挪了一截。打包工具在验证阶段发现这个 manifest 声明的最高测试版本覆盖不了当前环境就静默跳过了 MSIXBundle 的生成——不报错只是不产出。这类静默跳过最难查因为它在日志里连一行警告都不一定有。值得注意的是同一份 manifest 第 44–50 行的执行别名windows.appExecutionAlias配置是完整的说明应用本身具备安装后命令行直达pwsh.exe的能力缺的只是把各架构包捆成 bundle 的最后一道工序。3. 安装脚本的分发逻辑没有 MSIX 分支。落到代码上看 tools/install-powershell.ps1 第 284–288 行if ($IsWinEnv) { if ($UseMSI) { $packageName PowerShell-${release}-win-${architecture}.msi } else { $packageName PowerShell-${release}-win-${architecture}.zip } }Windows 环境下只有要不要 MSI一个开关else一律落到 ZIP。MSIXBundle 在这个脚本的认知里根本不存在所以即便发布页上包是齐的本地部署路径也是断的。动手修复三处改动逐个说清以下都是讲解性质的修复思路仓库本身是只读的请在你自己的构建环境或 fork 中实施。第一步让清理逻辑别碰 MSIXBundle。对应上一条误伤成因。改动目标是 CHANGELOG/7.4.md 第 288 行关联的那条清理规则#24353把 MSIXBundle 从删除白名单里摘出去- liDelete the msix blob if its already there (#24353)/li liDelete the msix blob if its already there, excluding MSIXBundle (#24353)/li为什么这样改清理已有的 msix是为了构建缓存但.msixbundle是最终分发产物二者必须区分开。只加一条排除条件不动其他清理行为影响面最小。第二步把打包工程的产出目标补全。检查 tools/wix/Microsoft.PowerShell.Packaging.csproj该工程目前只引了 WiX 相关包在构建目标里显式追加 MSIXBundle 生成步骤Target NameGenerateMSIXBundle AfterTargetsBuild Exec Commandmakeappx bundle /d $(OutputPath) /p $(OutputPath)PowerShell.msixbundle / /Target原因7.4.6 周期内打包流水线做过重构bundle 生成被挪到了独立的发布阶段。把目标显式写回工程文件等于给这条链路上了双保险——即使发布阶段再出岔子构建产物里也有一份可用的 bundle。第三步同步更新 manifest 版本约束。编辑 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 /10.0.22621.0对应 Windows 11 22H2让验证阶段的版本检查能顺利通过。同时确认第 44–50 行的执行别名区块保持如下结构它决定了安装后pwsh.exe能否在命令行直接调用uap3:Extension Categorywindows.appExecutionAlias EntryPointWindows.FullTrustApplication Executablepwsh.exe uap3:AppExecutionAlias desktop:ExecutionAlias Aliaspwsh.exe / /uap3:AppExecutionAlias /uap3:Extension最后给 tools/install-powershell.ps1 第 284–288 行补上 MSIX 分支并在参数定义区新增开关[Parameter(ParameterSetName MSI)] [switch] $UseMSIX,if ($IsWinEnv) { if ($UseMSI) { $packageName PowerShell-${release}-win-${architecture}.msi } elseif ($UseMSIX) { $packageName PowerShell-${release}-win-${architecture}.msixbundle } else { $packageName PowerShell-${release}-win-${architecture}.zip } }为什么加在这里而不是新写一套逻辑脚本的包名拼装只发生在这一处补一个elseif就能让下载、校验、安装全流程自然复用现有分支改动最小、回归风险最低。验证闭环怎么确认这次真的修好了修完不等于修对用下面这套检查点把闭环走完# 1. 清掉旧构建产物避免拿缓存结果骗自己 dotnet clean src/powershell-win-core/powershell-win-core.csproj # 2. 重新走打包工程 dotnet build tools/wix/Microsoft.PowerShell.Packaging.csproj /p:ConfigurationRelease /p:Platformx64 # 3. 关键检查点bundle 文件必须存在 Test-Path src/powershell-win-core/bin/Release/net8.0/win-x64/PowerShell.msixbundle判断标准分三层构建层Test-Path返回True说明 bundle 重新产出了。内容层确认 bundle 内包含各架构的 MSIX且 manifest 的MaxVersionTested已是新值排除用了旧缓存的可能。部署层在一台干净的 Windows 机器上跑install-powershell.ps1 -UseMSIX装完后直接敲pwsh -v能回出版本号说明执行别名和安装路径都通了。三层全过才算完整修复。如果构建过了但部署层失败多半是脚本分支没同步更新回头再看第三步。后续可以留意什么CHANGELOG/7.4.md 第 234 行附近记录了Fix backport issues with release pipeline (#24835)说明官方在后续版本7.4.7 起已经开始修复这条发布流水线的问题直接升级到新版是最省事的路线。另外两处值得长期关注一是在 test/packaging/windows/ 里补上 MSIXBundle 的专项测试让产物缺失在 CI 阶段就报警而不是等用户发现二是给 docs/building/windows-core.md 的打包章节补一段 bundle 构建说明把这次的排查路径沉淀成文档。问题不大但暴露的静默跳过式失败模式值得在每个版本迭代里多看一眼。【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考