There’s always something interesting going on with WinGet, the MS package manager for installing and updating Windows stuff. Yesterday, a database mixup prompts bogus update orders for Visual Studio 2022. Let’s look at what happened, so I can explain the nit-picky little details involved.
But first: there really is no update involved. In fact, the Visual Studio version numbers are identical: 17.14.6, as you can see in the lead-in graphic. Note that the same version number appears in the columns for both “Version” and “Available.”
Fixing Database Mixup Prompts Bogus Update
The devil for these particular details lies in the difference between the two strings. The info from the “Version” column comes from the local copy of the WinGet source. It includes the parenthetical phrase after the version number — “(June 2025).” The “Available” version info does not include that string. Thus, there’s a mismatch, even though they’re the same base version number.
Simply put, because the version numbers don’t match, WinGet blithely assumes they’re different. Technically, they are. But they differ because somebody erred in creating one version string or the other.
Who’s on the Hook for a Fix?
Why Microsoft, of course, because Visual Studio is their product. Thus, they’re responsible for the package data in the WinGet database. As you can see in the following screenshot, in fact, that fix is already in. It depicts this morning’s WinGet show and WinGet list data for Microsoft.VisualStudio.2022.Enterprise. Note that the version number info now agrees completely. Fixed!
The previous discrepancy is gone. [Click image to view full-sized.]
For further proof, I ran WinGet upgrade –all –include-unknown. It shows that CrystalDiskMark and Edge need updates, but Visual Studio no longer appears. The mismatch is corrected, so it’s no longer incorrectly flagged for update.
I’m a huge fan of WinGet, not least because the team at MS that works on its software and data is on top of things. Good stuff!
I’ve seen similar hiccups with package managers before. It’s a good reminder of how even small metadata differences—like a parenthetical date—can lead to unexpected behavior that looks like a legit update.
Interesting how something as small as an extra string like ‘(June 2025)’ can throw off WinGet’s update logic. It really highlights how important consistency in metadata is when tools rely on string comparisons.
Thanks for breaking down this subtle mismatch. It’s a good reminder that even harmless-looking metadata differences can trip up tools like WinGet. Maybe it’s time they added smarter handling to ignore these kinds of trivial string variations.
I ran into this exact issue and thought I was missing a real update. Your breakdown clears it up—shows how even version labeling nuances can impact workflows.
Thanks for clarifying this glitch, Ed. It’s surprising how something as small as a parenthetical date string can cause a false update flag. I wonder if WinGet might eventually add logic to ignore these metadata differences to avoid user confusion?
This kind of issue highlights the importance of string normalization in version checks. I wonder if WinGet could benefit from a stricter comparison protocol to avoid false positives like this in the future.
That’s kind of what I was thinking. Seems like an algorithm that enforces matching for the first, most significant part of the string would do the trick. My old, former employee Dr. Bill Brogden, was especially good at programming such stuff, so I think I have some idea how one might go about it. Good suggestion!
–Ed–