The Windows Package Manager team has been busy working on WinGet 1.4. This release introduces support for .zip-based packages. WinGet can now extract and run an installer inside of a .zip archive or install one or more portable packages from an archive. The WinGet open-source community has also been busy adding new features like command aliases to help with muscle memory if you use more than one package manager, and a wait argument to keep winget.exe open long enough to see what’s happening if it’s called from other applications.
WinGet Show Improvements
A few more manifest values like tags and purchase URL were added to the output (if they are present) of winget show <package>
. Below I have an example running winget show oh-my-posh -s winget
. Since Oh My Posh is available both in the Microsoft Store and the Windows Package Manager community repository, I narrowed the results down to the “winget” source. If you like the colorful display in my prompt, that’s the prompt theme engine I’m using.
Command Aliases
Muscle memory can be hard to overcome. If you’ve ever tried to type “dir” on a Linux system or “ls” on Windows, you know what I mean. Several new command aliases have been added to WinGet that might help a little. When you run winget
with no arguments, the default help displays the available commands. If you drill in a bit running winget <command> --help
you will see if any aliases are available. Below, you can see “find” is an alias for “search”. Other command aliases include add
for install, update
for upgrade, remove
and rm
for uninstall, ls
for list, and config
for settings.
As you might expect, you can now run winget find vscode
and the same output is displayed as if you had run winget search vscode
.
Note: The results displayed when searching the Windows Package Manager Community repository are ordered by a “best match” heuristic. WinGet evaluates the name, identifier, moniker, and tags. They are also more inclusive than “show” where WinGet is trying to find a single best match to use for install.
Install / Upgrade Flow Enhancements
Some packages require an explicit argument to be passed in order to perform an upgrade. This was causing winget to fail if a user ran winget install <package>
and the package was already installed on the machine. We made some additional enhancements to detect that the package was already installed and switch to the upgrade flow. If you don’t want the upgrade, you can pass --no-upgrade
. This is most commonly encountered in scritped scenarios. We’ve also noticed several packages can upgrade themselves, so our default behavior is to allow them to do so. If you run winget upgrade --all
and one or more of these packages are encountered, they will be skipped. If you want to include them, just add --include-explicit
.
.zip Archive
WinGet now supports installing packages contained within a .zip archive. This feature builds on the existing support for portable packages, and existing installer support for MSIX, MSI, and EXE-based installers. Our initial support includes either a single installer, or (one or more) portable package(s). We’ve kept the Issues and PRs (Pull Requests) open at GitHub and added the “.zip” label to them. Once this release rolls out to the majority of supported Windows systems, we will begin validating the existing PRs and accepting new ones.
Wait
Wait, there’s more. (I couldn’t help myself) Sometimes when you’re scripting things, or debugging, you want a prompt. It can be quite frustrating to see a terminal window display some text and then disappear before you can read everything. Just add --wait
.
I have a situation where a package distributed through Microsoft Store cannot be updated with winget. The package in question is "Web Media Extensions" (microsoft.webmediaextensions). What I am trying to do is find a way to update this package using PowerShell or some method that can be performed silently and without interrupting employees' work. Some clients, for reasons unknown at this time, are not updating automatically; Microsoft Store is set to automatically update but it's...
WinGet is not receiving the version information for UWP packages via the “msstore” REST source (long lead time work in progress). If you run the upgrade command with “–force” appended at the end it should force the upgrade. The “No applicable upgrade found.” message is due to the version being “Unknown”.
So I tried this with the "VP9 Video Extensions". The latest version listed on Microsoft Store is 1.0.52781.0. I confirmed that a client had an older version. I found I could do nothing with winget until I used Add-AppxPackage to add the app to my profile (i.e., "VP9 Video Extensions"). Once I did that, I confirmed that the app was listed in msstore and that winget was able to locate it. I used: winget search...
Thank you. I will give this a go and report back.
Winget is great, but has some limitations that make it quite difficult to use in an enterprise environment, specifically with MEMCM. I'd like to use it in a SCCM application, or perhaps a package/program, or even just run it from a task sequence using a run powershell step. The trouble is, I get inconsistent results, I think due to the fact that CM is running as system, and winget requires a user with admin rights....
Great stuff that it’s moving forward, but when I’m trying to search explicitly on the msstore, I get this: