As of Build 1607: WinGet

Since 2021, Microsoft has offered its own package manager for the command line: WinGet. Unlike Chocolatey, the condition for installing this tool is the operating system's ability to install apps from the Microsoft Store, which is why WinGet is only installable on Windows 10 as of build 1607, with Windows Server 2019 and older left out in the cold. Although you can theoretically install WinGet on Server 2022 (e.g., as described by Andreas Nick [6]), WinGet is not officially supported there.

WinGet is already pre-installed on the current builds of Windows 10 and 11, which gives you access to two repositories: winget and msstore . WinGet can download and install apps from the msstore repository in the same way as the graphical Microsoft Store app, whereas the winget repository contains various programs that are available in different formats (e.g., MSI installers or MSIX packages, ready-made store apps, or scripts).

A WinGet package is represented by a YAML manifest that can include one or more files. For example, if a package is offered in multiple languages, its manifest comprises at least four files: version, installer, default locale, and one additional locale file per supported language. You can submit a finished manifest to the community repository microsoft/winget-pkgs with a pull request on GitHub. The pull request triggers a validation process, after which your package is released and can be found and installed by the WinGet instances of all Windows users connected to the Internet. This process is fundamentally different from submitting apps to the Microsoft Store, which requires a dedicated developer contract and imposes far stricter content guidelines.

Initially, WinGet's command structure looks very similar to that of Chocolatey (Figure 2), which is hardly surprising, because both package managers are oriented toward the Linux role models and seek to offer people switching from Linux administration as familiar a user experience as possible. Beyond the basic range of functions, however, WinGet and Chocolatey differ considerably, as you can discern from the command set.

Figure 2: The command structures of WinGet and Chocolatey are similar.

Operating Private Repositories

Like AppGet, WinGet follows a philosophy different from Chocolatey regarding the distribution of binary installation sources. Whereas a Chocolatey package always contains the installation files, the artifact (a deployable component of an application) in a WinGet repository is typically just a manifest containing the download path for the installation sources and the instructions for installation.

Microsoft provides instructions and sample code [7] that you can use to create a private WinGet repository in the form of an Azure resource. The resulting REST API is documented and can be implemented on an on-premises web server. A few community projects make this possible, but none have made it to production maturity yet. If you want to deploy a private repository for WinGet, Azure is your best bet right now.

PowerShell Support

As nice as the original command line is in Windows, many Windows admins now expect to be able to operate the system of their choice with PowerShell. The success of Foil [8] – a wrapper for the choco command-line program created with Microsoft's Crescendo technology – shows how great the interest in this functionality is in the Chocolatey user community. Although this module, created by Ethan Bergstrom, was still classified as version 0.1.0 by the author at the time of writing, it has been downloaded almost five million times since its release in September 2021.

Another PowerShell artifact category that is gaining popularity is Chocolatey-based Desired State Configuration (DSC) resources, which let you keep both your Chocolatey installation and the packages installed with Chocolatey up to date. The official resources from both Chocolatey and community developments have six-figure download numbers.

At its core, Chocolatey is even more intertwined with PowerShell, with PowerShell commands providing the basis for installing Chocolatey packages. You also have access to a great abundance of PowerShell modules and scripts for creating packages.

PowerShell support for managing packages with WinGet is not as advanced, although WinGet is a Microsoft product. The highest download numbers in the PowerShell Gallery so far are for two projects also penned by Bergstrom – the Cobalt Crescendo wrapper and the WinGet module on which it is based.

The reason no DSC resources have yet been submitted could be because WinGet is reserved for clients, whereas servers are usually configured and managed by DSC. When it comes to creating WinGet manifests, Microsoft has so far only offered a winget-create [9] command-line tool, but not a PowerShell module.