The Windows Package Manager is Microsoft's answer for simplifying the deployment and management of applications within the Windows ecosystem. The WinGet client, generally synonymous with Windows Package Manager, is the main face of this relatively new package system and offers a command-line interface (CLI).

Drawing on the rich heritage of Linux package managers such as Apt and Windows-native equivalents such as Chocolatey and AppGet, WinGet signifies Microsoft's most direct effort to refine the software installation experience for administrators, developers, and users. Since its launch in May 2021 with version 1.0, Windows Package Manager has quickly gained acceptance through community adoption of WinGet and its public repository, with more than 4,000 package contributions. In this article, I touch on the WinGet CLI and the associated app lifecycle and provide an overview of creating and sharing your installer in a WinGet package format.

Why WinGet?

The evolution of package management in the Windows ecosystem has been more than 10 years in the making. Chocolatey, initially a small project that gained traction through Kickstarter support, has evolved into a robust ecosystem, significantly strengthened by the success of its funding campaign. This gradual progression has set the stage for future developments in Windows package management. Meanwhile, another project, AppGet, was also quietly taking shape.

The package management scene for Windows took a notable turn in 2020, with an announcement at the annual Microsoft Build conference of the Windows Package Manager WinGet client, marking a new era in Windows software management. WinGet consolidated crucial features from predecessors such as AppGet, creating a comprehensive package management solution for the Windows ecosystem. The success of a package manager hinges on active community participation and meeting the needs of users, developers, and system administrators; WinGet has made substantial progress in garnering community contributions and user acceptance over the past several years [1].

WinGet from the Command Line

The primary method of engaging with WinGet is through the CLI with the winget tool. Table 1 is an overview of common commands and useful options. To get started, fire up a CMD or Terminal session and ask WinGet for help with the question option:

winget -?

If you want to search the WinGet public repo for packages with names that might include "PowerShell," or be tagged as such, use the command shown in Listing 1 with its output.

winget search Microsoft.PowerShell
Name                 Id                            Version   Source
--------------------------------------------------------------------
PowerShell           Microsoft.PowerShell          7.4.1.0   winget
PowerShell Preview   Microsoft.PowerShell.Preview  7.5.0.2   winget
PowerShell Preview   9P95ZZKTNRN4                  Unknown   msstore
...

The first two rows list packages sourced from the winget repo, and the third row has a package sourced from the msstore repo (Microsoft Store). The winget package source is the main Community repo, whereas msstore is the repo for the store directly integrated into Windows.

To continue the example, install the preview edition of PowerShell:

winget install --id Microsoft.Powershell.Preview --source winget

Note that, in this instance, you explicitly specify the repo source. This option will be helpful later when designing private repos. After installation, you should be able to locate the pwsh executable binary under C:\Program Files\PowerShell\7-preview.

For the following installation example, install the well-known editing tool Notepad++, which is available from the Notepad++.Notepad++ package maintained in the WinGet repo:

winget install -e --id Notepad++.Notepad++

Figure 1 shows the start page for winget.run, a web app and API that provides a search feature for all packages available in the public repository. The homepage view also defaults to rendering a recently updated package list.

Figure 1: The winget.run homepage.

If you are interested in the Chrome browser application, for instance, you can search for the package and then proceed to install by copying the command under How to install :

winget install -e --id Google.Chrome

Alternatively, you can look up and use the friendly name for Chrome or use a shorthand package reference, e.g., for Visual Studio Code:

winget install "Windows Chrome"
winget install VSCode --verbose-logs

The install command supports various options, including verbose logs, as specified here. Utilizing the logging options of the winget command line is beneficial for troubleshooting or debugging failed package installations. It also offers a detailed record of the copied artifacts and any local modifications made during the setup or installation of software packages (e.g., created registry entries).

To view or inspect the logfile manually, use

winget --open-logs

This option opens a package subdirectory by Windows context, local state, and diagnostic output. You might need to navigate the directory to find and examine the logfile text, which contains timestamps for each setup action. Initially, it logs the path to the original setup executable and the options used for initiation (e.g., /SILENT, /SUPPRESSMSGBOXES).

Actions performed during the setup appear at the top of the logfile. Each copied or installed file generates a log entry. Registry entries are also recorded, further enhancing traceability. You can use

winget --info

to determine the local, absolute path where logfiles are stored. The console output displays the log settings, commonly rooted in the %LOCALAPPDATA% directory.

App Management Lifecycle

The classic lifecycle of an application is to install, maintain the application binary and artifacts over many updates, and eventually remove or uninstall it. I'll walk through this command cycle with several WinGet command-line examples. To begin, search the public repo for Wireshark:

winget search --id WireSharkFoundation

To review package details, use the show command and query and have past versions printed to the console:

winget show -e --id WiresharkFoundation.Wireshark --versions

The -e option ensures an exact match of the identifier. You can also view past version details by heading to the website [1], looking up the package of interest, and viewing past versions in your web browser. For example, to install the earlier 4.0.2.0 version of Wireshark that comes before those with a known bug, enter:

winget install --id WiresharkFoundation.Wireshark --version 4.0.2.0

If the Wireshark development team social media feed later reveals that the particular bug has been fixed and an updated version addressing the issue and incorporating the latest features is now available, you can proceed with the upgrade as follows:

winget upgrade --id WiresharkFoundation.Wireshark

Because Wireshark is not for mere mortals and you might be working on a shared computing environment, once its purpose is fulfilled, you can remove the software:

winget uninstall --id WiresharkFoundation.Wireshark

Note that many winget commands have an alias, which you can discover with the winget show command.