Remove MSI from publishing pipeline#27213
Merged
TravisEz13 merged 9 commits intoPowerShell:masterfrom Apr 16, 2026
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR removes Windows MSI installer creation/signing/publishing from the build + release toolchain, standardizing Windows distribution on .zip and .msix and deleting WiX/MSI-related assets and tests.
Changes:
- Removed MSI (and WiX/MSI helper functions) from
Start-PSPackageand related packaging exports. - Updated OneBranch pipeline templates to stop producing/downloading/uploading MSI artifacts and to validate only ZIP names.
- Cleaned up MSI-only assets/tests (WiX sources, Microsoft Update registration script, installer tests) and removed the script from the Windows publish output.
Reviewed changes
Copilot reviewed 16 out of 19 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| tools/packaging/packaging.psm1 | Removes MSI package type and deletes WiX/MSI packaging implementation. |
| tools/packaging/packaging.psd1 | Updates exported functions list (but needs further cleanup per comments). |
| tools/packaging/boms/windows.json | Removes BOM entry for RegisterMicrosoftUpdate.ps1. |
| tools/ci.psm1 | Stops producing/testing MSI/EXE packages in Invoke-CIFinish; shifts to zip/msix types. |
| test/powershell/Installer/WindowsInstaller.Tests.ps1 | Removes MSI/WiX-specific scenario tests. |
| src/powershell-win-core/powershell-win-core.csproj | Stops publishing RegisterMicrosoftUpdate.ps1 into the Windows output. |
| assets/wix/Product.wxs | Deletes MSI WiX authoring for the product. |
| assets/wix/bundle.wxs | Deletes EXE bootstrapper WiX authoring. |
| assets/wix/ExeLicense.rtf | Deletes WiX bootstrapper license asset. |
| assets/MicrosoftUpdate/RegisterMicrosoftUpdate.ps1 | Removes MSI custom-action helper used to opt into Microsoft Update. |
| .pipelines/templates/packaging/windows/package.yml | Removes MSI from Windows package build list; builds zip/msix only. |
| .pipelines/templates/packaging/windows/sign.yml | Removes MSI/EXE signing logic (but currently also removes MSIX signing). |
| .pipelines/templates/uploadToAzure.yml | Stops downloading/uploading MSI (and EXE download patterns) for Windows packages. |
| .pipelines/templates/release-validate-packagenames.yml | Updates Windows package-name validation to ZIP-only. |
| .pipelines/templates/release-githubNuget.yml | Ensures MSI files (if present) are removed before GitHub release publishing. |
| .github/CONTRIBUTING.md | Updates local packaging guidance away from MSI (but leaves ambiguous wording). |
| assets/wix/WixUIInfoIco.png | WiX UI asset present in PR (binary/no textual diff). |
| assets/wix/WixUIDialogBmp.png | WiX UI asset present in PR (binary/no textual diff). |
| assets/wix/WixUIBannerBmp.png | WiX UI asset present in PR (binary/no textual diff). |
Comments suppressed due to low confidence (1)
.pipelines/templates/packaging/windows/sign.yml:108
$packageTypesstill includes'exe'for x64/x86/arm64, but this PR removed MSI→EXE generation and upload/download of*.exeelsewhere. As written,Get-ChildItem ... | Select-Object -ExpandProperty FullNamewill produce$nullwhen no EXE exists andCopy-Item -Path $exePkgPathwill fail. Either removeexefrom$packageTypesor guard the copy with an explicit empty-check and a clear error/warning.
$packageTypes = switch ($runtime) {
'x64' { @('zip', 'msix', 'exe') }
'x86' { @('zip', 'msix', 'exe') }
'arm64' { @('zip', 'msix', 'exe') }
'fxdependent' { 'fxdependent' }
'fxdependentWinDesktop' { 'fxdependent-win-desktop' }
'minsize' { 'min-size' }
}
if (-not (Test-Path $(ob_outputDirectory))) {
New-Item -ItemType Directory -Path $(ob_outputDirectory) -Force
}
if ($packageTypes -contains 'exe') {
$exePkgNameFilter = "powershell-*.exe"
$exePkgPath = Get-ChildItem -Path $(Pipeline.Workspace) -Filter $exePkgNameFilter -Recurse -File | Select-Object -ExpandProperty FullName
Write-Verbose -Verbose "signed exePkgPath: $exePkgPath"
Copy-Item -Path $exePkgPath -Destination '$(ob_outputDirectory)' -Force -Verbose
}
|
Azure Pipelines: 5 pipeline(s) require an authorized user to comment /azp run to run. |
TravisEz13
approved these changes
Apr 16, 2026
|
This sounds like an absolutely terrible idea.... I'm baffeled. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR Summary
This pull request removes MSI and EXE package support from the Windows packaging and release pipelines, as well as related documentation and scripts. The changes ensure that only ZIP and MSIX packages are produced, validated, signed, and uploaded for Windows releases. Additionally, references to MSI/EXE packaging are removed from documentation and infrastructure scripts.
Pipeline and Packaging Changes:
.pipelines/templates/packaging/windows/package.ymland.pipelines/templates/packaging/windows/sign.ymlto remove MSI and EXE package types from build, sign, and copy steps; now only ZIP and MSIX packages are handled for all Windows architectures (x64, x86, arm64). [1] [2] [3] [4] [5].pipelines/templates/uploadToAzure.ymlto exclude MSI and EXE files from the list of artifacts to download and upload to Azure, as well as from the set of files to be uploaded in the final step. [1] [2] [3] [4].pipelines/templates/release-validate-packagenames.ymlto validate only ZIP package names, removing MSI from validation and updating the display name accordingly. [1] [2].pipelines/templates/release-githubNuget.ymlto ensure MSI packages are not uploaded to GitHub releases by explicitly removing them before publishing.Documentation Updates:
.github/CONTRIBUTING.mdand.github/instructions/powershell-module-organization.instructions.md, and updated examples to refer to MSIX instead of MSI. [1] [2]Script Cleanup:
assets/MicrosoftUpdate/RegisterMicrosoftUpdate.ps1script, which was previously used in MSI installation scenarios.PR Context
Announcement in PowerShell-Blog and reasoning explained here: https://github.com/PowerShell/PowerShell-Blog/pull/275
This PR should not be backported to the current release branches as those still need to support MSI packages.
PR Checklist
.h,.cpp,.cs,.ps1and.psm1files have the correct copyright header