Windows Package Manager 1.2

Demitrius Nelon

We’ve been busy improving the Windows Package Manager. Today I have the pleasure of announcing the availability of Windows Package Manager 1.2. It has been released to the Microsoft Store as an automatic update to the “App Installer” this morning if you’re running Windows 10 (1809+) or Windows 11.

Image Windows Package Manager 1 2

ARM64 Support

We’ve been working to improve the experience for users on ARM64 devices like the Surface Pro X, the Lenovo X13s, or the Samsung Galaxy Book Go. The Windows Package Manager chooses the best available package based on your hardware architecture. If a native option is not available, the next best option will automatically be selected. You can see the same familiar experience in a silent video. In the first minute, it shows a couple of basic commands, but the key thing to note is the installer URLs exposing the architecture coming from the winget show command. Most of the video is just scrollbars after that while packages download, install, and upgrade seamlessly. It may not be exciting to you, but I love being able to run winget import packages.json and go grab a cup of coffee.

Error Handling

It’s now possible to map cryptic error messages into something easier to understand. If you are like me, you struggled to understand the 10-digit error code returned by an installer. You probably wouldn’t want to hunt down exactly what that error code was indicating either. Those 10-digit error codes are often specific to just a single package. They may represent common types of errors like not enough storage or memory. The manifests can now create a link between the custom error code from the installer and a set of generic ones the Windows Package Manager understands. If this happens to you, feel free to create an issue at GitHub and one of our amazing community members might be able to help and create the link. If you’ve figured it out, you can even submit a pull request yourself to help anyone else who gets the same error.

New settings for local manifests

We have also added a new setting for the security conscious related to testing or installing from a local manifest file. This is something we ask users to do before submitting a package to the Windows Package Manager Community App Repository. I suggest performing this in a Windows Sandbox rather than taking a potential risk on your primary desktop. To enable testing with local files, run the following command in an elevated (Run as administrator) prompt: winget settings --enable LocalManifestFiles. To disable local manifests run the following command: winget settings --disable LocalManifestFiles.

Image LocalManifestFiles

Learn more about the Windows Package Manager

If you are not familiar with the Windows Package Manager, I would suggest taking a look at the Windows Wednesday episode titled “Let’s talk Windows Package Manager“. For something a bit more interactive, try the “Explore the Windows Package Manager” module on Microsoft Learn. You can also learn more about the basic commands in the blog posts for Windows Package Manager 1.0 and Windows Package Manager 1.1.


Thousands of packages are available from the Windows Package Manager Community App Repository and the Microsoft Store. You can even host your own private source on Microsoft Azure. If you are interested in submitting a package, the Microsoft Store now supports traditional desktop apps. If something is missing from the Windows Package Manager Community App Repository, you can submit a request to have it added, or you can use the Windows Package Manager Manifest Creator to submit it yourself. We’ve even packaged it to simplify Continuous Integration/Continuous Delivery (CI/CD) scenarios so you can automatically submit new versions with your automated release pipeline.

Behind the Scenes

The Windows Package Manager is much more than just the client. We’ve been busy behind the scenes improving the experience for authors publishing manifests. We share the results from failed validation attempts to help publishers submit their packages at GitHub. There is also a COM API and a sample project demonstrates how you can integrate with it. The Windows Package Manager Manifest Creator also comes in several flavors depending on your needs for CI/CD.

Open Source

We’ve been developing the Windows Package Manager, the Windows Package Manager Community App Repository, the Windows Package Manager Manifest Creator, and the reference implementation for private repositories at GitHub. Feel free to submit feature requests and bugs via GitHub Issues. If you have questions, feel free to start a GitHub Discussion. We look forward to your feedback.



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

  • Olav Rønnestad Birkeland 0

    Would be great with a heads up about breaking changes, like renaming AppInstallerCLI.exe to winget.exe. But other than that, great progress. 🙂

  • Robert Rodriguez 0

    I’ve been a big fan of winget since it was released. Any possibility of having a way to hide or exclude packages from
    upgrading until a new release is out? There are a few like Winamp, diskgenius, trillian that always show up as needing updates. Another one, Spotify always fails since it only runs in a non-administrator ID.

  • Paulo Pinto 0

    As usual no .NET love from Windows teams, we keep being forced to deal with COM API and C++, just like .NET had never happened.

    Maybe it is about time Windows teams experience a bit how productive tooling we have on Android, macOS and ChromeOS with managed languages.

    • Sunil Joshi 0

      COM is accessible from native and managed code – a pure .NET solution would require people to use Managed Code. You can easily consume COM APIs in .NET using CSWin32 or CSWinRT as required. Eventually, I’m sure a managed wrapper for these APIs will be published.

Feedback usabilla icon