A newer version was found, but the install technology is different from the current version installed. Please uninstall the package and install the newer version #2155
-
Brief description of your issueI am trying to update the Powershell to the latest 7.2.3 version, I (supposedly) have the 7.2.2 version. I do it via winget
Steps to reproduceExpected behaviorPS > successfully installedActual behaviorPS > A newer version was found, but the install technology is different from the current version installed. Please uninstall the package and install the newer version.EnvironmentWindows: Windows.Desktop v10.0.19044.1645
Package: Microsoft.DesktopAppInstaller v1.17.10271.0PS C:\Users\user1> $PSVersionTable
Name Value
---- -----
PSVersion 7.2.2
PSEdition Core
GitCommitId 7.2.2
OS Microsoft Windows 10.0.19044
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0Logs after running the command: |
Beta Was this translation helpful? Give feedback.
Replies: 9 comments 48 replies
-
|
This happens when the installer format changes from one type to another. It could be going from MSIX to MSI, EXE to MSI, or any other installer format transition. You could try using |
Beta Was this translation helpful? Give feedback.
-
|
try winget install Microsoft.PowerShell --force |
Beta Was this translation helpful? Give feedback.
-
|
Did you try |
Beta Was this translation helpful? Give feedback.
-
|
Using "--force" is likely to result in two versions of PowerShell installed "side-by-side". |
Beta Was this translation helpful? Give feedback.
-
|
I had the same issue when upgrading powershell from 7.3.11.0 to 7.4.1.0. First I thought I did not install powershell via winget but via some other "technology" (whatever that means), then I found this issue. Winget could really handle this more gracefully and improve the UX. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
@denelon Would this be a problem in the MSI was installed via a burn exe bundle? |
Beta Was this translation helpful? Give feedback.
-
|
from what I see command |
Beta Was this translation helpful? Give feedback.
-
|
When we update through Microsoft update, we use an EXE wrapper around the MSI for technical reasons. |
Beta Was this translation helpful? Give feedback.
-
I think we need to test that scenario. |
Beta Was this translation helpful? Give feedback.
-
|
I can provide the wrapper if that would be helpful. |
Beta Was this translation helpful? Give feedback.
-
|
I think we have a few options. I believe the best approach in my mind is to let the Publisher/ISV (PowerShell in this case) to decide what kind of experience they wish users to have with the Windows Package Manager. It would likely make the transition to Windows Package Manager after another install experience more seamless if the wrapper is used, but I'm not sure how that impacts CI/CD pipelines. |
Beta Was this translation helpful? Give feedback.
-
|
We also have improved on this in 1.3, allowing for packages to state the type that the present as in Add/Remove Programs. I'm surprised actually that an EXE wrapper on an MSI would cause problems with an MSI, but I would want to see how it handles in 1.3 to see if we need to do more. |
Beta Was this translation helpful? Give feedback.
-
|
I had a slightly different issue. Powershell told me 7.2.5.0 was available and I should update. |
Beta Was this translation helpful? Give feedback.
-
|
There are some sequencing challenges. It takes more time for validation and publishing to happen in the Windows Package Manager than it does to release a new version of PowerShell. The PowerShell release needs to exist before the Windows Package Manager manifest can be validated. I would be guessing how PowerShell detects a new version is available, but I wouldn't want them to have to wait on Windows Package Manager manifest publishing to have their product announce the availability of a new version. |
Beta Was this translation helpful? Give feedback.
-
|
Hey, got similar issue here |
Beta Was this translation helpful? Give feedback.
-
|
I would suggest uninstalling 7.2.7.0 and then installing 7.3.0.0 to avoid the error message (this assumes you no longer need 7.2.7.0). If you still need 7.2.7.0 you should be able to |
Beta Was this translation helpful? Give feedback.
-
Actually, that one command uninstalled the older version and installed 7.3.0.0 in-place. So all my profiles and shortcuts still works. Thanks, didn't know it is that simple. |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
This is an ongoing issue for v1.22 of vigembus and 1.4 of hidhide. I'm guessing I'll have to uninstall both and then install again using winget. |
Beta Was this translation helpful? Give feedback.
-
|
This is still an issue Feb 2024! Why? |
Beta Was this translation helpful? Give feedback.
-
|
Publishers build different installers with different use cases in mind. Different packages have different mechanisms for retaining "user" data during an upgrade. When the installer type changes, this could represent a fundamental change in how the program operates and how the user data is (or is not) retained when a new version of a program is installed. There isn't a "one size fits all" type of solution here. Ultimately, the publisher should be able to determine the best way to handle these scenarios. Sometimes that means uninstall the old version and install the new version. Other times it might mean installing the new version and running some kind of migration step. We're certainly open to solutions that address various scenarios here. PowerShell for example, has both MSI and MSIX installers, and they don't always gracefully upgrade the user profile and other settings when a new version is installed. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @denelon , Thank you very much for your feedback. Let me share my own experience that led me to this page and propose a solution. I've faced exactly the same issue:
when running as advises at https://learn.microsoft.com/en-us/powershell/scripting/install/installing-powershell-on-windows?view=powershell-7.4 Note that winget cli is marked as recommended option , hence I had some expectations of a smooth user experience when using it.
This happened on three different devices: two personal Windows 11 and one work Windows 10. Each time, it took a considerable amount of time to get things done. I was close to losing my patience. None of the solutions available on the internet worked out of the box on the first attempt for me. Now, here's a proposed solution: Introduce a standard/recommended/expert (whichever term you prefer) installation method to improve user experience by providing a single-line upgrade option. For example, add a --force switch which will run the uninstallation if required for the end user:
In the case of a different installation method, this would be equivalent to:
ps I do not remember how exatly I've installed PowerShell on my boxes in a first place. I suspepect it was done vie microsoft store. Unfortunately I do not have any evidecnes. Yet, chaces are high. This leads to another suggestion Make sure microsoft store and winget install options are compatible with each other. Thank you, |
Beta Was this translation helpful? Give feedback.
-
|
There is already an (Unless someone else looks into it first, of course...) |
Beta Was this translation helpful? Give feedback.
-
|
It might be less confusing if the error message were changed to something more meaningful (to mean, for example, package was installed differently and cannot be upgraded this way) The current error message reads as if there has been a breaking change in the newer version of the installer. Also, calling a installer format change as "new technology" is just ..... something🤣 🤣 |
Beta Was this translation helpful? Give feedback.
-
|
We're certainly open to suggestions. Given not all users understand the subtle distinctions between different installer types (.exe, MSI, MSIX), it's tricky to come up with a message that is brief and clear. WinGet can't assume one installer type is newer or better than another. That why the word "different" was chosen. The "newer version" applies to the package, not an installer type. |
Beta Was this translation helpful? Give feedback.
-
My complaint with this issue is not that Winget can't deal with changing installer types. (it absolutely should or even needs to handle that but that's an issue for another day I suppose) My issue is that Winget is the package manager from Microsoft and yet upgrading Microsoft PowerShell consistently yields this error. It doesn't matter if it's Winget's fault or PowerShells's fault. A Microsoft package manager should ALWAYS be able to install a Microsoft application. Frankly, things like this very issue with upgrading PowerShell makes me very hesitant to even bother installing or updating things via Winget and you are going to have a hell of an issue with adoption of it if people don't have confidence in it. |
Beta Was this translation helpful? Give feedback.
-
|
The choice was made to handle installer type changes by informing the user. If the manifest indicated "uninstall previous" was the default behavior, then the previous version would be removed and the newer version would be installed. This is a case where a user might want "both" versions to remain, or the user might "need" both versions to remain (at least until any package specific data was migrated). WinGet needs to have some "default" behavior in cases where the consequences of installing a newer version of an arbitrary package might not be well understood. Arguments like "--force" and "--uninstall-previous" are present so a user can control WinGet's behavior. I completely get the frustration here, and I encounter it myself regularly when installing and updating all kinds of packages. WinGet doesn't special-case behaviors for specific packages or publishers (not even Microsoft as a publisher). Our goal is to make the best "default" choice, so users aren't sad/mad/frustrated. Sometimes there isn't a single best solution, and in those cases, we defer to the user. Dealing with decades of entropy in terms of legacy installers, and a world of change isn't easy. I don't have all the answers. That's one of the primary benefits of being open source and having these kinds of discussions. If we can come up with better solutions together, everyone benefits. I do appreciate the honest feedback, even when it's negative. Thank you for taking the time to share it. |
Beta Was this translation helpful? Give feedback.
-
|
I created: |
Beta Was this translation helpful? Give feedback.
and others
This happens when the installer format changes from one type to another. It could be going from MSIX to MSI, EXE to MSI, or any other installer format transition.
You could try using
winget show Microsoft.PowerShell -s wingetto get the URL to the installer and you could run the installer directly rather than uninstalling it first.