Windows Package Manager 1.2

[Guest 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 you may already have it.

 

 

[HEADING=1]ARM64 Support[/HEADING]

 

We’ve been working to improve the experience for users on ARM64 devices like the Surface Pro X. 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 [iCODE]winget show[/iCODE] 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 [iCODE]winget import packages.json[/iCODE] and go grab a cup of coffee.

 

[HEADING=1]Error Handling[/HEADING]

 

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.

 

[HEADING=1]New settings for local manifests[/HEADING]

 

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: [iCODE]winget settings --enable LocalManifestFiles[/iCODE]. To disable local manifests run the following command: [iCODE]winget settings --disable LocalManifestFiles[/iCODE].

 

 

[HEADING=1]Learn more about the Windows Package Manager[/HEADING]

 

If you are not familiar with the Windows Package Manager, I would suggest taking a look at the Windows Wednesday episode titled “

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

 

[HEADING=1]Packages[/HEADING]

 

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.

 

[HEADING=1]Behind the Scenes[/HEADING]

 

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.

 

[HEADING=1]Open Source[/HEADING]

 

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.

 

[HEADING=2]References[/HEADING]

• GitHub - microsoft/winget-cli: Windows Package Manager CLI (aka winget)
  
• GitHub - microsoft/winget-pkgs: The Microsoft community Windows Package Manager manifest repository
  
• GitHub - microsoft/winget-create: The Windows Package Manager Manifest Creator command-line tool (aka wingetcreate)
  
• GitHub - microsoft/winget-cli-restsource: This project aims to provide a reference implementation for creating a REST based package source for the winget client.
  
• Windows Package Manager
  

 

The post Windows Package Manager 1.2 appeared first on Windows Command Line.

 

Continue reading...