WinGet keeps reinstalling same updates that were marked as successful #2313
Comments
ghost
added
the
|
denelon
added
Issue-Bug
|
I am also seeing where winget says I have updates but it's definitely already installed them. If I run Here is my list of apps that report upgrades but are already installed:
|
|
|
Thank you @Trenly for that detailed info!!! Looks like Windows PC Health Check was only installed using
|
|
The list doesn't mean that HealthCheck came from the "winget" source, it just means we were able to match the installed package against one that is available in the source. |
|
I'm also seeing this issue with several packages. One solution that I have thought of is for there to be an option to hide packages from winget. i.e. if there is a package that I don't want winget to manage and I will manage manually, add it to some exclusion list. |
|
Apart from allowing to set an exclusion list, could detect such cases (or at least the package installation failures) and suggest to the user how to add to the exclusion list. |
|
This is getting super frustrating. Winget keeps saying there are upgrades even after everything has been upgraded.
|
|
Notice also that this seems to be happening predominantly with Microsoft packages:
After upgrade:
|
|
This issue is primarily caused by packages with versions that install "side-by-side". As we iterate over the list, we look for upgrades. If you have version 1 installed and run upgrade, version 2 gets "added". Then when we iterate over again, we see version 1 and it needs an upgrade even though version 2 is installed. We're working on a fix to detect if the latest version of a package is already installed to reduce the friction here. |
|
We've improved the logic in WinGet 1.4. I know there are still issues with matching for some packages like Teams and VC Redists. @birbilis are you still seeing the same packages failing, or have some of them improved? |
denelon
added
the
Needs-Author-Feedback
|
The following packages will reinstall even though previously marked as successful: In IrfanView's case it's a 32 bit version installed but during the attempt to update a 64 bit installer is ran. |
|
Also for "unknown" packages:
|
|
How is Zotero being displayed in Windows Apps & Features? WinGet is looking at the registry key and seeing version "6.0.8" based on the output above. It's possible the installer isn't updating the registry key during the upgrade process. |
btw, does WinGet itself autoupdate? I see I have 1.4.10173 on that same Win10pro laptop, but not sure if it updated with OS or when I run it last time or something. Tried "winget upgrade winget" with no luck (can't find package). How can one try to get the latest winget (applicable to the current OS/CPU at least) before they do the other upgrades? |
microsoft-github-policy-service
bot
added
Needs-Attention
|
This one forces one to respond to confirmation prompt and then shows the VS installer's progress pane: |
|
WinGet does not autoupdate, but the Microsoft Store will autoupdate the App Installer (containing WinGet). |
|
This one shows a UAC prompt at some point (should I be running winget from elevated command prompt instead?) |
|
This one seems to progress with failure immediately before the user does something on the dialog it shows (even though I used "-h" option for upgrade). I guess if one presses Remove they'll lose the s/w and will need to install it by hand since as the screenshot shows winget continues in the mean time with other packages |
It displays as 6.0.18. Same for Control Panel\Programs\Programs and Features.
Yes that seems plausible. I haven't rebooted the computer. I'll try that ...
See #3130 |
|
I'm encountering this as well with these applications:
I don't know of any fix and it's polluting my weekly EDIT: For now, I've pinned the packages using #476. This should prevent it from useless reinstalling every time I try to update everything. |
|
I'm experiencing the same issue with Android Studio:
Here are the logs: |
|
I'm having the repeat-install problem with DotNet 7. Over the past week or so, winget has re-installed it every time I have run |
|
I have a list of 20 packages that never get removed from the list even though they were upgraded. Since I've seen this issue for a year and a half, I just ignore the offenders and install by hand the packages that play nice. |
|
Any solution for this yet? |
|
We've released better support for packages that install "side-by-side" in WinGet 1.8. Is this still happening? |
denelon
added
Needs-Author-Feedback
|
Hi Demetrius,
Good question. I can't guarantee that it's fixed but I haven't seen it
happen recently.
Thanks for checking.
Cheers,
Jeff
…On Mon, Jul 8, 2024 at 8:13 PM Demitrius Nelon ***@***.***> wrote:
We've released better support for packages that install "side-by-side" in
WinGet 1.8. Is this still happening?
—
Reply to this email directly, view it on GitHub
<#2313 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AXHCUD5EGNWEE762VTRSEPLZLM2LNAVCNFSM523X6HMKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMRRGU4TMNZRGE3A>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
microsoft-github-policy-service
bot
added
the
No-Recent-Activity
|
Well, that's odd. I replied on the 19th of July 2024. Oh well. I will trust that the problem is fixed as I have not seen it reoccur since the update to Winget 1.8. |
microsoft-github-policy-service
bot
removed
the
No-Recent-Activity
tried on that same machine earlier today (without the -h option) and it did install 40 packages ok, apart from a strange glitch message at the end that's strange: the uninformative glitch I refer to is: There's a small chance it's related to "Dev Home" (Preview) and to the fact that once it popped up (after WinGet updated it), I selected from its UI to bring some extensions which it seems to bring via the Microsoft Store. It had brought (pending at that moment) the GitHub extension for Dev Home. ...But not sure since when I run the command again (and when I run it again now) I mainly notice a message "46 package(s) have version numbers that cannot be determined. Use --include-unknown to see all results.". That message was also showing at the end of the 30 packages successful upgrade. If it had shown just below the initial list of packages with upgrades (before the upgrades loop) it would have been more informative I think since I wouldn't be wondering now if the updates caused the 46 packages with version numbers that cannot be determined or affected that count. Trying --include-unknown shows nothing (so I wonder what that count of 46 means): all the interaction was this: now when I try the command again (for the --include-unknown output see comment earlier on) I get: |
microsoft-github-policy-service
bot
added
Needs-Attention
|
The message about packages with "version numbers that cannot be determined" is based on packages that don't report a version in the Windows Apps & Settings (via registry keys). If you run If you see any with a mapped source (like "winget" or "msstore"), those could be upgrades, but WinGet has no way to determine which version is installed. WinGet would try to install those upgrades if you used |
Brief description of your issue
Seems WinGet keeps on installing (some of) the updates again and again
Steps to reproduce
probably machine-specific, see output
Expected behavior
Shouldn't keep on installing the same succesful installs
Actual behavior
Environment
The text was updated successfully, but these errors were encountered: