Upgrade all | enhancement suggestion
Describe the issue The Upgrade all button wasn't touched in quite some time. There is no problem with it, but it can be enhanced quite a bit. It uses a powershell 5 window and isn't really correlated to the rest, I currently do not have time to fix it, so if someone has time and wants to work on that be my guest.
To Reproduce Steps to reproduce the behavior:
- Open WinUtil
- Click on Upgrade all
suggestion Instead of having it's own function like now it would be much easier to check for updates, package the IDs of applications that need to be updates and send them to the existing logics to install & upgrade a selection, the selection here being all updatable applications. That would also make it easier to track when it is finished with the process due to it being impossible at the time and I don't have to add logics later on for the progress bar, hehe.
Screenshots self explanatory, not needed.
Linking with #2226 for @og-mrk
Two ideas of how one can get all available winget update packages
The winget native way (currently used in winget)
(winget list -s winget | Select-Object -skip 3 | ConvertFrom-String -PropertyNames "Name", "Id", "Version", "Available" -Delimiter '\s{2,}' | Where-Object {$_.Available -like "*.*"}).id
The modern way (Requires the Module: Microsoft.WinGet.Client)
(Get-WinGetPackage | Where-Object {$_.IsUpdateAvailable -eq "True"}).Id
Problems:
winget native: Winget returns everything as a string, so one must manually parse the string output into a PSCustomObject. Unfortunately, no consistent delimiter is used, making it challenging to parse all winget packages reliably.
For example, the package "Mail and Calendar" returns the following string:
Name Id Version Available
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Mail and Calendar MSIX\microsoft.windowscommunicationsapps_16005.14326.20544.0_x64__8wekyb3… 16005.14326.205…
The ID is so long that it gets truncated, rendering it unusable.
Also as you can see, there are spaces in the package name, so at least two spaces need to be used as a delimiter. This makes it hard, to split the ID from the version because you most likely would need to handle more than [Space][Space] OR
...[Space] as a delimiter
Powershell Module: Since the module isn't installed by default on Windows, it must be manually installed before it can be used. Winutil has been attempting to install it for the past few months during the installation or upgrade of Winget. However, in my experience, automatic Nuget or module installation from the PowerShell Gallery is unreliable, and I've encountered significant issues on some older installations.
Due to these concerns (and the lack of telemetry from winutil to confirm), I'm not convinced that all PCs have the module installed. Additionally, I'm uncertain if we can or should rely on the auto-install feature.
If we can get the Module to install and work reliably this would most definitely be the way to go, as this would remove the need for manually parsing the string and converting it to an object. Also, the Module offers some more options to work with winutil using modern PowerShell Cmdlets that return proper PSObjects
This issue was marked as stale because it has been inactive for 7 days
This issue was closed because it has been inactive for 7 days since it was marked as stale