Closed wolf99 closed 5 months ago
are you...trying to update PowerShell while running the powershell version that is supposed to be removed & updated? that's like trying to shoot your own foot and windows is preventing that. If the old powershell was in use the upgrade was probably scheduled for the next system reboot - the old powershell will only be replaced then. So, reboot the system and check the version then.
are you...trying to update PowerShell while running the powershell version that is supposed to be removed & updated? that's like trying to shoot your own foot and windows is preventing that. If the old powershell was in use the upgrade was probably scheduled for the next system reboot - the old powershell will only be replaced then. So, reboot the system and check the version then.
I tried this from other shells also. For the sample I put here I used ms PowerShell so that I could properly show the verilsion output from PowerShell itself, as kind of a source of version information independent of winget.
Again, same behaviour in CMD or windows powershell as in ms PowerShell.
Even if this is the cause, I would expect that winget, as an independent tool,would still be able to consistently recognise the versions, but that the update installer would then fail (kind of like if you try to delete a file that is already open). In this case, winget doesn't seem to even understand that the system has an old version even though it has just there is a newer version available.
Probably due to https://github.com/microsoft/winget-pkgs/issues/127283#issuecomment-1856603465
Wow. Just skimming through the linked issue that also links to another issue and so on, it seems that, essentially, winget gets confused between all the different packages named "powershell"...
Who could have possibly predicted problems with naming different packages with the same name...🤦
Yes - with a diversity of installer types and CPU architectures, some software packages have a handful of installers. Add language localization, and some of Mozilla's manifests have more than 100 installers listed.
The package manager logic downloads the repo's contents inside an MSIX, and compares this to the Registry, returning matching results. Not just on name, but many manifests also utilize DisplayCode
and InstallerCode
to help with matching and correlation.
Sometimes, a dupicate registry entry can cause issues. Could you run winget list powershell
and paste the output?
Hi @stephengillie
Here is the output:
PS C:\> winget list powershell
Name Id Version Available Source
------------------------------------------------------------------------------
PowerShell 7.4.1.0-x64 Microsoft.PowerShell 7.4.1.0 7.4.2.0 winget
Windows Terminal Microsoft.WindowsTerminal 1.19.10821.0 winget
The input from @R-Adriangot got me thinking a little, so I tried checking the PSVersion Table from cmd prompt.
c:\>PowerShell $PSVersionTable
Name Value
---- -----
PSVersion 5.1.22621.2506
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.22621.2506
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
So perhaps the "system" (i.e. Windows and winget combined) somehow only sees the Windows powershell and not Microsoft PowerShell.
Of course I could update PowerShell by just downloading the relevant MSI installer... but this is a problem with winget (or perhaps Windws) that maybe should be fixed
The 1.0 version is sometimes called Windows Powershell
, such as in Terminal:
And this version stores data at C:\Program Files (x86)\WindowsPowerShell
instead of C:\Program Files\PowerShell
. It's possible that this 1.0
version is running when the version 7
is upgrading.
Please don't conflate separate software into one - it confuses troubleshooting. The package manager mostly matches a data file to the Registry to return results, and runs the installer programs. What's occurring here seems to be a mismatch between the data in the PC's Registry with the data from the repo. From your reports and pasted outputs, I believe this PC's Windows OS to generally be in normal working order. (Edit: accidentally submitted before complete.)
Probably the best course here is to reinstall PowerShell - the package manager has this version so should be able to winget uninstall Microsoft.Powershell
followed by a quick winget install Microsoft.Powershell
. The automation of this manual process has apparently been added to a planning system, but other work might be prioritized ahead of it.
Hmm:
c:\>winget uninstall Microsoft.PowerShell
No installed package found matching input criteria.
This is beyond my current knowledge of the system. I do not currently know what state the Registry could be in, which would give the outputs pasted in this Issue.
Well, looks like Windows took care of this itself somehow while I wasn't looking. Not sure if it was Windows Update or Microsoft Store, but Powershell now shows 7.4.2 and Im very sure it wasn't via winget. 🤷♂️
Thanks for th help anyway @stephengillie !
Please confirm these before moving forward
Category of the issue
No applicable update found.
Brief description of your issue
winget update
shows that Microsoft.PowerShell is behind (7.4.1.0) the latest release (7.4.2.0)winget update Microsoft.PowerShell
thinks there is not newer release.THe PowerShell repo does show the newer release: https://github.com/PowerShell/PowerShell/releases/tag/v7.4.2
Steps to reproduce
Actual behavior
PowerShell is not updated
Expected behavior
PowerShell is updated
Environment
Screenshots and Logs