Bug: Unable to uninstall Chrome (except as admin) (winget version)

[ppvnf]

Uninstalling as admin works. It's also possible to uninstall it using unelevated Powershell (this issue also applies to Chrome dev, beta, etc.):

I believe the scoop version isn't affected by this.

[ppvnf]

I did a few tests. Updating is working and interactive uninstall is also working, however WingetUI is detecting the package (at least for Chrome dev) as not being installed by Winget, which is false as you can see it the shell:

[marticliment]

as not being installed by Winget, which is false as you can see it the shell

However, this won't change the uninstall command (local pc and winget are handled in the same way)

[ppvnf]

as not being installed by Winget, which is false as you can see it the shell

However, this won't change the uninstall command (local pc and winget are handled in the same way)

I see... I thought not being able to uninstall was because of the package not being correctly identified by Winget. I just remembered that I had the same problem with Microsoft Visual C++ Redistributable packages a few days ago. I believe the cause was the manifests being changed. I am gonna open a new one not bloat this one, but feel free to unify them if you wish.

[marticliment]

What would happen if you ran winget uninstall --id Google.Chrome -e --silent?

[ppvnf]

What would happen if you ran winget uninstall --id Google.Chrome -e --silent?

I am also getting error 1603 on Winget-cli. So, this isn't a problem with WingetUI after all?
What about as a workaround automatically trying to uninstall without silent parameter when this error appears?

[marticliment]

I don't think.

What i suspect is happening is that the --silent flag in winget prevents msi installers (chrome and some older vcredist) from showing the UAC prompt, failing with oc 1603. Running as admin already gratns needed provoleges so it works ok.

I reckon this is an issue with winget-cli, though

[marticliment]

I can try to create some kind of fallback, that when uninstalls fail they'll be ran without the --silent flag, what do you think?

[ppvnf]

I can try to create some kind of fallback, that when uninstalls fail they'll be ran without the --silent flag, what do you think?

I don't see any downside for doing that

[ppvnf]

There's an issue about this error on microsoft/winget-cli#248, but it's about installs and not related to Chrome so I am gonna open a new one

[ppvnf]

I've just tested winget uninstall --id Google.Chrome -e --silent today and somehow it worked fine on Winget-CLI, but WingetUI still fails with error 1603

[marticliment]

can you please test that same command but with the winget versio bundled in WingetUI? %localappdata%\programs\WingetUI\winget-cli\winget.exe

[ppvnf]

can you please test that same command but with the winget versio bundled in WingetUI? %localappdata%\programs\WingetUI\winget-cli\winget.exe

Never mind, I think I accidentally opened Powershell as admin before. I've tried again and winget uninstall --id Google.Chrome -e --silent fails on both bundled and system PowerShell. I've opened an issue about this there: microsoft/winget-pkgs#82692
I believe this is a good idea. It would be even better if Microsoft implemented it on Winget-cli though

[ppvnf]

I got an answer here:

One of our key design criteria has been supporting "unattended" installations to support things like winget import packages.json. We might consider a fallback approach to "non-silent" installs once we have some user driven settings or arguments to allow users to select that behavior.

[marticliment]

Well, they are not going to fix it, we'll need to do it ourselves.

[marticliment]

Fixed!

[marticliment]

Now when the error occurs it immediately re-runs the uninstall command with administrator rights