In my September 16 post, “WinGet Mistakenly Reports Discord as Pinned,” I covered a quirk in how winget labels certain packages. I was reminded of same, as I observed that UniGetUI hanldes Discord updates easily and directly. If winget marks Discord as pinned and skips it, how can UniGetUI update it anyway? Let me ‘splain it to you.
How UniGetUI Handles Discord Update, While WinGet Fails
It is a handling difference that distinguishes the two package managers. Actually, WinGet itself stumbles only when using update --all. WinGet actually CAN handle a Discord update but it has to be commanded correctly and directly. UniGetUI uses WinGet to get (at least some of) its work done (also works with Chocolatey, Scoop, etc.). The trick turns out to hinge on how WinGet is told to upgrade Discord. The blanket approach just described fails because of a manifest flag (see 9/16 post for deets). Winget simply skips over that upgrade.
UniGetUI does things differently. Under the hood, it calls winget using an explicit package ID for each app that needs an update. For Discord it works just as if it had entered
winget upgrade --id Discord.Discord --include-pinned
at a command line (cmd.exe or PowerShell). In fact, WinGet will update Discord if you use similar syntax, to wit:
winget upgrade --id Discord.Discord --force
Manual Override Is a One-Off Avventura
Please note: the preceding command string is a one-time override. The RequireExplicitUpgrade: true flag that causes WinGet to skip over Discord for WinGet upgrade --all stays in place. Future winget upgrade –all runs will still skip Discord, so you would need to repeat the command each time you wanted to force that update manually.
UniGetUI’s approach turns this winget blind spot into a non-issue for anyone who prefers a GUI workflow. I’m actually coming to like this program more and more because of its consistent, user-friendly package handling. But WinGet remains number one in my heart because it’s command-line native, and readily susceptible to scripting and automation.
