PowerShell 7.4.6 Windows MSIX 包缺失从发布流水线到安装脚本的完整实操复盘【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell打开 PowerShell 7.4.6 的 Windows 安装资源时msi 和 zip 都在唯独.msixbundle不见了给 install-powershell.ps1 加上-UseMSIX也会被拒绝为未知参数。这次 PowerShell 7.4.6 MSIXBundle 缺失的核心是发布流水线的清理逻辑动到了打包产物。本文带你从现象一路排到 changelog 与打包配置里的根因再用三处最小改动修好它。 先复现再动手7.4.6 MSIX 包缺失的最小复现步骤环境要求只有一台 Windows 10/11外加一份已切到 v7.4.6 的 PowerShell 仓库git clone https://gitcode.com/GitHub_Trending/po/PowerShell cd PowerShell; git checkout v7.4.6出现以下两种现象之一才算踩中这个问题v7.4.6 的发布资产里只有.msi和.zip没有*.msixbundle7.4 之前发布渠道是上传过 msixbundle 的见 CHANGELOG/7.2.md 中 Suppress prompting when uploading the msixbundle package to blob 一条安装脚本不认识 MSIX 开关PS .\tools\install-powershell.ps1 -UseMSIX install-powershell.ps1: A parameter cannot be found that matches parameter name UseMSIX.非 Windows 系统不用排查——MSIX 是 Windows 专属打包格式这个问题只影响 Windows 侧。 逐层排查从发布记录到打包脚本的排查路径先看 changelog7.4.6 是一个动了流水线的发布版结论先行7.4.6 的发布记录以构建打包改动为主其中 msix blob 清理一项最可疑。CHANGELOG/7.4.md 中 7.4.6 小节发布于 2024-10-22列了二十多项流水线变更第 552 行是重点liDelete the msix blob if its already there (#24353)/li为什么一个清理缓存的改动会删掉发布包因为它的判定条件是blob 已存在就删——回合并入时若存储账号里残留了旧 msix 产物新生成的 msixbundle 会被当作待清理项一起移除。这一点是推断自 changelog 条目的流水线文件在 CI 配置仓库、不在本仓库。旁证是第 498 行紧接着的 7.4.7 小节就有一条 Fix backport issues with release pipeline (#24835)说明当时发布流水线本身就在反复修补。再看打包配置manifest 模板没坏但受测版本偏旧第二个结论MSIX 生成用的模板本身是完整的问题出在声明的平台版本上限偏低。assets/AppxManifest.xml 第 23 行声明了平台兼容范围TargetDeviceFamily NameWindows.Universal MinVersion10.0.17763.0 MaxVersionTested10.0.18362.0 /MaxVersionTested10.0.18362.0停在 Windows 10 1909 的 build明显低于 Windows 11 的 22621 build。打包流水线的校验阶段若在较新系统上运行 makeappx validate可能对这类未受测平台降权甚至跳过——此句为推断自版本号。好消息是执行别名声明第 46-50 行完整安装后pwsh.exe可直接调用这部分不是病灶。最后看脚本Windows 分支只有 msi 和 zip 两条路第三个结论即便流水线产出了 msixbundle官方安装入口也没有承接它的通路。tools/install-powershell.ps1 参数区第 44 行只有-UseMSI一个 Windows 专属开关第 280-284 行的包名逻辑只有两个分支if ($UseMSI) { $packageName PowerShell-${release}-win-${architecture}.msi } else { $packageName PowerShell-${release}-win-${architecture}.zip }没有第三条路。而测试侧 test/packaging/windows/ 里只有exe.tests.ps1和msi.tests.ps1两个测试文件MSIX 零覆盖——产物缺失要到用户下载时才会暴露。️ 最小改动修复让 msixbundle 回来的三处修改按依赖顺序先 manifest再安装脚本最后流水线清理逻辑。第一处抬升 manifest 的 MaxVersionTested这处改动在平台兼容性声明行把受测上限提到 Windows 11 22H2 的 build 号assets/AppxManifest.xml- TargetDeviceFamily NameWindows.Universal MinVersion10.0.17763.0 MaxVersionTested10.0.18362.0 / TargetDeviceFamily NameWindows.Universal MinVersion10.0.17763.0 MaxVersionTested10.0.22621.0 /为什么这么改MaxVersionTested声明的是此包验证过的最高系统 build写低了会让校验环节把它当未受测的旧包对待。改完能看到在 Windows 11 机器上对生成的 msix 跑 makeappx validate不再出现平台版本告警。第二处安装脚本补上 -UseMSIX 参数与包名分支参数块第 44 行附近先加开关让调用方有这个选项tools/install-powershell.ps1[Parameter(ParameterSetName MSI)] [switch] $EnablePSRemoting [Parameter()] [switch] $UseMSIX )包名分支第 280-284 行再补一条 msixbundle 通路让下载 URL第 291 行能自动拼出新包名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 }第 323 行附近的安装执行段要配套-UseMSIX时不走解压改调Add-AppxPackage注册包。为什么这么改msixbundle 由此成为与 msi/zip 平级的一等安装选项而不是脚本盲区。改完能看到.\install-powershell.ps1 -UseMSIX不再报参数错误拉取到的就是 .msixbundle 文件。第三处流水线清理步骤加白名单推断自 changelog此改动对应 CHANGELOG/7.4.md 第 552 行的 #24353 条目流水线文件在 CI 配置仓库不在本仓库以下为示意 diff# Delete the msix blob if its already there - match: *.msix* match: *.msix # 保留 *.msixbundle 不被清理为什么这么改根因就是清理条件没排除最终产物把 msixbundle 从清理名单里摘出去。改完能看到即使存储账号残留旧产物重跑发布流水线也不会再删掉 bundle。改动点速查表文件改动原因验证信号assets/AppxManifest.xmlMaxVersionTested → 10.0.22621.0校验环节拒收旧声明版本validate 无平台告警tools/install-powershell.ps1新增 -UseMSIX 参数与包名分支安装入口缺 msix 通路能下载并安装 .msixbundle流水线清理步骤清理条件排除 *.msixbundle清理逻辑误删发布产物重跑流水线不删 bundle✅ 构建与验收makeappx 到安装产物的验证序列仓库内的 MSIX 打包入口是 tools/packaging/packaging.psm1 的New-MSIXPackage函数第 3451 行它内部调用 Windows 10 SDK 的 makeappx.exe 完成 pack。完整验收序列在仓库根目录执行# 1) 导入打包模块 Import-Module .\tools\packaging\packaging.psm1 # 2) 基于主构建产物生成单架构 msix路径以你的构建输出为准 New-MSIXPackage -ProductVersion 7.4.6 -Architecture x64 -ProductSourcePath src\powershell-win-core\bin\Release\net8.0\win-x64\publish # 3) 打包 bundle 并验证/d 指向含 msix 的目录/p 指定输出 makeappx bundle /d msix 所在目录 /p PowerShell-7.4.6-win.msixbundle makeappx validate /v /p PowerShell-7.4.6-win.msixbundle Test-Path .\PowerShell-7.4.6-win.msixbundle成功标志Test-Path返回True、validate 无错误、Add-AppxPackage装完后Get-AppxPackage *PowerShell*能查到 7.4.6。仍失败的常见信号有三类报Could not locate makeappx.exe, make sure Windows 10 SDK is installedpackaging.psm1 第 3506 行的原始报错→ 装 Windows SDKvalidate 提示平台版本 → 回看第一处改动没生效bundle 里只有单架构 →/d要把各架构 msix 都放齐别只放一个。️ 让它不再复现打包测试与依赖治理的三个缺口补打包专项测试test/packaging/windows/ 目前只有 exe 和 msi 两个测试文件加一个 msix 验证测试产物存在 可被 Add-AppxPackage 安装对每个发布版跑一遍。给依赖治理加回滚检查定期跑 tools/ComponentGovernance/ComponentGovernance.psm1 的扫描像 7.4.6 那次 .NET 8.0.403 SDK 升级见 CHANGELOG/7.4.md 7.4.6 小节时同一 PR 里顺带确认打包流水线没被波及。文档补全把 makeappx 依赖、msixbundle 产物位置写进 docs/building/windows-core.md下次排查不用翻 changelog 挖线索。根因是发布流水线里一行打包产物清理误删了整个发布。若你正受影响直接升级到 7.4.7 及以上并在安装前核对资产里有没有 msixbundle。【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 PowerShell 7.4.6 Windows MSIX 包缺失：从发布流水线到安装脚本的完整实操复盘
PowerShell 7.4.6 Windows MSIX 包缺失从发布流水线到安装脚本的完整实操复盘【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell打开 PowerShell 7.4.6 的 Windows 安装资源时msi 和 zip 都在唯独.msixbundle不见了给 install-powershell.ps1 加上-UseMSIX也会被拒绝为未知参数。这次 PowerShell 7.4.6 MSIXBundle 缺失的核心是发布流水线的清理逻辑动到了打包产物。本文带你从现象一路排到 changelog 与打包配置里的根因再用三处最小改动修好它。 先复现再动手7.4.6 MSIX 包缺失的最小复现步骤环境要求只有一台 Windows 10/11外加一份已切到 v7.4.6 的 PowerShell 仓库git clone https://gitcode.com/GitHub_Trending/po/PowerShell cd PowerShell; git checkout v7.4.6出现以下两种现象之一才算踩中这个问题v7.4.6 的发布资产里只有.msi和.zip没有*.msixbundle7.4 之前发布渠道是上传过 msixbundle 的见 CHANGELOG/7.2.md 中 Suppress prompting when uploading the msixbundle package to blob 一条安装脚本不认识 MSIX 开关PS .\tools\install-powershell.ps1 -UseMSIX install-powershell.ps1: A parameter cannot be found that matches parameter name UseMSIX.非 Windows 系统不用排查——MSIX 是 Windows 专属打包格式这个问题只影响 Windows 侧。 逐层排查从发布记录到打包脚本的排查路径先看 changelog7.4.6 是一个动了流水线的发布版结论先行7.4.6 的发布记录以构建打包改动为主其中 msix blob 清理一项最可疑。CHANGELOG/7.4.md 中 7.4.6 小节发布于 2024-10-22列了二十多项流水线变更第 552 行是重点liDelete the msix blob if its already there (#24353)/li为什么一个清理缓存的改动会删掉发布包因为它的判定条件是blob 已存在就删——回合并入时若存储账号里残留了旧 msix 产物新生成的 msixbundle 会被当作待清理项一起移除。这一点是推断自 changelog 条目的流水线文件在 CI 配置仓库、不在本仓库。旁证是第 498 行紧接着的 7.4.7 小节就有一条 Fix backport issues with release pipeline (#24835)说明当时发布流水线本身就在反复修补。再看打包配置manifest 模板没坏但受测版本偏旧第二个结论MSIX 生成用的模板本身是完整的问题出在声明的平台版本上限偏低。assets/AppxManifest.xml 第 23 行声明了平台兼容范围TargetDeviceFamily NameWindows.Universal MinVersion10.0.17763.0 MaxVersionTested10.0.18362.0 /MaxVersionTested10.0.18362.0停在 Windows 10 1909 的 build明显低于 Windows 11 的 22621 build。打包流水线的校验阶段若在较新系统上运行 makeappx validate可能对这类未受测平台降权甚至跳过——此句为推断自版本号。好消息是执行别名声明第 46-50 行完整安装后pwsh.exe可直接调用这部分不是病灶。最后看脚本Windows 分支只有 msi 和 zip 两条路第三个结论即便流水线产出了 msixbundle官方安装入口也没有承接它的通路。tools/install-powershell.ps1 参数区第 44 行只有-UseMSI一个 Windows 专属开关第 280-284 行的包名逻辑只有两个分支if ($UseMSI) { $packageName PowerShell-${release}-win-${architecture}.msi } else { $packageName PowerShell-${release}-win-${architecture}.zip }没有第三条路。而测试侧 test/packaging/windows/ 里只有exe.tests.ps1和msi.tests.ps1两个测试文件MSIX 零覆盖——产物缺失要到用户下载时才会暴露。️ 最小改动修复让 msixbundle 回来的三处修改按依赖顺序先 manifest再安装脚本最后流水线清理逻辑。第一处抬升 manifest 的 MaxVersionTested这处改动在平台兼容性声明行把受测上限提到 Windows 11 22H2 的 build 号assets/AppxManifest.xml- TargetDeviceFamily NameWindows.Universal MinVersion10.0.17763.0 MaxVersionTested10.0.18362.0 / TargetDeviceFamily NameWindows.Universal MinVersion10.0.17763.0 MaxVersionTested10.0.22621.0 /为什么这么改MaxVersionTested声明的是此包验证过的最高系统 build写低了会让校验环节把它当未受测的旧包对待。改完能看到在 Windows 11 机器上对生成的 msix 跑 makeappx validate不再出现平台版本告警。第二处安装脚本补上 -UseMSIX 参数与包名分支参数块第 44 行附近先加开关让调用方有这个选项tools/install-powershell.ps1[Parameter(ParameterSetName MSI)] [switch] $EnablePSRemoting [Parameter()] [switch] $UseMSIX )包名分支第 280-284 行再补一条 msixbundle 通路让下载 URL第 291 行能自动拼出新包名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 }第 323 行附近的安装执行段要配套-UseMSIX时不走解压改调Add-AppxPackage注册包。为什么这么改msixbundle 由此成为与 msi/zip 平级的一等安装选项而不是脚本盲区。改完能看到.\install-powershell.ps1 -UseMSIX不再报参数错误拉取到的就是 .msixbundle 文件。第三处流水线清理步骤加白名单推断自 changelog此改动对应 CHANGELOG/7.4.md 第 552 行的 #24353 条目流水线文件在 CI 配置仓库不在本仓库以下为示意 diff# Delete the msix blob if its already there - match: *.msix* match: *.msix # 保留 *.msixbundle 不被清理为什么这么改根因就是清理条件没排除最终产物把 msixbundle 从清理名单里摘出去。改完能看到即使存储账号残留旧产物重跑发布流水线也不会再删掉 bundle。改动点速查表文件改动原因验证信号assets/AppxManifest.xmlMaxVersionTested → 10.0.22621.0校验环节拒收旧声明版本validate 无平台告警tools/install-powershell.ps1新增 -UseMSIX 参数与包名分支安装入口缺 msix 通路能下载并安装 .msixbundle流水线清理步骤清理条件排除 *.msixbundle清理逻辑误删发布产物重跑流水线不删 bundle✅ 构建与验收makeappx 到安装产物的验证序列仓库内的 MSIX 打包入口是 tools/packaging/packaging.psm1 的New-MSIXPackage函数第 3451 行它内部调用 Windows 10 SDK 的 makeappx.exe 完成 pack。完整验收序列在仓库根目录执行# 1) 导入打包模块 Import-Module .\tools\packaging\packaging.psm1 # 2) 基于主构建产物生成单架构 msix路径以你的构建输出为准 New-MSIXPackage -ProductVersion 7.4.6 -Architecture x64 -ProductSourcePath src\powershell-win-core\bin\Release\net8.0\win-x64\publish # 3) 打包 bundle 并验证/d 指向含 msix 的目录/p 指定输出 makeappx bundle /d msix 所在目录 /p PowerShell-7.4.6-win.msixbundle makeappx validate /v /p PowerShell-7.4.6-win.msixbundle Test-Path .\PowerShell-7.4.6-win.msixbundle成功标志Test-Path返回True、validate 无错误、Add-AppxPackage装完后Get-AppxPackage *PowerShell*能查到 7.4.6。仍失败的常见信号有三类报Could not locate makeappx.exe, make sure Windows 10 SDK is installedpackaging.psm1 第 3506 行的原始报错→ 装 Windows SDKvalidate 提示平台版本 → 回看第一处改动没生效bundle 里只有单架构 →/d要把各架构 msix 都放齐别只放一个。️ 让它不再复现打包测试与依赖治理的三个缺口补打包专项测试test/packaging/windows/ 目前只有 exe 和 msi 两个测试文件加一个 msix 验证测试产物存在 可被 Add-AppxPackage 安装对每个发布版跑一遍。给依赖治理加回滚检查定期跑 tools/ComponentGovernance/ComponentGovernance.psm1 的扫描像 7.4.6 那次 .NET 8.0.403 SDK 升级见 CHANGELOG/7.4.md 7.4.6 小节时同一 PR 里顺带确认打包流水线没被波及。文档补全把 makeappx 依赖、msixbundle 产物位置写进 docs/building/windows-core.md下次排查不用翻 changelog 挖线索。根因是发布流水线里一行打包产物清理误删了整个发布。若你正受影响直接升级到 7.4.7 及以上并在安装前核对资产里有没有 msixbundle。【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考