Microsoft.Winget.Client not updated at x86 location

[DrStrange]

Using PS I manually installed the PS module Microsoft.Winget.Client (v1.8.1133) after realising that UnigetUI 3.1.0 beta 1 required it but was failing to install it. Some time later UnigetUI said that there was an update to v1.8.1791 so it installed it. I noticed that the module in C:\Program Files\WindowsPowerShell\Modules is v1.8.1791 but it is also found in C:\Program Files (x86)\WindowsPowerShell\Modules. The module in the latter location is still v1.8.1133 so has not been updated.
In PS x64 $env:PSModulePath shows that C:\Program Files (x86)\WindowsPowerShell\Modules is not included in the list of locations but in PS (x86), $env:PSModulePath shows that C:\Program Files (x86)\WindowsPowerShell\Modules is included in the list of locations so I don't know why there is this difference? I've gone ahead and added C:\Program Files (x86)\WindowsPowerShell\Modules to the PSModulePath environment variable.

Is it safe to uninstall the module in C:\Program Files (x86)\WindowsPowershell\Modules if UnigetUI is a 64-bit program and so would not use this module?

Edit: Nevermind. I see beta 2 installs Microsoft.Winget.Client in one of the other default locations for PS Modules, namely the Documents folder and has put the module simultaneously in the Documents folder in my Admin and Standard User accounts.

[hueldoeu]

sometimes i have the problem, that unigetui says Microsoft.Winget.Client can get updated, but i can't install the update with unigetui and even weirder i can't find the update with cmd => winget upgrade. i just skip the update and rest peacefully

[marticliment]

As long as you have it installed, there is no need to have it on the latest version (at least when it comes to UniGetUI depending on it.)

[marticliment]

It is not found by WinGet because it is a PowerShell module

[hueldoeu]

what should i do? hiding the package?

[marticliment]

You can just Ignore updates for it

[ravensorrow]

This appears to be an error because PowerShell v5.4 (default install) and PowerShell 7.4 don't have a -Scope switch available.

Starting package update operation for package id=Microsoft.WinGet.Client with Manager name=PowerShell
Given installation options are <InstallationOptions: 
SkipHashCheck=False;InteractiveInstallation=False;RunAsAdministrator=True;Version=;Architecture=;InstallationScope=;InstallationScope=;CustomParameters=;RemoveDataOnUninstall=False>
Process Executable     : C:\Program Files\UniGetUI\Assets\Utilities\gsudo.exe
Process Call Arguments : "C:\Windows\system32\windowspowershell\v1.0\powershell.exe"  -NoProfile -Command Update-Module -Name Microsoft.WinGet.Client -Confirm:$false -Force  -Scope CurrentUser
Working Directory      : C:\Users\grunk
Process Start Time     : 11/1/2024 12:17:18 PM
Update-Module : A parameter that matches the parameter name 'Scope' cannot be found.
At line:1 char:68
+ ... e -Name Microsoft.WinGet.Client -Confirm:$false -Force -Scope Current ...
+                                                            ~~~~~~
+ CategoryInfo          : InvalidArgument: (:) [Update-Module], ParameterBindingException
+ FullyQualifiedErrorId : NamedParameterNotFound,Update-Module
Process Exit Code      : 1
Process End Time       : 11/1/2024 12:17:21 PM

Having dumped the output of powershell.exe -help and pwsh.exe -help to a text file and searching for Scope in the output reveals that it is not a valid option for either version, but the update process is calling it, as can be seen above. At first, I thought it was because UniGetUI was calling v5.4 and not 7.4, but before trying to figure out how to make UniGetUI use 7.4 instead, I decided to poke around and see if it was a valid switch.

/mnt/d/tmp
❯ grep pwsh_help_v5.4.txt "Scope"
grep: Scope: No such file or directory
❯ grep pwsh_help_v7.4.txt "Scope"
grep: Scope: No such file or directory

/mnt/d/tmp
❯

And just for transparencies sake;

D:\> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.4.6
PSEdition                      Core
GitCommitId                    7.4.6
OS                             Microsoft Windows 10.0.19044
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

D:\> powershell
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Try the new cross-platform PowerShell https://aka.ms/pscore6

PS D:\> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.19041.5007
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.19041.5007
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1


PS D:\>

[ravensorrow]

UniGetUI informed me a few hours ago that winget.exe was corrupt and must be repaired. After doing that, I was prompted by UniGetUI to update itself. Upon letting UniGetUI update itself, it successfully installed Microsoft Winget.Client with/ zero issues.

[BayIsland757]

I found to fix this issue, open powershell and give it this command:

Install-Module -Name Microsoft.WinGet.Client -force

That will do it.

[hueldoeu]

where do i have to enter it?

[BayIsland757]

I ran that in a powershell window. Click on Search box and type in POWERSHELL and enter

[hueldoeu]

I ran that in a powershell window. Click on Search box and type in POWERSHELL and enter

thank you. now only 2 packages are left:

also VLC and qbittorrent but VLC 3.0.21 is only .exe available, no more .msi so far (i prefer .msi but i think i will switch to VLC-installer.exe) https://www.google.com/search?q=vlc+3.0.21+msi and qbittorrent has this problem where winget THINKS it has been updated but qbittorrent still is the old version (because in the installwizard you can see that it wants qbittorrent removed from the RAM before updating. somehow the installer doesn't do it on its own) qbittorrent/qBittorrent#18115 unigetUI (or winget?) also has the problem, that even if i remove qbittorrent from RAM before updating it, it installs qbittorrent_5.0.1_x64_setup.exe but i need/want qbittorrent_5.0.1_qt6_lt20_x64_setup.exe . the notification for megasync appears very early and it takes time that mega-app updates itself (yes! mega updates itself, i get notified after the update had been successful. mega helped me alot uploading scientific books on it and reading them everywhere i want).

[ravensorrow]

qbittorrent has this problem where winget THINKS it has been updated but qbittorrent still is the old version (because in the installwizard you can see that it wants qbittorrent removed from the RAM before updating. somehow the installer doesn't do it on its own)

So kill QBitTorrent before updating. Problem solved. It's not UniGetUI's job to term the apps before updating; it's up to the developer's installer package.

[hueldoeu]

qbittorrent has this problem where winget THINKS it has been updated but qbittorrent still is the old version (because in the installwizard you can see that it wants qbittorrent removed from the RAM before updating. somehow the installer doesn't do it on its own)

So kill QBitTorrent before updating. Problem solved. It's not UniGetUI's job to term the apps before updating; it's up to the developer's installer package.

i prefer auto-install since unigetUI is so awesome and well programmed. i let unigetUI (i prefer writing unigetUI more than UnigetUI or UniGetUI) total control on my devices and my clients devices.