Unboxing

Installing and uninstalling applications in Windows traditionally involves running a graphical wizard. Unattended installs that depend on this type of installer are often troublesome. In comparison, installing an application on Linux is usually a piece of cake: Package managers such as Apt, Yum, and Zypper make sure that the sources are always up to date and resolve dependencies, and they usually do not require any parameters apart from the package name. However, Windows users also have some practical command-line interface (CLI) based package management tools.

In this article, I look at two solutions for full-fledged package managers on Windows: Chocolatey and Microsoft's WinGet.

Unique Installs

If you want to install a simple Windows program such as 7-Zip, GreenShot, or Notepad++, you usually download and launch the installer (EXE or MSI) and click through the graphical wizard, even though the same information is typically provided every time. All of the programs support unattended installation, but hardly anyone is familiar with the parameters, and it takes longer to look them up than to click through the installer. To keep applications up to date, you usually just install a newer version. Some programs, such as Notepad++ or KeePass, notify the user that an updated version is available, but downloading and installing are manual tasks.

Alternatives to the unique installation and updating of applications have been around for a long time. Since the introduction of the iPhone, proprietary app stores have become the standard for mobile devices, and Apple offers a similar solution for its macOS desktop operating system. Likewise, Microsoft has created a central platform for installing and updating applications in the form of the Microsoft Store, although the platform does not enjoy the same popularity among software providers as Apple's AppStore or Google Play – for many reasons. The bottom line is that even Windows end users tend to be reluctant to purchase software from the Microsoft Store.

Practical Repositories

For decades, Linux has successfully relied on a non-graphical approach for the large mass of open source and freeware applications and operating system-related tools: text-based package managers that access an extensible list of repositories to locate applications and libraries, determine their mutual dependencies, and ultimately enable installs, uninstalls, and upgrades. The packages listed in the repositories each have a specific format that varies from distribution to distribution.

The repositories are maintained in three ways:

• Distribution maintainers offer repositories that they pre-install when they ship their distribution. Most system-specific tools and libraries can be found here, but application programs are also sometimes included in the mainstream repositories to increase the versatility of the distribution. The maintainers vouch for the quality and mutual compatibility of the packages on offer, which means some serious overhead for testing new versions.
• Software vendors who develop applications for Linux, including Microsoft, often offer their own repositories that contain only in-house products. If common libraries are required as dependencies, they need to be obtainable from another repository registered on the same system. Vendor-owned repositories usually contain the latest versions of the products, but the compatibility of the packages offered with individual distributions and versions can vary.
• Projects or special interest groups within a community often establish and maintain repositories for packages that distribution maintainers have dropped from mainstream feature sets – even though the software in the packages is still used by end users or other products need them as prerequisites.

This architecture, complex at first sight, results in a very satisfying user experience. With just a few commands, you can search for available packages and install or uninstall them. When doing so, the package manager takes into account the dependencies of the desired application and installs them, as well, if necessary, or cancels the installation if you do not agree to install or update one of the required packages. Although the command syntax is not identical for the different package managers, the logic behind it is very similar, which means that you can quickly find your way around the new package landscape when changing the distribution you use.

A similar user experience that also supports scripting of complex installations has been on many a Windows administrator's wish list for years. Over the years, several developer communities have tackled the task of providing a full-fledged package manager for Windows. Two of these projects deserve special mention:

• Chocolatey [1] has a development history going back more than 10 years and has become the de facto standard for command-line-based package management on Windows.
• Microsoft's open source WinGet [2] has an interesting history. Developer Keivan Beigi originally set out to solve both the technical challenges of package management on Windows and to overcome the organizational hurdles in the package review and release process with his AppGet project [3]. In early 2020, Microsoft expressed its intention to acquire the author's business and product, but they decided against it in the same year. Meanwhile, the ideas underlying AppGet formed the basis for WinGet. After a media outcry in the community, Microsoft admitted [4] to having used AppGet's ideas directly.

The Classic Choice: Chocolatey

Chocolatey was developed in 2011 by Rob Reynolds. Today a whole team works on the product. The original idea was to extend the functionality of NuGet (installing and including components in software projects) to entire application packages, thus addressing the needs of end users and system administrators. According to the company's website, the name "Chocolatey" is a culinary analogy to "NuGet" (nougat), a package manager for reusable code. The choco program, which offers all of Chocolatey's functions, is itself delivered as a NuGet package.

Getting started with the Chocolatey Community Edition is simple. You can install the product on all Windows versions from Server 2003 and Windows 7 in 32 and 64 bit, provided .NET Framework 4 is available. The installation website shows some setup instructions and offers a PowerShell one-liner (Listing 1) that downloads and executes a script.

Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))

The install.ps1 script in turn downloads the NuGet package and installs the program components in the designated paths, which, however, end up in %ProgramData% instead of %ProgramFiles%, as intended by Microsoft. The Chocolatey website also provides playbook definitions for organizations already using Ansible, Chef, or Puppet. However, this assumes that you have already set up an internal NuGet repository to which you've uploaded the Chocolatey package.

Once Chocolatey is installed, you have access to the community repository, which contains several thousand packages for various applications. You can search the repository for (and install) a desired package on your system using:

choco search <part of package name>
choco install <package name>

If administrative rights are required, the calling account must have appropriate authorizations, and depending on the configuration, you will need to confirm the user account control (UAC) prompt.

You can upgrade to the latest version available in the repository or remove an application installed by Chocolatey with:

choco upgrade <package name>
choco uninstall <package name>