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.

Running `winget` in Windows Terminal

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>.

Documentation displayed via `winget show`

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.

Installation Notes after an installation

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.

Expected Return Code Response URL displayed

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.

AppsAndFeatures filtered on Microsoft.NET

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.

Running `winget --info` displays system architecture.

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.

Uninstall via Apps & Features

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.

Error on 1.2 when trying to install a portable package

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.


Discussion is closed. Login to edit/delete existing comments.

  • Eugene Astafiev 0

    Congratulations on the release! Can’t wait to try all new features. However, it is interesting to see how this tool will be succeeded with chocolate.

  • ZippyV 0

    Last time I tried WinGet to install Firefox Developer Edition, it installed the English version. There didn’t seem to be a way to choose the language when installing an application. Did I do something wrong?

    • Joshua Huseman 0

      There is an argument for an interactive install which should give you the option, I believe it is the “-i” argument. Otherwise it runs most installers in “quiet” mode which typically accepts all of the defaults.

      • Joshua Huseman 0

        It looks like you can also specify it with the “–override” argument if the Firefox installer has an argument to specify the language without an interactive install.

  • Jon E Gross 0

    There is a typo with the – – I n f o parameter. The double dash has been converted to an emdash.

    • Demitrius NelonMicrosoft employee 0

      Thanks! The editor thinks I want an emdash regardless of what I enter.

  • John King 1

    why you guys not release a reall “.winpkg” file and push it’s support to all windows version (start from win7), for me the installer is about to put program files into a local folder and add shutcut to “desktop/start menu” and with service register + registry + other folder operation (maybe also add banner image when installing) .
    now msix is about container , so it’s simply not fit for every program, and now your winget is eliminating it. and some .exe is completly ignored by your configuration for “install folder / drive”, I hope you guys can realse a fullverion of installer package format and support all of the type (none-container + contained + background servics + child programe)

Feedback usabilla icon