[BUG] WinGetUI again and again installs x64 applications into "C:\Program Files (x86)\..." - why?

[mmoser18]

Please confirm these before moving forward

• I have searched for my issue and have not found a work-in-progress/duplicate/resolved issue.
• I have tested that this issue has not been fixed in the latest (beta or stable) release.
• I have checked the FAQ section for solutions.
• This issue is about a bug (if it is not, please use the correct template).

UniGetUI Version

3.1.5

Windows version, edition, and architecture

Windows 10 Pro

Describe your issue

Again and again - since I installed WinGetUI about 3 months ago - I witness that applications that have been updated by WinGetUI end up being installed in Window's x86/32-Bit application directory "C:\Program Files (x86)...". This happen, even though the prior installed versions were x64 (i.e. 64-Bit) versions and were installed in the "normal" 64-Bit application directory "C:\Program Files...". :-(

Why does WinGetUI keep installing me the x86/32-Bit updates over existing x64 versions? I find that increasingly annoying to the point that I am starting to consider ditching WinGetUI again. Or just using it as an alert mechanism to inform me that new versions are available, but not using its automatic update functionality any more (which would really be a pity).

Why is that so? Can I somehow "force" it to always download and install me the x64 versions ony?

Steps to reproduce the issue

As I said, it happens again and again and with may different applications.
One "reliable" example is JetBrain' IntelliJ IDE Community Edition (see https://www.jetbrains.com/idea/download/?section=windows - you'll have to scroll down a bit on that page - they want you to download the paid version. The free CE "community edition" can be downloaded when you scroll down a bit on that page).

To reproduce: Install an older version of the IDE using the x64 version and then let WinGetUI detect that there is a newer version available and let it update the application. It will then first uninstall the installed x64 version and instead install the latest vesion, but in the x86 variant. :-(

UniGetUI Log

[26.01.2025 11:48:54] Loaded operation parameters for package id=JetBrains.IntelliJIDEA.Community on manager Winget and operation Update: update --id "JetBrains.IntelliJIDEA.Community" --exact --source winget --accept-source-agreements --disable-interactivity --silent --include-unknown --accept-package-agreements --force
[26.01.2025 11:50:29] Found 0 screenshots for package Id=JetBrains.IntelliJIDEA.Community
[26.01.2025 11:50:31] Loaded details for package JetBrains.IntelliJIDEA.Community on manager Winget

Package Managers Logs

Logged subprocess-based task on manager Winget. Task type is LoadPackageVersions
Subprocess executable: "C:\Program Files\UniGetUI\winget-cli_x64\winget.exe"
Command-line arguments: " show --id "JetBrains.IntelliJIDEA.Community" --exact --versions --accept-source-agreements"
Process start time: 26.01.2025 11:50:29
Process end time:   26.01.2025 11:50:30

-- Process STDOUT
 ...

Return code: SUCCESS (0)

Relevant information

No response

Screenshots and videos

No response

[marticliment]

does the command winget update --id "JetBrains.IntelliJIDEA.Community" --exact --source winget --accept-source-agreements --disable-interactivity --silent --include-unknown --accept-package-agreements --force still cause the issue?

[mmoser18]

As far as I can tell that is exactly the command that I copied from the UniGetUI Log (see above).

[marticliment]

Yes, I know, this is the command UniGetUI uses to call WinGet to update the package.

If this command still presents this issue, then the issue is with WinGet, and not with UniGetUI