PowerShell 7.4.6 MSIXBundle 缺失完整排障与本地修复指南【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell把部署脚本的安装器从 MSI 切到 MSIXBundle 后你去拿 PowerShell 7.4.6 的发布产物发现里面只有.msi和.zip.msixbundle不见了。自动化流水线在下载这一步直接报错而你自己按打包入口重新构建时msix 中间产物又在中途被清掉bundle 阶段拿不到输入。 机制拆解MSIXBundle 打包流程与 AppxManifest 配置先看正常情况下这条链路怎么走异常点才能对得上号。Windows 侧发布产物分两条线MSI 走 WiX 打包项目MSIX 走打包脚本。MSIX 的核心是 packaging.psm1 里的New-MSIXPackage函数流程是三步读取模板 AppxManifest.xml把其中的$PRODUCTNAME$、$ARCH$、$VERSION$等占位符替换成当前构建参数用 Windows 10 SDK 的makepri处理资源再用makeappx pack打包出$packageName.msixpackaging.psm1 第 3609 行附近流水线把各架构的 msix 合并成单个.msixbundle供分发。发布类型由 setReleaseTag.ps1 决定它会把MSIX_TYPEpreview或release写进流水线变量区分 LTS 和 Stable 两条包。清单本身也约束着目标系统AppxManifest.xml 第 23 行TargetDeviceFamily NameWindows.Universal MinVersion10.0.17763.0 MaxVersionTested10.0.18362.0 /MaxVersionTested停在 10.0.18362.02019 年的版本号意味着在更新的系统上makepri 验证阶段会报未测试警告。这条链路上任何一环丢了 msixbundle 都出不来。而 7.4.6 的变更里恰好有一条 CHANGELOG/7.4.md 第 552 行记录的 Delete the msix blob if its already there (#24353)。它的本意是清理构建缓存里的陈旧 blob但执行位置排在 bundle 生成之前上一轮生成的 msix 被当成陈旧产物删掉bundle 阶段找不到输入发布产物就缺了。定位路径MSIXBundle 缺失的四步排查顺序按从表象到根源的顺序走每一步都有可验证的判断依据第一步确认缺的是哪个产物。下载 7.4.6 的发布包列出文件Get-ChildItem看到.msi、.zip都在、只有.msixbundle缺失说明公共上传环节正常问题在 MSIX 独有的阶段不必去查签名或上传脚本。第二步对照变更日志。在 CHANGELOG/7.4.md 的 7.4.6 小节Bump .NET SDK to 8.0.403 展开块里#24353 的清理变更和 SDK 升级出现在同一批。清理逻辑 工具链升级同版本落地是典型的流水线顺序问题组合怀疑点直接指向清理步骤。第三步锁定生成入口排除本地环境问题。在本地副本里执行Select-String -Path tools/packaging/packaging.psm1 -Pattern function New-MSIXPackageNew-MSIXPackage会先找makeappx.exe找不到就抛 Could not locate makeappx.exe, make sure Windows 10 SDK is installed。如果你的报错不是这一句说明 SDK 没问题继续往产物流转上查而不是装 SDK 绕圈。第四步用上游修复反向验证。7.4.7 小节里有 Fix backport issues with release pipeline (#24835) 和 Take the newest windows signature nuget packages (#24818)。如果你只是使用者升级到 7.4.7 后产物恢复完整即可确认根因就是流水线顺序问题不需要再深挖。修复与验证本地重建 msix 并验证产物上面第四步覆盖的是直接用官方发布包的情况。如果你需要自己构建 7.4.6 标签比如给内网环境出离线包把仓库克隆到本地后只改自己这份副本的两处改完不要推回上游git clone https://gitcode.com/GitHub_Trending/po/PowerShell改动一blob 清理步骤加保留条件。让 Delete the msix blob 这一步跳过本次构建生成的 msix 文件。为什么改这里而不是在 bundle 步骤里重新生成重打一次 msix 要再过 makepri 和签名校验耗时且可能再次触发缓存竞争保留输入文件是最小改动。改动二更新本地 AppxManifest.xml 的版本上限。把MaxVersionTested提到与构建机一致的版本消除新系统上的未测试警告避免验证步骤因警告被策略拦截TargetDeviceFamily NameWindows.Universal MinVersion10.0.17763.0 MaxVersionTested10.0.22621.0 /改完直接在仓库根目录重新打包并检查产物打包命令的形式与 releasing.md 中的示例一致Start-PSPackage -Type msix -ReleaseTag v7.4.6 -WindowsRuntime win-x64 Get-ChildItem -Recurse -Filter *.msix # 应出现各架构的 msix Get-ChildItem -Recurse -Filter *.msixbundle # 应出现合并后的 bundle两个过滤器都能列出文件即验证通过。想更严格一点可以用makepri validate对 msix 做最终校验确认清单在目标系统上合法。顺带两个延伸要点一是New-MSIXPackage查找makeappx.exe的顺序是 PATH、$SystemDrive\makeappx、Windows Kits\10\bin\*\x64本地报找不到 makeappx 时先装 Windows 10 SDK这和发布产物缺失是两码事二是如果你只消费官方发布渠道直接升级到 7.4.7 或更新版本即可#24835 已经把流水线顺序问题修掉了本地这两处改动只在自建 7.4.6 时才需要。【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
PowerShell 7.4.6 MSIXBundle 缺失：完整排障与本地修复指南
PowerShell 7.4.6 MSIXBundle 缺失完整排障与本地修复指南【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell把部署脚本的安装器从 MSI 切到 MSIXBundle 后你去拿 PowerShell 7.4.6 的发布产物发现里面只有.msi和.zip.msixbundle不见了。自动化流水线在下载这一步直接报错而你自己按打包入口重新构建时msix 中间产物又在中途被清掉bundle 阶段拿不到输入。 机制拆解MSIXBundle 打包流程与 AppxManifest 配置先看正常情况下这条链路怎么走异常点才能对得上号。Windows 侧发布产物分两条线MSI 走 WiX 打包项目MSIX 走打包脚本。MSIX 的核心是 packaging.psm1 里的New-MSIXPackage函数流程是三步读取模板 AppxManifest.xml把其中的$PRODUCTNAME$、$ARCH$、$VERSION$等占位符替换成当前构建参数用 Windows 10 SDK 的makepri处理资源再用makeappx pack打包出$packageName.msixpackaging.psm1 第 3609 行附近流水线把各架构的 msix 合并成单个.msixbundle供分发。发布类型由 setReleaseTag.ps1 决定它会把MSIX_TYPEpreview或release写进流水线变量区分 LTS 和 Stable 两条包。清单本身也约束着目标系统AppxManifest.xml 第 23 行TargetDeviceFamily NameWindows.Universal MinVersion10.0.17763.0 MaxVersionTested10.0.18362.0 /MaxVersionTested停在 10.0.18362.02019 年的版本号意味着在更新的系统上makepri 验证阶段会报未测试警告。这条链路上任何一环丢了 msixbundle 都出不来。而 7.4.6 的变更里恰好有一条 CHANGELOG/7.4.md 第 552 行记录的 Delete the msix blob if its already there (#24353)。它的本意是清理构建缓存里的陈旧 blob但执行位置排在 bundle 生成之前上一轮生成的 msix 被当成陈旧产物删掉bundle 阶段找不到输入发布产物就缺了。定位路径MSIXBundle 缺失的四步排查顺序按从表象到根源的顺序走每一步都有可验证的判断依据第一步确认缺的是哪个产物。下载 7.4.6 的发布包列出文件Get-ChildItem看到.msi、.zip都在、只有.msixbundle缺失说明公共上传环节正常问题在 MSIX 独有的阶段不必去查签名或上传脚本。第二步对照变更日志。在 CHANGELOG/7.4.md 的 7.4.6 小节Bump .NET SDK to 8.0.403 展开块里#24353 的清理变更和 SDK 升级出现在同一批。清理逻辑 工具链升级同版本落地是典型的流水线顺序问题组合怀疑点直接指向清理步骤。第三步锁定生成入口排除本地环境问题。在本地副本里执行Select-String -Path tools/packaging/packaging.psm1 -Pattern function New-MSIXPackageNew-MSIXPackage会先找makeappx.exe找不到就抛 Could not locate makeappx.exe, make sure Windows 10 SDK is installed。如果你的报错不是这一句说明 SDK 没问题继续往产物流转上查而不是装 SDK 绕圈。第四步用上游修复反向验证。7.4.7 小节里有 Fix backport issues with release pipeline (#24835) 和 Take the newest windows signature nuget packages (#24818)。如果你只是使用者升级到 7.4.7 后产物恢复完整即可确认根因就是流水线顺序问题不需要再深挖。修复与验证本地重建 msix 并验证产物上面第四步覆盖的是直接用官方发布包的情况。如果你需要自己构建 7.4.6 标签比如给内网环境出离线包把仓库克隆到本地后只改自己这份副本的两处改完不要推回上游git clone https://gitcode.com/GitHub_Trending/po/PowerShell改动一blob 清理步骤加保留条件。让 Delete the msix blob 这一步跳过本次构建生成的 msix 文件。为什么改这里而不是在 bundle 步骤里重新生成重打一次 msix 要再过 makepri 和签名校验耗时且可能再次触发缓存竞争保留输入文件是最小改动。改动二更新本地 AppxManifest.xml 的版本上限。把MaxVersionTested提到与构建机一致的版本消除新系统上的未测试警告避免验证步骤因警告被策略拦截TargetDeviceFamily NameWindows.Universal MinVersion10.0.17763.0 MaxVersionTested10.0.22621.0 /改完直接在仓库根目录重新打包并检查产物打包命令的形式与 releasing.md 中的示例一致Start-PSPackage -Type msix -ReleaseTag v7.4.6 -WindowsRuntime win-x64 Get-ChildItem -Recurse -Filter *.msix # 应出现各架构的 msix Get-ChildItem -Recurse -Filter *.msixbundle # 应出现合并后的 bundle两个过滤器都能列出文件即验证通过。想更严格一点可以用makepri validate对 msix 做最终校验确认清单在目标系统上合法。顺带两个延伸要点一是New-MSIXPackage查找makeappx.exe的顺序是 PATH、$SystemDrive\makeappx、Windows Kits\10\bin\*\x64本地报找不到 makeappx 时先装 Windows 10 SDK这和发布产物缺失是两码事二是如果你只消费官方发布渠道直接升级到 7.4.7 或更新版本即可#24835 已经把流水线顺序问题修掉了本地这两处改动只在自建 7.4.6 时才需要。【免费下载链接】PowerShellPowerShell for every system!项目地址: https://gitcode.com/GitHub_Trending/po/PowerShell创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
