Back on March 6, I posted an item about Windows Application Update Rhythms. This offered a snapshot for a week’s update activities across my various PCs. Since then, of course, the updates have continued as the never-ending Windows Update story carries on. I’ve made some interesting observations since then, too.
The lead-in graphic above shows one such data point. I’ve begun to notice that sometimes Winget will update Chrome, and sometimes it won’t. It seems to be related to whether or not the app is open at the moment (yes if closed; no if open).
Never-ending Windows Update Story Keeps Going…
The same thing appears to be true for PowerShell as well, as you can see in this next screencap. Amusingly, the app itself is PowerShell so indeed it’s obviously running too. But there are ways to force a PS upgrade within the app, so this default behavior can be over-ridden. The second post in this SuperUser thread explains how to do just that. It grabs and uses the PS install MSI from GitHub to make that happen.
Winget updates neither Chrome nor PowerShell here.
What’s Behind the Apparent No-Upgrade Behavior?
In various discussions online as to what’s at work here, I learned (or re-learned) a few things. When installer formats change (MSIX to MSI, MSI to EXE, and so forth) Winget won’t perform the update. Indeed, I’ve seen explicit messages to this effect in Winget output from time to time. This Answers.Microsoft.com thread explains how to grab, then use, the download URL for the Chrome installer to bypass the failed (and silent, error-message-wise) Winget update. Likewise interesting!
The more I work with Winget, the more I learn about its various hiccups and gotchas. But the tool continues to impress because there’s nearly always a clever workaround to get things done. It’s definitely made the various installments of the never-ending Windows Update story around Chez Tittel shorter and more entertaining. What more could a Windows-head like me want?
