Repository navigation
Upgrade when installer type changes #1640
Description
Activity
In this scenario, the previous installer was a .exe installer and the new version is an MSI. For this scenario, we may need to add a new key to the manifest to indicate what has happened at the transition. Maybe we should uninstall the previous version and install the new MSI version. More examples would help to determine if this is the correct behavior, or if we're going to need to support additional behaviors in the client. I believe in this case you may be able to:
winget upgrade Cryptomancer.Cryptomancer --forceAn uninstall of the prior exe version was required to allow install of the new msi version. Running the new msi version indicated the uninstall requirement.
MagicFirefly, I'm not sure about what the code path would do today. It's worth trying to add the upgrade behavior as "uninstallPrevious" for the new MSI version of the package.
winget-cli/schemas/JSON/manifests/v1.0.0/manifest.installer.1.0.0.json
Lines 150 to 155 in 17fc527
I experienced this issue today with Microsoft Edge. Log is attached
Windows PowerShell Copyright (C) Microsoft Corporation. All rights reserved. Try the new cross-platform PowerShell https://aka.ms/pscore6 PS C:\WINDOWS\system32> winget upgrade Name Id Version Available Source ------------------------------------------------------------------------------------------- Microsoft Edge Microsoft.Edge 95.0.1020.40 95.0.1020.44 winget Microsoft 365 Apps for enterprise Microsoft.Office 16.0.14326.20508 16.0.14527.20234 winget 2 upgrades available. PS C:\WINDOWS\system32> winget upgrade Microsoft.Edge No applicable update found. PS C:\WINDOWS\system32> winget upgrade --id Microsoft.Edge No applicable update found. PS C:\WINDOWS\system32> winget show Microsoft.Edge Found Microsoft Edge [Microsoft.Edge] Version: 95.0.1020.44 Publisher: Microsoft Corporation Publisher Url: https://www.microsoft.com/en-US/ Publisher Support Url: https://support.microsoft.com/en-US/ Author: Microsoft Corporation Moniker: msedge Description: World-class performance with more privacy, more productivity, and more value while you browse. Homepage: https://www.microsoft.com/en-us/edge License: MIT License License Url: https://www.microsoft.com/en-us/servicesagreement/ Privacy Url: https://privacy.microsoft.com/en-US/privacystatement Copyright: Copyright (C) Microsoft Corporation Copyright Url: https://www.microsoft.com/en-us/servicesagreement/ Installer: Type: Msi Download Url: https://msedge.sf.dl.delivery.mp.microsoft.com/filestreamingservice/files/93862b4a-15ae-40a0-b501-f969633661e2/MicrosoftEdgeEnterpriseX64.msi SHA256: 7f0e61839f618d9e09c487e9e66755ee2094a31fd4bf83973c6b044e238ed745 PS C:\WINDOWS\system32> winget --info Windows Package Manager v1.1.12653 Copyright (c) Microsoft Corporation. All rights reserved. Windows: Windows.Desktop v10.0.19043.1288 Package: Microsoft.DesktopAppInstaller v1.16.12653.0 Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir Links --------------------------------------------------------------------------- Privacy Statement https://aka.ms/winget-privacy License Agreement https://aka.ms/winget-license Third Party Notices https://aka.ms/winget-3rdPartyNotice Homepage https://aka.ms/winget Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-saleI'm having this same issue with PowerToys and Thunderbird. I installed them both using winget. At the very least, we should keep things consistent within the ecosystem. I understand if somebody installs using an external method and it doesn't find applicable updates.
I experienced the same. I commented here: microsoft/winget-pkgs#36499 (comment)
Got redirected to this existing issue: #752.
Found out that a workaround for now is to just use
winget install --id <package_identifier>for such cases. So when automating winget upgrade with PowerShell, I now have a list of identifiers where I use install rather than upgrade. It's jank, but at least I can leverage Winget to upgrade most of my applications. Example:Click to expand
#Requires -RunAsAdministrator #Requires -Version 5.1 <# .SYNOPSIS Use winget to update some packages. .NOTES Author: Olav Rønnestad Birkeland Created: 211205 Modified: 211206 .EXAMPLE & $psISE.CurrentFile.FullPath #> # Inpit parameters [OutputType($null)] Param() # PowerShell preferences $ErrorActionPreference = 'Stop' $InformationPreference = 'Continue' # Encoding $PSDefaultParameterValues['*:Encoding'] = 'utf8' [Console]::InputEncoding = [Console]::OutputEncoding = $OutputEncoding = [System.Text.Utf8Encoding]::new() # Assets ## Control what apps to update with winget ### Device/ system context $Apps = [string[]]( 'CodecGuide.K-LiteCodecPack.Mega', 'Eraser.Eraser', # "winget upgrade" does not work, must use "winget install". 'Jabra.Direct', 'Logitech.Options', 'Microsoft.dotnetRuntime.3-x64', 'Microsoft.PowerToys', # "winget upgrade" does not work, must use "winget install". 'Nlitesoft.NTLite', 'Notepad++.Notepad++', 'Plex.Plex', # Not totally silent, "updating" prompt, and starts after install. 'Postman.Postman', 'SoftDeluxe.FreeDownloadManager', 'XnSoft.XnConvert', 'XnSoft.XnViewMP' ) ### User context, only if not running as SYSTEM if ([System.Security.Principal.WindowsIdentity]::GetCurrent().'User'.'Value' -ne 'S-1-5-18') { $Apps += [string[]]( 'GitHub.GitHubDesktop', 'OpenWhisperSystems.Signal' ) } ## Path of winget-cli $WingetCliPath = [string]( $( if ([System.Security.Principal.WindowsIdentity]::GetCurrent().'User'.'Value' -eq 'S-1-5-18') { '{0}\AppInstallerCLI.exe' -f ( (Get-Item -Path ('{0}\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe' -f $env:ProgramW6432)).'FullName' | Select-Object -First 1 ) } else { '{0}\Microsoft\WindowsApps\winget.exe' -f $env:LOCALAPPDATA } ) ) # Get upgradeable apps ## Introduce step Write-Information -MessageData '# Get Winget output' ## Get output from "winget upgrade" $WingetUpgradeable = [string[]]( cmd /c ('{0} upgrade' -f $WingetCliPath) | Where-Object -FilterScript {$_[0] -notmatch '\s'} ) ## Sort output alphabetically $WingetUpgradeable = [string[]]( $WingetUpgradeable[0,1] + ($WingetUpgradeable[2 .. $WingetUpgradeable.IndexOf($WingetUpgradeable[-2])] | Sort-Object) + $WingetUpgradeable[-1] ) ## Show output Write-Information -MessageData ($WingetUpgradeable -join [System.Environment]::NewLine) # Find upgradeable apps $AppsUpgradeable = [string[]]( $( foreach ($App in $Apps) { if ($WingetUpgradeable.Where{$_ -like ('*{0}*'-f$App)}.'Count' -eq 1) { $App } } ) | Sort-Object ) # Upgrade upgradeable apps ## Introduce step Write-Information -MessageData ('{0}# Upgrade apps' -f ([System.Environment]::NewLine*2)) ## Show no upgrades avaialble if none if ($AppsUpgradeable.'Count' -le 0) { Write-Information -MessageData 'Found no apps to update.' } ## Upgrade upgradeable apps foreach ($App in $AppsUpgradeable) { Write-Information -MessageData ( '{0}## {1} / {2} "{3}"' -f ( $(if($AppsUpgradeable.IndexOf($App) -ne 0){[System.Environment]::NewLine}), (1+$AppsUpgradeable.IndexOf($App)).ToString('0'*$AppsUpgradeable.'Count'.ToString().'Length'), $AppsUpgradeable.'Count'.ToString(), $App ) ) $null = cmd /c ( '{0} {1} --id {2} --silent --accept-package-agreements --accept-source-agreements' -f ( $WingetCliPath, $(if($App -in 'Eraser.Eraser','Microsoft.PowerToys'){'install'}else{'upgrade'}), $App ) ) Write-Information -MessageData ('Done. $? = {0}, $LASTEXITCODE = {1}.' -f $?.ToString(), $LASTEXITCODE) }
Yup, just reposting here for readability (from #1928 ), I ran into this same issue with
StefansTools.grepWin.Reacted by Demitrius NelonDemitrius Nelon (@denelon) - Perhaps we can add better messaging around trying to uninstall previous, especially now that #2755 is experimental? Not sure if the uninstall previous arg would bypass this error though
I'm not sure if WinGet has enough information to provide the right hint to the user.
Maybe it would make sense to have some documentation at Microsoft Learn to help provide some hints as to why certain error messages are presented.
I'm sure there are edge cases where the hints might not be correct, but I would prefer to help users fall into the "pit of success".
What were you thinking for better messaging Kaleb Luedtke (@Trenly)?
It might be related to:
I'm not sure if WinGet has enough information to provide the right hint to the user.
Maybe it would make sense to have some documentation at Microsoft Learn to help provide some hints as to why certain error messages are presented.
I'm sure there are edge cases where the hints might not be correct, but I would prefer to help users fall into the "pit of success".
What were you thinking for better messaging Kaleb Luedtke (@Trenly)?
There's 3 types of error that can lead to no applicable upgrade (at least from what I see in the code), and I'm sort of guessing at these, since I'm not quite familiar with that section of the workflow yet.
- The installed version is greater than the update version. This can occur with side by side installs occasionally, or when a package ID is mis-mapped (e.g, Teams Machine-Wide Installer vs Microsoft.Teams)
- No Applicable Installer. This can occur when a newer package version is available, but there aren't any installers in the newer package version that would be able to install on the user's system
- Upgrade Technology Different. This is the one we know and love around moving from exe -> msi, or something similar to that.
Currently, there are only 2 messages during the upgrade flow -
- No applicable upgrade found
- 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.
My thoughts are twofold
- Perhaps the messaging could be improved as to why no applicable upgrade was found. What filters made it un-upgradeable?
- No applicable upgrade found. A newer version is already installed
- No applicable upgrade found. No compatible installers found for your system
- More messages as needed. . .
- If the uninstall previous argument is pulled into stable, provide instruction on how to use winget to uninstall
- A newer version was found, but the install technology is different from the current version installed. Use --uninstall-previous to force an upgrade to the newer version
Reacted by w3lld0neThat sounds like a great improvement!
[Policy] Command-Upgrade
- removed this from the milestone
on Nov 14, 2024
Originally posted by MagicFirefly in #1191 (comment)