winget-cli: Unable to disambiguate package Microsoft.VC++2013Redist-x64
Brief description of your issue
I’m trying to update package Microsoft.VC++2013Redist-x64 because it cannot disambiguate between the package and a weird package with a guid
Steps to reproduce
Install an old version Microsoft.VC++2013Redist-x64 I’m not aware of the exact sequence of package to install.
Expected behavior
I want to be able to choose the exact package with the --id or --exact.
Actual behavior
I’m not able to update package Microsoft.VC++2013Redist-x64 because it continues to tells me that it is ambiguous with another package identified by a weird guid, as for the previous image.
Environment
Windows Package Manager v0.4.11391 Preview
Copyright (c) Microsoft Corporation. All rights reserved.
Windows: Windows.Desktop v10.0.19043.1165
Package: Microsoft.DesktopAppInstaller v1.11.11391.0
Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
Links
--------------------------------------------------------
Privacy Statement https://aka.ms/winget-privacy
License Agreement https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage https://aka.ms/winget
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 43
- Comments: 23 (5 by maintainers)
We met with the VC++ redistributable team. We’re working together to help alleviate the confusion here. There are a few scenarios we need to consider.
Between 2005 and 2013 Visual Studio editions, a different version is installed “side by side”. Starting with the 2015 editions, the version is truly upgraded.
One of the things we need to do is check to see if a “newer” version is installed when multiple installed versions are present, so we don’t try to perform an upgrade on the “older” version (when it is a “side by side” install).
Another area we’re looking at is the product code for the installers that is currently the same across architectures.
I don’t see why @denelon has marked this as
featureand not as abug. The option--idis broken, if you ask me.When I enter
--idwith an exact id, the upgrade should know what package to upgrade. It should just do a (non case senstive) string compare and no “intelligent” things. I enter--idfor a reason!And note that the package with the GUID isn’t even mentioned in
winget upgrade, so apparently it is not upgradable. Why is it even considered for upgrading?This problem has existed for months without any suggestion of workaround or fix. How can a tool simultaneously accurately identify an upgrade version and then fail to upgrade with that exact same id. Unless you do a
winget upgrade --alland then it works just fine.I misunderstood the original report. This is probably a duplicate of another Issue, but I will keep this open for now until we have a chance to triage all open bugs again to confirm. We already have support in the 1.1 schema for this scenario, but the client side implementation is still in progress.
This is more than a feature request. I’m having the same issue with multiple packages. Here’s one example.
I’m on Windows 11 build 22000
I also have this issue with the c++ 2015-2019 Redistributable (x64). I have tried --name, -e --name, --id, and -e --id but always get the multiple installed packages message with one being x64 and the other x86. I find no ability to refine further.
Attempt upgrade --name example:
The initial upgrades found window:
Here another example why I think there is definitely something wrong with
--idand/or--exact.Note that PowerToys is detected as an upgrade but none of the 5(!)
winget upgradecommands I tried were able to find the package.@denelon Could you consider changing the title of this issue and make it more general? It is not just for VC++ runtime libraries.
@rcdailey the VC++ issue was the first report for the problem(s). We’re looking for a solution to the class of problems pointed out here. This seems to happen when the Windows Package Manager is unable to disambiguate more than one entry in Apps & Features as they correlate to different architectures (and possibly other properties). There are some other scenarios that manifest the same way in terms of ambiguity. Since this was the first report, we’re trying to capture the impact by marking others as a duplicate of this one to increase the 👍 count to help prioritize.
I was able to update by running, for example,
winget upgrade --name "Microsoft Visual C++ 2013 Redistributable (x64)", but all it did was install the new version (12.0.40664) without uninstalling the previous one (12.0.30501), which I then had to manually uninstall viaSettings > Apps & features > Uninstall.To solve the problem, you can use an install on behalf of the upgrade, thus solving your problem Use command
winget install --id Microsoft.VC++2013Redist-x64instead of it
winget upgrade --id Microsoft.VC++2013Redist-x64Indeed, the mess can be impressive:
I’ve cleaned that up on all my PCs, now will monitor if further upgrades will work as expected.
I have the same issue with R. Is there any workaround?
This is still happening as of 2024
I presume this belongs here too?
For me the resolution was to go into Control & Panel -> Programs and uninstall every version of problematic ‘Microsoft Visual C++ YYYY Redistributable’ package … I had 4 versions and 3 seemed like broken references to non-existing installations. After cleaning that mess, upgrade works.
I am having the same issue,
When I run the following command
winget upgradeI see the followingAfter that when I try to run
winget upgrade --id Microsoft.VC++2008Redist-x64I can see the followingThis doesn’t make any sense right? It (
winget) should have chosen the first one, isn’t it? Since theIdis different for all the packages! Moreover the string-based alphanumericId(Microsoft.VC++2008Redist-x64) is what gave the issue in the first place how come it is still the part of the output? The other twoIdwhich are GUIDs may make sense as the output! Which brings me to my next question can’t we pass GUID as input towinget upgrade --id? Something likewinget upgrade --id 5FCE6D76-F5DC-37AB-B2B8-22AB8CEDB1D4. Didn’t work for me I gotNo installed package found matching input criteria.. Isn’t me specifing a GUID “refine the input”?Anyone any insights?
I did a comment on winget-pkgs/issues/27935