Is it possible? Detection fails depending on PS version in system context?

[KnifMelti]

As title says (when running in an admin user context there's no problem) ...

...with https://www.nirsoft.net/utils/advanced_run.html Run (with installed TimKosse.FileZilla.Client): -AppIDs TimKosse.FileZilla.Client -Uninstall -WAUWhiteList (TimKosse.FileZilla.Client-uninstall.ps1 takes care of the whait for the graphical uninstall UI)

Results: Win 11 PS: 5.1.22000.1 (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\3\PowerShellEngine)

20:27:21 - Using following Winget Cmd: C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.17.10271.0_x64__8wekyb3d8bbwe\winget.exe (v1.2.10271)
/../
20:27:45 - TimKosse.FileZilla.Client successfully uninstalled.

Win 10 PS: 5.1.19041.1 (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\3\PowerShellEngine)

20:40:26 - Using following Winget Cmd: C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.17.10271.0_x64__8wekyb3d8bbwe\winget.exe (v1.2.10271)
/../
20:40:39 - TimKosse.FileZilla.Client is not installed.

And, it's not only TimKosse.FileZilla.Client.. ..it's the detection itself and goes for every application detection on my Win 10 with Powershell 5.1.19041.1...

[KnifMelti]

...haven't tried yet with this PS version for real (under SCCM), but it detects correctly with AdvancedRun as System under Win 11 PS: 5.1.22000.1...

Tested a bit more and nope, it isn't the version of Powershell:

• Ran %comspec% as System via AdvancedRun
• Changed dir into "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.17.10271.0_x64__8wekyb3d8bbwe"
• Ran winget.exe list --Id TimKosse.FileZilla.Client --accept-source-agreements>d:\list-system.txt
• Ran (as user) winget.exe list --Id TimKosse.FileZilla.Client --accept-source-agreements>d:\list-user.txt

Result: The list-system.txt contains:

   -\|/-\|/ 
   -\|/-\|/-

The list-user.txt contains:

   -\ 
   -\ 
Name             Id                        Version Source
----------------------------------------------------------
FileZilla Client TimKosse.FileZilla.Client 3.59.0  winget

This is really weird... ..."winget.exe source reset --force" didn't help... "winget.exe list" as System is totally empty

[KnifMelti]

It's not a scripting issue.

[KnifMelti]

https://github.com/microsoft/winget-cli/discussions/2096

[Romanitho]

Same here on some computers. Sometimes if I uninstall, reinstall Visual C++ and restart it works. But not sure. Maybe it's due to something else. (I open it to keep tracking)

[KnifMelti]

Which one (of the 24 installed) Microsoft Visual C++ Redistributable (developing machine) do you propose I should uninstall/install then ;) Which one do you choose when you have the issue?

[Romanitho]

My recent tests was on a fresh install. When I install 2022 as system and reinstall it as admin user. But I think its not really related to this. Not sure

[KnifMelti]

I uninstalled all 2013, didn't reboot and suddenly it did work one time! Tested one more time and it failed... Rebooted and still failing... ...so, related/unrelated - it's something...

[Romanitho]

One interesting thing : If I update winget with their latest preview release, it works again ^^ https://github.com/microsoft/winget-cli/releases/tag/v1.3.431

And it resolves one bug I had to workaround in the script :
Winget upgrade --accept-source-agreements was buggy. That's why we had Winget list --accept-source-agreements in the script.

[KnifMelti]

Then it's the classic Microsoft wait... ;)

[Romanitho]

I think i'll use the preview one in production as it looks more stable than the current one ^^

[KnifMelti]

Then you've have to install it on every client first...

[Romanitho]

yes. I was thinking about detecting Winget version on WAU first install. Then, put WAU as prerequisites when I install apps with Intune or SCCM for example.

[KnifMelti]

Yes, a prerequisites dep. to WAU is on my mind also! But.. ..with that amount of apps with dep. to WAU it'll get messy in SCCM/revisions. I think that I'll push out WAU with a empty whitelist first to all of the clients beforehand.

[Romanitho]

I have a PR waiting for publishing in WAU repo :) And for dependencies, normally everything is (or will be) in the WAU install script. In that case, I only put WAU as a prerequisite of my apps installed with Winget-Install script

[KnifMelti]

Could you also incorporate the Mods solution for WAU it would be nice: https://github.com/Romanitho/Winget-AutoUpdate/issues/42 With $ModsInstall both for Upgrade/Install

[Romanitho]

we can create a separate PR for that. by the way, how do you handle your "AppID_upgrade.ps1" mod files ?

Edit: https://github.com/Romanitho/Winget-AutoUpdate/discussions/57

[KnifMelti]

The same way as in winget-install.ps1:

        #Check if mods exist
        $ModsInstall = Test-ModsInstall $AppID
        if ($ModsInstall){
            Write-Log "Modifications for $AppID during install are being applied..." "Yellow"
            & "$ModsInstall"
        }

I'll create an PR out of Issue #42 (not now, I'm too busy) :)

[KnifMelti]

Ah, https://github.com/Romanitho/Winget-AutoUpdate/discussions/57...

[KnifMelti]

WAU Mods done. Winget latest preview release solution to the crash in winget list/export

[EricPez]

hello I am having exactly the same issue. Do someone has already found a way to fix that ? or shall we have to wait on Microsoft to release a fix with an upcoming Windows Update ?

[KnifMelti]

hello I am having exactly the same issue. Do someone has already found a way to fix that ? or shall we have to wait on Microsoft to release a fix with an upcoming Windows Update ?

Winget latest preview release solution to the crash in winget list/export

[Romanitho]

Link to download Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle