Windows Package Manager 1.3

Demitrius Nelon

Today I get to announce Windows Package Manager 1.3 has been released. The team has been adding several enhancements to manifests to improve your package installation experience. We’ve enabled better package version reporting. A new setting allows verbose logs to be on by default. If you run winget --info the system architecture is now displayed. The progress bar was improved with more fine-grained blocks. And the Windows Package Manager now supports portable applications.

Manifest Improvements

Display Documentation

Some packages include documentation associated with a package version. You will now be able to see the documentation and an associated URL when you run winget show <package>.

Installation Notes

Most command-line packages require a terminal restart for the environment variables to be loaded. Some other packages have nuances related to what a user should understand before running them the first time. Installation notes will be displayed after the package is installed. We’ve also added arguments and settings to manage these notes. The default behavior is to display these notes. You can add “suppressInstallNotes” as a setting to prevent them from being displayed. You can also pass “–display-notes” or “–suppress-notes” to override settings.

Expected Return Code Response URL

Most .exe-based installers can provide custom responses for various failure scenarios. We’ve added an enhancement to provide not only a standard error message, but now a URL can also be included. We’re hoping this will help with troubleshooting why something didn’t go quite right. Manifest authors can add a “ReturnResponseURL” to the array of “InstallerReturnCode” values.

Note: The following example shows an error that was intentionally forced to occur.

New Settings

The Windows Package Manager settings file is opened with your default JSON editor when you run winget settings. If you happen to have Visual Studio Code installed and configured, you also get the benefit of the JSON schema for tooltips and code completion. If you don’t, you can run winget install vscode.

Installation Notes

The Windows Package Manager was designed to behave in a predictable manner by default and give users the ability to customize those behaviors. The “suppressInstallNotes” setting was added for users who prefer not to see install notes included in manifests.

Verbose Logs

If you add “–verbose-logs” to any command, the Windows Package Manager adds additional information to the logs. This is often helpful for troubleshooting or digging deeper into exactly what the Windows Package Manager is doing. Users can now specify what level of logging they want. The “Logging” levels available are “verbose”, “info”, “warning”, “error”, and “critical”.

New Version Reporting

Some packages like the Microsoft .NET SDK display versions to users that are slightly different from their build numbers. Unfortunately, this caused confusion during the upgrade process, and it caused frustration for manifest authors. The Windows Package Manager will now honor the preferred version publishers would like to display, and the tooling will still be able to make the correct comparisons when determining if a newer version is available.

In the example below from Windows Apps & Features, you can see the Microsoft .NET Runtime packages and the Microsoft .NET SDK package versions displayed start with “6.0”. The but the Microsoft .NET SDK version below the display name starts with “6.3”. Manifests can now use the display version (“packageVersion” in the manifest) to show users what version is installed or which upgrade is available, but it can still use the build version (“displayVersion” manifest key from the registry and “AppsAndFeatures” from the manifest) for comparison.

Display System Architecture

Not all packages run natively on every architecture. Sometimes packages are run under emulation. We’ve updated winget --info so it now displays the system architecture so you can quickly see what architecture your hardware has. This might help with troubleshooting why a particular package doesn’t have a matching installer, or why it might not behave exactly as you expect.

An Even Better Progress Bar

One of our most popular features is the customizable progress bar. Thanks to a community contribution, it just got better. Additional fine-grained blocks make that progress bar buttery smooth. If you didn’t know, you can customize your progress bar in settings. I use:

“visual”: {“progressBar”: “rainbow”}

Don’t worry, all the styles get the improved progress bar.

Support for Portable Packages

Is there a portable package you wish you could manage with the Windows Package Manager? These are essentially just executable programs that don’t have an installer. Maybe you would like to winget install Microsoft.NuGet or winget upgrade Microsoft.NuGet. We wanted to make sure you could manage these portable packages, so we add the appropriate entries in Windows Apps & Features when you install them. That allows you to see them as installed applications. You can even uninstall them from there if you don’t want to type winget uninstall Microsoft.NuGet.

Note: We’ve added Microsoft.NuGet to the repository so you can test this out. It will fail on Windows Package Manager versions lower than 1.3 as shown in the image below.

Submitting Manifests for Portable Packages

The Windows Package Manager Community Repository will begin accepting submissions for other portable packages after the upgrade has rolled out to a majority of the user base. This should take about one week. If you want to submit a pull request, go ahead. We’ll mark it as blocked for now, and as soon as we begin to accept portable packages, we will run them all through validation.

Demitrius Nelon Senior Product Manager, Engineered 4 Developers (E4D)

Follow