I can think of one thing though and that is PowerShell team waiting for the signature granted by the Microsoft Store validation team so they can use it to sign the MSIX package, which should have Windows Store EKU - 1.3.6.1.4.1.311.76.3.1 and Microsoft MarketPlace PCA 2011 as CN. But even if that's the case, as i mentioned the code is already released in every other possible way, so even if in an unlikely event the validation fails for some reason, there is no going back as every other installer has already been used by tens of thousands of people/automated workflows across multiple OSes.

So at least this process needs to be optimized and sped up.

Or just wait till MSIX package is ready before making the release, because when MSIX is added to a release, we don't get any notification, so we literally just have to refresh the release page everyday to see if MSIX package was added...

My understanding is that the app store performs the signing of the MSIX. You submit your bundle signed by your developer's certificate then Microsoft resigns it with the store certificate. An MSIX signed by the developer's certificate would not be able to be installed on end user machines unless you added the developers certificate to your trust store, that then defeats the ease of use of the MSIX.

so we literally just have to refresh the release page everyday to see if MSIX package was added...

Does the app not get updated directly from the AppStore like every other app store app?

Nobody needs to add any certificate to any store. Other installers are signed with globally valid certificates, MSIX would be signed with the same certificate. Microsoft isn't using self-signed certificates.

Anyway, as i explained, this isn't related to Microsoft store. It's about having access to the MSIX package.

Seeing the same thing with 7.5.1. I checked the box when I installed it.
The last updates were 7.4.6 and LTS 7.4.7 in the Microsoft Update Catalog.

Regarding signing certificates, the identity of an MSIX application is governed by the publisher and the certificate. The MSIX has to be signed by a certificate matching the publisher in the appxmanifest.

The application identity, eg Microsoft.PowerShell_8wekyb3d8bbwe is used as a directory in %LOCALAPPDATA\Microsoft\WindowsApps, if you sign with a different certificate it would need to be a different publisher and hence be counted as yet another different application. See How to calculate PublisherID from Publisher?

I suggest that waiting a couple of days for the MSIX with the exact same identity as the one published in the store is worth the delay. I don't see it as an inconvenience.

Although the certificates have different thumbprints they do have the same subject.

foreach ($File in 'PowerShell-7.4.6-win-x64.msi','PowerShell-7.4.6-win.msixbundle')
{
	if (-not(Test-Path $File))
	{
		Invoke-WebRequest -Uri "https://github.com/PowerShell/PowerShell/releases/download/v7.4.6/$File" -OutFile $File
	}

	$Certificate = (Get-AuthenticodeSignature $file).SignerCertificate
	$Publisher = Get-PublisherIdFromPublisher $Certificate.Subject

	[PSCustomObject]@{
		File = $File
		Thumbprint = $Certificate.Thumbprint
		Subject = $Certificate.Subject
		Publisher = $Publisher
	}
}

Gives

File                            Thumbprint                               Subject                                                                          Publisher
----                            ----------                               -------                                                                          ---------
PowerShell-7.4.6-win-x64.msi    8F985BE8FD256085C90A95D3C74580511A1DB975 CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US 8wekyb3d8bbwe
PowerShell-7.4.6-win.msixbundle E58C8819B0C917304DFD171699CE7BAF249C3359 CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US 8wekyb3d8bbwe

That looks like the correct publisher id. So it might give the correct application identifier.

Flagged as discussion on the community call this month in #25000 & may see an update in here before then

Still waiting...
7.5.1 is now screaming to be installed...

Hi,
The most important thing for me is to be able to install it without Administrator privileges.

I've mentioned multiple problems with the current workflow/plan and made a few suggestions too, do you consider implementing any of them?

For example delaying the GitHub release until MSIXBundle is available or notify us when it becomes available instead of silently adding it to the release.

Also why should there even be a reason to request the Microsoft's recommended installer format? Maybe we should ask why we need .exe or .MSI file. MSIXBundle is modern, installation/uninstallation is clean and has many other benefits.

MSIXBundle can be easily used in Intune for remote deployment without going through all other unnecessary steps needed for legacy installers.

If any of the things i mentioned is wrong or not logical please let me know.

Ultimately, the reason for needing the MSIXBundle can be the same reason people need MSI or .exe installers.

I understand the review process for the Store signing and the complications of signing the MSIXBundle with another certificate. All i'm asking is to give it the same importance and priority that you give to the legacy installer formats.

I would like to understand the scenarios where you need the msixbundle file instead of updating via the Store. Thanks

In large organisations with company managed PCs access to the store may be blocked. But they could still distribute MSIX internally.

In large organisations with company managed PCs access to the store may be blocked. But they could still distribute MSIX internally.

This.

Another important benefit of delaying the GitHub releases until MSIXBundle is ready is to increase security and reliability of the distributed code.

Currently, when you submit the PowerShell package to the Store for review and signing, if by any chance, even if so small and very unlikely, the review process fails, due to security or even reliability reasons in the code, you cannot do anything because the code has already been made available to the public through other installer formats.

The whole point of making the package available to the Store team is so they can review and vet it, right? So what would be the point of it all if whether the review fails or succeeds, you release the code to the people?

Also should mention that the signature in the MSIXBundle is a lot more trustworthy (in the eyes of the OS) than MSI or Exe installer. App Control template policies in the OS all trust packages signed by Store certificate by default. That further indicates the importance of the vetting and review process done by the Microsoft Store team.

@SteveL-MSFT - using the MSIX should work fine in a fully disconnected environment, shouldn't it? I may be wrong but wouldn't it also would be the only way to install software on devices that are running Windows S mode & then aren't for whatever reason allowed to connect to the Store at all.

Those are great goals and i hope we'll see them in the not so distant future too. What you said about different rings is reasonable and fair. For the time being maybe small and simple things can be implemented? like someone uploading the MSIXBundle package whenever the Store team signs it? Within a reasonable timeframe like in 1 or 2 days, not 1 month. All it takes is someone with write permissions to upload the MSIXBundle to the release.

Or maybe you can include that step in the same workflow that pushes it to the Winget repository? I could look into it and create a PR if needed.

One of the reasons I asked for MSIXBundle package on release is that other Microsoft repositories do it, such as Winget, Windows Terminal, Dev Home and so on. Maybe PowerToys too? So i figured PowerShell could adopt the same workflow. Yes those aren't cross platform like PowerShell is but still.

if there was some reason for not releasing the update in the Microsoft Update Catalog

Looking at Microsoft Update Catalog it looks like 7.4.7 is there because it is the most recent LTS release. Others are marked as preview. .NET 8.0 is an LTS release, .NET 9.0 is not.

Where as winget does give you 7.5.1

C:\>winget search --id microsoft.powershell
Name               Id                           Version Source
---------------------------------------------------------------
PowerShell         Microsoft.PowerShell         7.5.1.0 winget
PowerShell Preview Microsoft.PowerShell.Preview 7.6.0.4 winget

This is not helpful from a system management perspective.

This is not helpful from a system management perspective.

I suggest the case where somebody elected to install an LTS release and then was involuntarily updated to an non-LTS release is the worse scenario.

Any planned release of the MSIXbundle for 7.5.1?

7.5.1 is available in the Windows update catalog. It says it was released 21 May 2025.
7.5.0 never made it out of preview in the catalog.
7.6 is now in preview there.