Uninstall an installed App

[denelon]

As a user I want to be able to use winget to uninstall a package so I don't have to go through the Add/Remove software UX.

Experimental Feature
winget uninstall <package> - uninstalls the specified package.
winget uninstall -? - displays help for the uninstall command.

Note: uninstall depends on list also being enabled.

winget features - displays all experimental features and their status
winget settings - launches settings.json to configure settings like experimental features

Note:
There are limitations about how programs get installed and whether or not that binary supports uninstall. This may also need to be supported in the manifest with new key(s) and or syntax.

Edited: experimental status

[phiresky]

This is never going to happen since packages just consist of running random executable files that can do whatever they want. There's no package building step or anything.

(edit: see also my clarification below)

[jedieaston]

Chocolatey (and scoop in certain scenarios) already does it through running the uninstaller that is registered in the control panel, I thought. winget could do a similar thing, although the flags for a silent uninstall would have to be in the manifest somewhere.

[michaelvolz]

IMHO this is basic functionality which is paramount for the success of winget.

[Smart123s]

This is never going to happen since packages just consist of running random executable files that can do whatever they want. There's no package building step or anything.

There could be references to the programs' "uninstaller" executables as well.
For example, it could launch C:\Program Files (x86)\Steam\uninstall.exe to uninstall Steam.

[Karl-WE]

The uninstaller reference comes with every installation. There are RARE cases of applications that cannot be uninstalled this way but it is doubtful they will be ever accessible / installable via winget.

Other than that you can clearly uninstall all apps using a WMI call and I have even borrowed a method someone else that is even able to crawl the registry for uninstalling applications by a name or wildcards.

Without blaming anyone, I certainly support an /u --uninstall switch, which can also be combined with /h --silent

[Karl-WE]

in terms of naming i would not use Winget remove, imho as it is "install" it should be named "uninstall" for ease of use. https://github.com/microsoft/winget-cli/issues/192

[masx200]

i support it

[phiresky]

For clarification about what I meant with my (admittedly flippant) comment above, see these three threads:

• Not a package manager #223
• https://news.ycombinator.com/item?id=23238051
• https://www.reddit.com/r/programming/comments/gmqv6n/microsoft_announces_the_windows_package_manager/fr5pasi/?context=3

Basically, my point is that since this works by running arbitrary exe files on the host computer, the only thing it can do to uninstall something is run another arbitrary exe, again pulled from 3rd party sources. That exe can do anything, especially not clean up all the crap left by the install process.

What you expect from package managers (coming from other OSs) is that they build packages that are pretty much just declarative file archives with as little logic as possible, then those are installed with logic defined almost completely on the side of the package manager instead of the to-be-installed app. The logic that comes with the package itself is minimal if it exists at all, runs at specific times with specific functions (preinstall / postinstall / etc) and is declared as readable code (e.g. shell scripts). The package manager or user then can also verify that the package does not do anything weird like copying files to unusual locations or removing other files, or setting up / starting system services. (that's also a job of the package manager).

[Karl-WE]

Yes in fact what you are describing is something like MSI or MSIX / Windows Store that allows an internal uninstall via WinGet while at the moment and forseeable future winget is just the commandline (now also GUI) proxy for this task, but relies on some of the mentioned packagers and installation methods.

[Mallchad]

I don't understand, if one of the intents of this program is to let allow you to install pre-existing software as well as any packages it may have.
Is it not possible to run an installer in a kind of sandbox and track installed files?
Projects such as Nix, GNU Stow and Arch packages ect ect have worked hard to provide similar functionality with streamlines the proccess with the only difference being that almost always programs are explicitly made to interface with this proccess.
Would it not be possible to achieve similar funcitonality with this?
There might be some issues with cleaning up files after the installation proccess, but this is a problem that no package manager (that I know of) has solved, and a package manager like this in it's early development could look to solve it, especially since it is official some of this functionality could be facilitated with the kernel.

[Caltor]

This is basic functionality for a package manager really. Without that we have something that is just barely above a powershell script or even a good ol' batch file.

[KevinLaMS]

I have an early draft started of the spec. I am not tackling the notion of a sandbox at this time.
#397

[sredna]

SystemAppId is not enough to provide a proper uninstall experience IMHO.

There might be a need for a UninstallSwitches section with at least a Silent entry in the manifest. Unless we want to assume that all uninstallers support the same silent switch as its installer?

It would also be nice if winget tried the de facto standard QuietUninstallString registry value (if it exists) before using UninstallString.

When it comes to actually running the uninstaller, it is a good idea for winget to use a Job object on the uninstaller process so it can wait for all the children like Add/Remove programs does.

If you don't want to use a job object but still want to wait for the process then custom actions are required. For nullsoft this means using its special uninstaller syntax. In a batch file that would look something like this:

@echo off
REM This is a ugly mess because it is very hard for a running .exe to delete itself on Windows.
set "installdir=c:\program files\foo"
set "uninstbin=%installdir%\uninstaller.exe"
call "%uninstbin%" /S _?=%installdir%
if errorlevel 1 goto failed
del "%uninstbin%"
rd "%installdir%"
:failed

[BrainSlugs83]

This is never going to happen since packages just consist of running random executable files that can do whatever they want. There's no package building step or anything.

That's just silly. -- If the package registry can specify an executable which can be run to install a given package, then it should be able to specify an executable that can be run to uninstall a package.

BTW, upon doing a quick search, it looks like package manifests are just yaml files -- so someone does have to build them -- apps don't just automatically have yaml files for no reason. (Not to mention there's a PowerShell script on that page that helps develops build their package manifests...)

And if you can put an "Installers" key in your yaml file, you can sure as heck add an "Uninstallers" key with the exact same info. 😑

[DiegoMagdaleno]

I agree with @BrainSlugs83 you can have contributors declare an uninstall key, that the program just executes, just like Homebrew formulae does, so you can have "if the user wants to uninstall do this: blah blah blah" and it would work without issues imo.

[keenbowl3009]

@jedieaston Microsoft is now in a great position to make MSIX better (drop signature requirement, add direct support to common setup wizard frameworks to make adoption easier, ...) and push it using winget ("you can put your app on winget, just use this installation format your pipeline probably already supports"). Once winget is included in Windows, developers might even use it to auto-update their apps basically for free. I don't think there's a high chance of this happening, but it would surely be great.

The MSIX format is really horrendous because it allows the insertion of DRM in software through the form of the AppxBlockMap.xml files.

On top of that, it is only supported on windows.
It is really the most horrible and frustrating one of the choices.

Really really awful that microsoft is attempting to push forward with the locking of windows, without fixing any of the underlying problems of the platform.

[JanPokorny]

@keenbowl3009 Most paid software already has DRM, with or without MSIX.

Also, how is "it is only supported on Windows" an argument? Scoop is only supported on Windows, Homebrew is only supported on Mac and Apt is only supported on Linux, does that make them bad?

[keenbowl3009]

scoop is a shell script that unzip files, and adds to path.

can you unzip files, and add them to path with winget?

[keenbowl3009]

https://devblogs.microsoft.com/commandline/windows-package-manager-preview/

You are going to be able to winget install your way to bliss. One of the best parts is that it is open source. I had to pinch myself when I was able to winget install terminal, and then winget install powershell, and then winget install powertoys.

Can you winget install any of those from the original winget annoucement?

[JanPokorny]

scoop is a shell script that unzip files, and adds to path.
can you unzip files, and add them to path with winget?

No, it's on the roadmap, and I don't get how it's related to the previous conversation.

Can you winget install any of those from the original winget annoucement?

All of them! In fact I installed all of these through winget. What are you even trying to say?

[jthoward64]

Given that

A. You don't like winget
B. You like scoop

I suggest that you

Use scoop

EDIT: also could a mod mark everything for the last hour as off topic please? @denelon

[Masamune3210]

Yet another bad faith argument, seems people love these lately

[denelon]

@tajetaje Since this issue is closed, I don't see much value in marking the thread "off topic". Unfortunately, there probably isn't a single solution that will make everybody happy. Sometimes people want to make sure they are heard. There are several tools attempting to solve the problems related to managing software on Windows. We're not trying to replace any of them. We're trying to meet developers where they are and have a plan to go forward in time. Some of the constraints we're trying to adhere to make the problems more challenging in some areas and easier in others. Hopefully over time, we will build something that is flexible enough to give the control users want and the flexibility to work with existing installers.

[JanPokorny]

@denelon > We're not trying to replace any of them.

I'd be... more cautious with that statement. https://keivan.io/the-day-appget-died/

[keenbowl3009]

scoop is a shell script that unzip files, and adds to path.
can you unzip files, and add them to path with winget?

No, it's on the roadmap, and I don't get how it's related to the previous conversation.

Can you winget install any of those from the original winget annoucement?

All of them! In fact I installed all of these through winget. What are you even trying to say?

winget install powershell will literally give me an error.

On top of that, i'm afraid of even running that and permanently borking my machine.

[Masamune3210]

If you are getting a error installing something, open a ticket. Things can't get fixed if the devs don't know of the issue

[jthoward64]

@denelon > We're not trying to replace any of them.

I'd be... more cautious with that statement. https://keivan.io/the-day-appget-died/

#353 (comment)

Last I'll say on the topic

[JanPokorny]

@keenbowl3009 If you're afraid, don't use winget. Nobody is forcing you. If you want to install PowerShell manually, feel free to go to https://github.com/PowerShell/PowerShell/releases/download/v7.2.0/PowerShell-7.2.0-win-x64.msi and run it yourself, although be aware that you will be doing precisely the same thing as the winget you're afraid of.

Also there is no error, unless you mean the disambiguation note which happens if you enabled the msstore source and thus have two locations to install PowerShell from.

[JanPokorny]

@tajetaje Yeah, I know. I just felt the itch to point this out, due to the statement's wording reminding me of this controversy. (Also did the "something to share" already happen?)

[keenbowl3009]

Also there is no error, unless you mean the disambiguation note which happens if you enabled the msstore source and thus have two locations to install PowerShell from.

There is no error.
Unless, of course, there's an error.
Then the error is a feature!

[keenbowl3009]

@keenbowl3009 If you're afraid, don't use winget. Nobody is forcing you. If you want to install PowerShell manually, feel free to go to https://github.com/PowerShell/PowerShell/releases/download/v7.2.0/PowerShell-7.2.0-win-x64.msi and run it yourself, although be aware that you will be doing precisely the same thing as the winget you're afraid of.

Also there is no error, unless you mean the disambiguation note which happens if you enabled the msstore source and thus have two locations to install PowerShell from.

I have not "enabled" mstore.
It get's enabled by itself, automatically.
Absolutely no input on my side.

[keenbowl3009]

If you are getting a error installing something, open a ticket. Things can't get fixed if the devs don't know of the issue

Thanks.
#1711

[JanPokorny]

@keenbowl3009 Using command line package managers requires a basic degree of computer literacy, including the ability to comprehend bright yellow text in simple English. I am afraid that I can not help you further, sorry.

[Masamune3210]

If you already had a ticket, what was the point other than to scratch the chip on your shoulder you seem to have of bringing it up.
I'm done. Its obvious you arent acting in good faith and just want to stir up trouble

[EqualDust]

IMHO it is a dishonest attitude closing this issue since the uninstaller is currently broken and most of the time does not work.

[JanPokorny]

@EqualDust The feature is implemented, that's why this issue is closed. It can certainly be buggy for some uninstallers -- the correct attitude to fix this problem is to report each individual bugged uninstaller.

Also, stop creating new GitHub accounts, please.

[EqualDust]

every bug is a new account. Reporting each individual bugged uninstaller is inneficient, an org with resources like msft should be able to ship great products by default. How come scoop, completely community backed, get this right by default?

[Mallchad]

Please don't make an ordeal of this,
the topic of the issue has been resolved, if you have an issue (and I don't doubt you have),
it is correct to make a new issue.

This thread is getting long and very noisy now, noisy threads are hard to follow.
Are you will be bothering people that are still inadvertently following a virtually dead issue.