You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is about a bug (if it is not, please use the correct template).
UniGetUI Version
3.1.3
Windows version, edition, and architecture
Windows 11 Home 10.022631 Build 22631 x64
Describe your issue
When WinGet refuses to install an update because "A newer version was found. but the install technology is different the current version installed", UniGetUI reports this as successful. The code explicitly checks for this, likely because WinGet's docs claim it simply means "no applicable update found", but this seems like it should be an error, not a success, as a package is unable to be updated as requested due to something being wrong.
Steps to reproduce the issue
I'm not totally sure how to trigger an "install technology is different from the current version installed" error with WinGet, but I don't think it's pertinent. If you do have a WinGet package triggering this issue, you can just try to update it to see the issue.
UniGetUI Log
[Trimmed except for applicable line]
[11/8/2024 4:16:55 PM] Loaded operation parameters for package id=Microsoft.Edge on manager Winget and operation Update: update --id "Microsoft.Edge" --exact --source winget --accept-source-agreements --disable-interactivity --silent --include-unknown --accept-package-agreements --force
Package Managers Logs
**NOTE: For some reason triggering the issue in question does not change the Packager Manager log**
Manager WinGet with version:
System WinGet CLI Version: v1.9.25180
Using Native WinGet helper (COM Api)
——————————————————————————————————————————
Logged native task on manager Winget. Task type is ListSources
Process start time: 11/8/2024 3:25:01 PM
Process end time: 11/8/2024 3:25:01 PM
-- Task information
...
The task reported success
——————————————————————————————————————————
Logged subprocess-based task on manager Winget. Task type is RefreshIndexes
Subprocess executable: "C:\Users\mjrix\AppData\Local\Microsoft\WindowsApps\winget.exe"
Command-line arguments: " source update --disable-interactivity"
Process start time: 11/8/2024 3:25:04 PM
Process end time: 11/8/2024 3:25:12 PM
-- Process STDOUT
...
Return code: SUCCESS (0)
——————————————————————————————————————————
Logged native task on manager Winget. Task type is ListSources
Process start time: 11/8/2024 3:25:05 PM
Process end time: 11/8/2024 3:25:05 PM
-- Task information
...
The task reported success
——————————————————————————————————————————
Logged native task on manager Winget. Task type is ListInstalledPackages
Process start time: 11/8/2024 3:25:10 PM
Process end time: 11/8/2024 3:25:15 PM
-- Task information
...
The task reported success
——————————————————————————————————————————
Logged native task on manager Winget. Task type is ListUpdates
Process start time: 11/8/2024 3:25:12 PM
Process end time: 11/8/2024 3:25:15 PM
-- Task information
...
The task reported success
——————————————————————————————————————————
Logged native task on manager Winget. Task type is ListInstalledPackages
Process start time: 11/8/2024 3:25:30 PM
Process end time: 11/8/2024 3:25:32 PM
-- Task information
...
The task reported success
——————————————————————————————————————————
Logged subprocess-based task on manager Winget. Task type is RefreshIndexes
Subprocess executable: "C:\Users\mjrix\AppData\Local\Microsoft\WindowsApps\winget.exe"
Command-line arguments: " source update --disable-interactivity"
Process start time: 11/8/2024 3:25:47 PM
Process end time: 11/8/2024 3:25:48 PM
-- Process STDOUT
...
Return code: SUCCESS (0)
——————————————————————————————————————————
Logged native task on manager Winget. Task type is ListUpdates
Process start time: 11/8/2024 3:25:48 PM
Process end time: 11/8/2024 3:25:51 PM
-- Task information
...
The task reported success
——————————————————————————————————————————
Logged subprocess-based task on manager Winget. Task type is RefreshIndexes
Subprocess executable: "C:\Users\mjrix\AppData\Local\Microsoft\WindowsApps\winget.exe"
Command-line arguments: " source update --disable-interactivity"
Process start time: 11/8/2024 3:26:03 PM
Process end time: 11/8/2024 3:26:04 PM
-- Process STDOUT
...
Return code: SUCCESS (0)
——————————————————————————————————————————
Logged native task on manager Winget. Task type is ListUpdates
Process start time: 11/8/2024 3:26:04 PM
Process end time: 11/8/2024 3:26:07 PM
-- Task information
...
The task reported success
——————————————————————————————————————————
Logged native task on manager Winget. Task type is ListInstalledPackages
Process start time: 11/8/2024 4:14:48 PM
Process end time: 11/8/2024 4:14:53 PM
-- Task information
...
The task reported success
——————————————————————————————————————————
Logged native task on manager Winget. Task type is ListInstalledPackages
Process start time: 11/8/2024 4:16:36 PM
Process end time: 11/8/2024 4:16:40 PM
-- Task information
...
The task reported success
——————————————————————————————————————————
Logged subprocess-based task on manager Winget. Task type is RefreshIndexes
Subprocess executable: "C:\Users\mjrix\AppData\Local\Microsoft\WindowsApps\winget.exe"
Command-line arguments: " source update --disable-interactivity"
Process start time: 11/8/2024 4:16:47 PM
Process end time: 11/8/2024 4:16:48 PM
-- Process STDOUT
...
Return code: SUCCESS (0)
——————————————————————————————————————————
Logged native task on manager Winget. Task type is ListUpdates
Process start time: 11/8/2024 4:16:48 PM
Process end time: 11/8/2024 4:16:52 PM
-- Task information
...
The task reported success
——————————————————————————————————————————
Relevant information
Yes, this does occur when running the WinGet CLI, although this issue pertains to how UniGetUI handles that.
In the WinGetOperationProvider.cs file, here is the relevant line of code. The return value in question is -1978335189, or hex code 0x8A15002B (according to the WinGet docs, APPINSTALLER_CLI_ERROR_UPDATE_NOT_APPLICABLE / No applicable update found).
Screenshots and videos
The text was updated successfully, but these errors were encountered:
Please confirm these before moving forward
UniGetUI Version
3.1.3
Windows version, edition, and architecture
Windows 11 Home 10.022631 Build 22631 x64
Describe your issue
When WinGet refuses to install an update because "A newer version was found. but the install technology is different the current version installed", UniGetUI reports this as successful. The code explicitly checks for this, likely because WinGet's docs claim it simply means "no applicable update found", but this seems like it should be an error, not a success, as a package is unable to be updated as requested due to something being wrong.
Steps to reproduce the issue
I'm not totally sure how to trigger an "install technology is different from the current version installed" error with WinGet, but I don't think it's pertinent. If you do have a WinGet package triggering this issue, you can just try to update it to see the issue.
UniGetUI Log
Package Managers Logs
Relevant information
Yes, this does occur when running the WinGet CLI, although this issue pertains to how UniGetUI handles that.
In the
WinGetOperationProvider.cs
file, here is the relevant line of code. The return value in question is-1978335189
, or hex code0x8A15002B
(according to the WinGet docs,APPINSTALLER_CLI_ERROR_UPDATE_NOT_APPLICABLE
/No applicable update found
).Screenshots and videos
The text was updated successfully, but these errors were encountered: