Upgrade when installer type changes

[denelon]

Originally posted by @MagicFirefly in #1191 (comment)

[denelon]

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 --force

[MagicFirefly]

An 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.

[denelon]

@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

	"UpgradeBehavior": {
	"type": [ "string", "null" ],
	"enum": [
	"install",
	"uninstallPrevious"
	],

[denelon]

Related to:

• Winget upgrade package, No applicable update found #1191

[Trenly]

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-sale

WinGet-2021-11-06-15-22-31.813.log

[cotsuka]

I'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.

[o-l-a-v]

@cotsuka

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)        
}

[eidylon]

Yup, just reposting here for readability (from #1928 ), I ran into this same issue with StefansTools.grepWin .

[Trenly]

@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

[denelon]

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 @Trenly?

[denelon]

It might be related to:

• Client Verbosity Settings #161

[Trenly]

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 @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

1. 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. . .
2. 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

[denelon]

That sounds like a great improvement!

[Trenly]

[Policy] Command-Upgrade