WinGet is a command line tool that works in Command Prompt and PowerShell. It works with Windows install packages for apps and applications. In the words of the Microsoft Learn “Use the winget tool…” article, winget “…enables users to discover, install, upgrade, remove and configure applications on Windows 10 and Windows 11 computers.” Behind the scenes, winget works with the Windows Package Manager service, and acts as its command line interface.
Where Is WingGet?
By default, WinGet (the capitalization comes from its GitHub home page, though MS itself refers to the tool interchangeably as winget and WinGet) is included with all versions of Windows 11. It has been included in Windows 10 since version 1709 (the current version is 22H2). If you’re running Windows 10, you’ll also want to install the latest PowerShell (7.4.2 as I write this) to take best advantage of it capabilities. Do so easily with this WinGet command:
winget install Microsoft.Powershell
Most users should, however, be able to fire up PowerShell or Command Prompt and simply start using the WinGet command. The next section provides a primer on the WinGet commands syntax and structure. If you want to experiment with WinGet in isolation from your normal or production desktop environment, follow the MS Learn document’s instructions in the “Install winget on Windows Sandbox” section.
WinGet Commands and Options Overview
In looking over the WinGet commands and its command-line options, it’s easy to tell that this tool was built for developers. Indeed, unless you are a developer you’re unlikely to use many of the WinGet commands at all. Even so, here’s a brief but complete list of commands and options, courtesy of the built-in PowerShell help facility:
Key Uses for WinGet: Find, Install, Update and Uninstall Apps
Developers use Winget to distribute software packages to various online sources (the default source is a Microsoft repository named “winget”). Packages come with manifests that describe their constituent files, which usually include .msix, .msi, or .exe installer files and supporting infrastructure elements (e.g. DLLs and so forth). Packages often come from the Microsoft Package Manager Community Repository on GitHub (aka source: winget) or from the Microsoft Store (source: msstore).
End-users are the focus for this story. As the preceding head says, they use WinGet to find, install, update and uninstall applications as needed. Keep that in mind as you work through this alphabetized list of command line options, rearranged from the preceding screenshot (options start with double dashes, though a single dash and the first letter works most of the time, too).
Table 1 shows the command or option name (which will follow WinGet at the command) line left, and a brief explanation right. Items marked with an asterisk are developer oriented; items marked with a plus sign are for advanced users. Going forward, this story focuses on items that are unmarked.
| Configure+ | reads a configuration file to download and install packages to match a specific configuration |
| --disable-interactivity* | turns off interactive prompts (typically used in automated scripts) |
| Download+ | downloads an installer from a specific package to current host |
| Export+ | exports a list of all installed packages to a configuration file |
| Features+ | shows status of experimental features (requires a preview version to use) |
| Hash* | helper/wizard to assist developers with hashing of installer files for packaging |
| --help | accesses built-in PowerShell help, works at multiple levels, as does -? |
| Import+ | Installs all packages as listed in a configuration file |
| --info | shows information about winget command |
| Install | installs a specified package, as per command details or options |
| list | displays information about installed (local) packages |
| --logs+ | opens the default winget logs location in File Explorer window |
| Pin+ | manage package pins (used to prevent or allow updates) |
| Repair* | repairs a specified package |
| search | find and show basic package data |
| Settings+ | provides access to winget’s .json settings file to manage app behavior |
| show | shows information about a package (from a source database, e.g. winget) |
| source | manage package sources (e.g. winget, msstore, other third-party sites) |
| uninstall | uninstall a specified package |
| upgrade | update a specified package |
| Validate* | check a manifest file for accuracy and completeness |
| --verbose* | turn on verbose logging |
| --version | show the current running WinGet version number |
| --wait* | prompt user to strike some key before exiting Winget |
After all is said and done, the key WinGet commands and options (unmarked in Table 1) are: --info, --help, install, list, search, show, source, uninstall, upgrade, and –version. Let’s explore these further in the sections that follow.
Working with WinGet: Day-in, Day-out
Though it is also handy for installing and removing packages, WinGet serves me primarily as an update tool. That is, it surveys installed Windows packages. By comparing the installed version to the most current version in one of its source databases (usually, and by default, the WinGet repository on GitHub) WinGet upgrade reports any and all packages it finds in need of an update. This means the version in the repository is higher-numbered than the one it finds installed locally. Here’s an illustration from a Windows 11 SFF PC (Dell OptiPlex 7080):
The WinGet command I use most frequently is (nearly daily, on most of my PCs):
Winget upgrade --all --include-unknown
This tells WinGet to install all packages for which a higher-numbered version is available from the repository, even if the name and Id information (first and second columns above) isn’t completely matched (partial matches are OK: that’s what include-unknown enables). Here’s what that looks like from the same PC:
The only applications that WinGet can’t update are those for which developers do not provide package manifests to some repository. Occasionally, I’ll also run PatchMyPC to catch and update common applications outside the WinGet umbrella.
Using WinGet Install/Uninstall
Most of the time, when I use the install and uninstall WinGet commands, it’s because an update/upgrade fails. WinGet is inherently conservative: if it detects some difference between the current installer and its downloaded replacement, it won’t apply an upgrade. Instead, it issues an error message that mentions a different install technology as grounds for a failure to update.
Indeed, this occurred to me recently when attempting to upgrade PowerShell itself. The precise information reads “The install technology of the newer version is different from the current version installed.” It also prescribes an appropriate response.
The remaining text at the bottom of the screencap reads “Please uninstall the package, and install the newer version.” That means using the following sequence of commands:
Winget uninstall Microsoft.PowerShell
Winget install Microsoft.PowerShell
The first command removes the code for the old version from the PC, while the second replaces it with the new version. PowerShell is smart enough to keep running from an in-memory version while it does away with the old, and brings in the new. But after that sequence of commands it will instruct you to close and then re-open PowerShell to flush that (old) in-memory version and bring the new one up afterward.
Finding packages with Search, List and Show Commands
Both winget search and winget show access information from some winget source (by default, the WinGet GitHub repository). Use these commands to explore what’s “out there” that matches the search string provided. Here’s an example, based on the PowerShell display settings script/tool called “winfetch”:
Using WinGet search and show commands provides different levels of detail.
As you can see in the preceding screenshot, search simply provides a brief indication if a string match is found in the target repository. Show, on the other hand, produces the full repository information for matches. Note that using the “hit name” for the winfetch utility works for search but not for show: I had to use the ID value (nepnep.neofetch-win) to make it appear (the Name string neofetch-win works as well). In general, the closest unique match will work for show, whereas anything close often works for search.
Winget list works like search but searches for local installed packages. After installing winfetch on the PC from which the preceding screencap was taken, here’s what winget list neofetch-win produces on that same machine (same results for the full ID string):
Two Key Options --version and --info
You can sometimes abbreviate full-length options with a single dash and the first letter. As you can see in the next screencap, -v works just like --version to show a numerical version number for the running WinGet instance. You must, however, enter winget --info to produce the full winget information block, as shown.
Putting WinGet to Work on Your PC(s)
Open a PowerShell or Command Prompt session on your PC (or PCs). Type winget -v to see if it’s installed: you’ll get a version number like the v.1.7.17261 shown in the preceding screenshot if it’s there; you’ll get an error message that begins “The term ‘winget’ is not recognized…” if it’s not. In the latter case, visit the WinGet GitHub page to grab and install the most current version (scroll down until you see the green “Latest” button under the Releases heading in the right-hand column).
It's become a matter of (near) daily routine to use WinGet to keep Windows packages up to date on my modest fleet of Windows PCs (a dozen physical devices, with an equal number of VMs scattered about on the better-endowed laptops and desktops in this group). WinGet is a terrific tool that works well in scripts (programs also, through its API) as well as interactively. The more you get to know Winget (Id = Microsoft.AppInstaller) the better you’ll come to like it. If you’re not using it already, you owe to yourself to give it a try. As a parting screenshot, here’s the output from winget list Microsoft.AppInstaller and winget show Microsoft.AppInstaller. Enjoy!
