Remove MSI from publishing pipeline by jshigetomi · Pull Request #27213 · PowerShell/PowerShell

jshigetomi · Apr 8, 2026

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:

Updated .pipelines/templates/packaging/windows/package.yml and .pipelines/templates/packaging/windows/sign.yml to 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]
Updated .pipelines/templates/uploadToAzure.yml to 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]
Modified .pipelines/templates/release-validate-packagenames.yml to validate only ZIP package names, removing MSI from validation and updating the display name accordingly. [1] [2]
Updated .pipelines/templates/release-githubNuget.yml to ensure MSI packages are not uploaded to GitHub releases by explicitly removing them before publishing.

Documentation Updates:

Removed instructions and references related to MSI and EXE packaging from .github/CONTRIBUTING.md and .github/instructions/powershell-module-organization.instructions.md, and updated examples to refer to MSIX instead of MSI. [1] [2]

Script Cleanup:

Deleted the now-unused assets/MicrosoftUpdate/RegisterMicrosoftUpdate.ps1 script, 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

Copilot

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-PSPackage and 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

$packageTypes still includes 'exe' for x64/x86/arm64, but this PR removed MSI→EXE generation and upload/download of *.exe elsewhere. As written, Get-ChildItem ... | Select-Object -ExpandProperty FullName will produce $null when no EXE exists and Copy-Item -Path $exePkgPath will fail. Either remove exe from $packageTypes or 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
      }

Copilot

Pull request overview

Copilot reviewed 21 out of 24 changed files in this pull request and generated 3 comments.

azure-pipelines · Apr 15, 2026

Azure Pipelines: 5 pipeline(s) require an authorized user to comment /azp run to run.

MichelZ · Apr 17, 2026

This sounds like an absolutely terrible idea.... I'm baffeled.
Microsoft shooting itself in the foot again

Karl-WE · May 2, 2026

Hi there,
If we have deployed msi, e.g. Through Intune or winget what is the way forward then?

Previously msi and store App were not compatible and clash.

If customers are on msi and try to upgrade via winget what would happen?

HStry · May 25, 2026

It took me far too long to find out that this is the reason my scripted winget install --scope machine MicroSoft.PowerShell.Preview broke. Why wasn't this mentioned in the release notes?
As a linux person I'm the first to admit I don't know the ins and outs of the differences between msi and msix, but for my own convenience reasons, I want this installed system-wide. I'm probably missing something, but this seems to be a solution in search of a problem.

Co-authored-by: Justin Chung <chungjustin@microsoft.com> Co-authored-by: Aditya Patwardhan <adityap@microsoft.com>

gabriel-vanca · Jul 16, 2026

Please reverse this. Genuinely terrible decision.

doctordns · Jul 16, 2026

This is, i agree, a terrible decision: removing a working features that many customers rely on, and substituting a less capable technology (and declaring it a good thing).

I am aware of no-one in the community that thinks this was a good idea or even vaguely helpful. It is, i feel, just another MS PM commitgment that takes precedence over the community and customer need.

The right answer, for customers, is to restore MSI, and wait till THE COMMUNITY AGREES MSIX IS READY. Then nuke MSI. In my view, any other decision priorities internal project commitments over customers need.

Snover once opined that MS was not capable of sustained failure. It feels like this is no longer true.

Karl-WE · Jul 16, 2026

@jshigetomi @copilot can you confirm that the comments here are read and considered?

Here are some side-effects this change brings:

Affected OS: all supported versions of Windows Server, Windows and Azure Stack HCI OS (Azure Local).

no update path from msi to msix using winget. Winget has no logic that it would remove the msi to replace it with MSIX when upgrading the package. Removing a package is not covered by the dependency logic winget already has, it can just add packages beforehand.
Please consider to consult with winget PM about this change. This change will break deployment logic and causing regressions, status quo.
It's identified that some modules, such as Windows and Windows Server inbox DISM module causing a regression with the MSIX. method.
Execution will fail because of access / permission issues. To my knowledge this is by-design of MSIX.

While, as Windows Server MVP I could file a feature request for updating dism module, also adding missing commands/parameters, unlikely such update will happen in time and alignment of this change. Also backports need extended time.

OT Sidenode: I am here wishing for long time that MSIX would have made MSI deperecated, infact obsolete as a successor, across all products and installers, but apparently after years, it still has limitations and adoption of 3rd parties is rather low.
Even in Microsoft Store sometimes it's a "good enough approach" msix will serve as wrapper downloading MSI installers, examples iCloud, Spotify etc.

In addition I have not seen much adoption of MSIX from Microsoft Product groups either. Thinking about Exchange etc. There might be reasons.

Karl-WE · Jul 17, 2026

This video I found in my vault of my Microsoft knowledgebase. This might serve as a reminder of back then vs status quo improvements of MSIX since 2020 - I think it is still valueable: https://www.youtube.com/watch?v=wbe_KvfkG0Q

- YouTube
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.

kilasuit · Jul 17, 2026

Hi - not speaking on behalf of the team on this as such, I feel the links below should be used instead to make comments on this change, as to better direct the conversation going forward rather than adding comments to a closed out PR, that in many cases isn't usually looked at.

That said I don't see why the comments here will not have been read by at least some in the team/extended team like myself.

I would strongly recommend instead of commenting on this PR that for anyone reading you add you comments that you may have to this discussion

Deprecation of MSI and EXE based installers in lieu of MSIX #27292

or this Issue

Please re-add MSI installer packages for >= v7.7 #27383

Or to the tracking issue for Gaps in MSIX

Tracking: MSIX packaging gaps for PowerShell 7 #27565

If this was one of my projects, I'd have made a comment like this & then decided to lock further comments on this PR for the above reason.

`Test-Bom` was only used in `New-MSIPackage`, which was removed in #27213 as we are not building MSI packages for v7.7 and onward. `Test-Bom` is no longer used anywhere in PowerShell repo, so removing it and its helpers, as well as the boms JSON files, in this PR.

Justin Chung and others added 3 commits April 8, 2026 16:45

Filter out msi

aa256d4

Remove MSI packaging

cd9f196

Remove RegisterMicrosoftUpdate.ps1 from csproj and BOM

10259c3

jshigetomi added the CL-BuildPackaging Indicates that a PR should be marked as a build or packaging change in the Change Log label Apr 9, 2026

microsoft-github-policy-service Bot added Backport-7.4.x-Consider Backport-7.5.x-Consider Backport-7.6.x-Consider labels Apr 9, 2026

jshigetomi removed Backport-7.4.x-Consider Backport-7.5.x-Consider Backport-7.6.x-Consider labels Apr 9, 2026

Justin Chung added 2 commits April 9, 2026 14:21

Removed references to deleted methods

c9264ea

Remove test that checked for wix

3a41a8c

jshigetomi marked this pull request as ready for review April 10, 2026 15:25

jshigetomi requested a review from a team as a code owner April 10, 2026 15:25

Copilot AI review requested due to automatic review settings April 10, 2026 15:25

Copilot started reviewing on behalf of jshigetomi April 10, 2026 15:26 View session

Copilot AI reviewed Apr 10, 2026

View reviewed changes

Comment thread tools/packaging/packaging.psd1 Outdated

Comment thread tools/packaging/packaging.psm1

Comment thread .pipelines/templates/packaging/windows/sign.yml Outdated

Comment thread tools/ci.psm1

Comment thread .github/CONTRIBUTING.md Outdated

Copilot review fixes

d2d130e

jshigetomi requested a review from Copilot April 10, 2026 16:07

Copilot started reviewing on behalf of jshigetomi April 10, 2026 16:08 View session

Copilot AI reviewed Apr 10, 2026

View reviewed changes

Comment thread .github/CONTRIBUTING.md Outdated

Comment thread tools/packaging/packaging.psm1 Outdated

Comment thread docs/maintainers/releasing.md Outdated

Justin Chung and others added 3 commits April 10, 2026 15:28

Copilot fix second

79e9a31

Edits to releasing.md

f46e12d

Merge branch 'master' into removeMSI

970b54b

TravisEz13 approved these changes Apr 16, 2026

View reviewed changes

TravisEz13 merged commit 72be78e into PowerShell:master Apr 16, 2026
40 checks passed

JustinGrote pushed a commit to JustinGrote/PowerShell that referenced this pull request Jun 2, 2026

Remove MSI from publishing pipeline (PowerShell#27213)

fce4127

Co-authored-by: Justin Chung <chungjustin@microsoft.com> Co-authored-by: Aditya Patwardhan <adityap@microsoft.com>

jshigetomi deleted the removeMSI branch June 25, 2026 17:33

Karl-WE mentioned this pull request Jul 17, 2026

Tracking: MSIX packaging gaps for PowerShell 7 #27565

Open

11 tasks

daxian-dbw mentioned this pull request Jul 24, 2026

Remove Test-Bom and the boms JSON files #27726

Merged

12 tasks

Search code, repositories, users, issues, pull requests...

Uh oh!

Conversation

jshigetomi commented Apr 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

PR Summary

PR Context

PR Checklist

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

azure-pipelines Bot commented Apr 15, 2026

Uh oh!

Uh oh!

MichelZ commented Apr 17, 2026

Uh oh!

Karl-WE commented May 2, 2026

Uh oh!

HStry commented May 25, 2026

Uh oh!

gabriel-vanca commented Jul 16, 2026

Uh oh!

doctordns commented Jul 16, 2026

Uh oh!

Karl-WE commented Jul 16, 2026

Uh oh!

Karl-WE commented Jul 17, 2026 • edited by unfurl-links Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kilasuit commented Jul 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

jshigetomi commented Apr 8, 2026 •

edited

Loading

Karl-WE commented Jul 17, 2026 •

edited by unfurl-links Bot

Loading