I’ve been researching an upcoming ComputerWorld story about the terrific and powerful PowerShell based Windows packager: Winget. It’s a peach! I mostly use it for keeping applications and supporting elements current. Lately, I’m using Winget for 4 ways to update my apps. Let me explain…
How-to: Using Winget for 4 Ways to Update
Way 1: Check Pending /Available Upgrades
By itself, the command winget upgrade simply shows what’s ready to upgrade. It doesn’t actually do any upgrades. Thus, it offers a quick easy way to see what upgrades are available. That’s why it appears as the lead-in graphic for this story.
Ways 2 & 3: Perform Blanket Upgrades
In fact, two different command strings provide varying degrees of upgrade capability
- winget upgrade –all
- winget upgrade –all –include-unknown
By default winget only upgrades to a new version when it recognizes the current version. Then, if the current installed version is lower-numbered than the pending one, the upgrade goes ahead. Some-times, for whatever reason, winget can’t find the current running version into. In such cases, the upgrade –all variant skips them. Thankfully, adding –include-unknown to the string tells winget to upgrade those anyway. Consequently, I use that more inclusive variant because there’s less follow-up needed.
To illustrate, the next screencap shows winget upgrade –all –include-unknown output on the PC that produced the lead-in snap. Notice please: 5 items found, 5 items upgraded. Good-oh!
The –all –include-unknown variant of winget upgrade covers the most possibilities. On this PC, all 5 candidates upgrade.
[Click image for full-sized view.]
Way 4: Targeted Winget Upgrades
Examined closely, both preceding screencaps shows an ID column. Indeed, that information provides a “package name” for its associated application. Thus, you can always upgrade a single package at time using this syntax:
winget upgrade <package-name>
For example, names shown in the screencaps include Mozilla.Firefox, TeamViewer.Teamviewer, AntibodySoftware.Wiztree, Google.Chrome and Microsoft.WindowsSDK. That follows a mostly predictable structure: builder-name.package-name. For speed, I like to use it when winget presents only a single option, or when a winget blanket command fails. I’m learning that happens sometimes, for various odd reasons.
There are many ways to work with winget I haven’t yet mentioned. These could appear in future posts here. Certainly, they’ll definitely be covered in my upcoming ComputerWorld piece. Right now, that’s scheduled to appear online before month’s end. Hopefully, you’ll get a chance to catch that during the busy holiday season.
