Windows Package Manager 1.4
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.
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,
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
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, 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
Great stuff that it’s moving forward, but when I’m trying to search explicitly on the msstore, I get this:
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. What appears to be happening is, when I run from a task sequence, powershell cannot find winget, because there is no app alias for winget in the System users appdata folder, and even if I hard code the path to the winget.exe in the PS script, it cannot find it. When I run the same script from my admin account, it works fine. Do you have any suggestions for deploying store apps with winget using MEMCM?
Are these limitations below going to be addressed in future versions?
Lack of device context (device-based) install options to help device management tools such as SCCM. This is how Microsoft Store for Business (MSfB) works.
Lack of options to override UAC prompts during uninstall.
Lack of options to manage local Admin permissions during uninstall of the applications using the WinGet Tool.
Lack of device-based licensing option is not available.
Lack of Offline install options are not available with the Windows Package Manager service and the WinGet tool.
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 just not happening consistently.
I can find the package with: winget search –name “Web Media Extensions”. The source is listed as msstore.
When I execute “winget upgrade –name “Web Media Extensions” –accept-source-agreements –accept-package-agreements”, the output is “Failed when searching source: winget An unexpected error occurred while executing the command: 0x8a15000f : Data required by the source is missing”. When I execute “winget upgrade –name “Web Media Extensions” –source msstore –accept-source-agreements –accept-package-agreements”, the output is “No applicable upgrade found”. However, I know for sure there is an update because it is listed in a CVE.
I’ve tried to force a source reset and then updating the source. I found several posts about a problem with the winget upgrade process dating back to November; my understanding is those issues have been resolved.
At this point, I have been reduced to emailing end users with instructions on how to update manually with the Microsoft Store app. However, this is not a viable option in the long term for a number of reasons which I won’t get into. There must be a way to update this component through scripting. I was hoping winget would do the trick but it is simply not working. What am I missing?
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”.
Thank you. I will give this a go and report back.
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 “VP9 Video Extensions”. The output was:
Name Id Version Source
VP9 Video Extensions 9N4D0MSMP0PT Unknown msstore
So I can see where the version is showing up as “Unknown”. Then I used: winget upgrade “VP9 Video Extensions” –silent –accept-source-agreements –accept-package-agreements –source msstore –force. The output was: No applicable upgrade found.
However, there is an upgrade available. It seems that the –force parameter is not working as expected.