winget-cli
winget-cli copied to clipboard
microsoft
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
IF you specify the GUID to upgrade package, the situation become worse, it updates the package and then I have even more conflict
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 via Settings > Apps & features > Uninstall.
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:
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 don't see why @denelon has marked this as feature and not as a bug. The option --id is broken, if you ask me.
C:\Windows\system32>winget upgrade
Naam Id Versie Beschikbaar Bron
-------------------------------------------------------------------------------------------------------------------------
Microsoft Visual C++ 2015-2019 Redistributable (x64) Microsoft.VC++2015-2019Redist-x64 14.29.30133.0 14.29.30135.0 winget
Microsoft Visual C++ 2015-2019 Redistributable (x86) Microsoft.VC++2015-2019Redist-x86 14.29.30133.0 14.29.30135.0 winget
Microsoft Teams Microsoft.Teams 1.4.0.7174 1.4.00.26376 winget
3 beschikbare upgrades.
C:\Windows\system32>winget upgrade --id Microsoft.VC++2015-2019Redist-x86
Er zijn meerdere geïnstalleerde pakketten gevonden die overeenkomen met de invoer criteria. Verfijn de invoer.
Naam Id
---------------------------------------------------------------------------------------------------------
Microsoft Visual C++ 2015-2019 Redistributable (x86) Microsoft.VC++2015-2019Redist-x86
Microsoft Visual C++ 2015-2019 Redistributable (x64) - 14.29.30133 {295d1583-fdb9-414b-a4c8-da539362a26b}
When I enter --id with 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 --id for 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?
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.
Here another example why I think there is definitely something wrong with --id and/or --exact.
Note that PowerToys is detected as an upgrade but none of the 5(!) winget upgrade commands 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.
C:\Windows\system32>winget upgrade
Naam Id Versie Beschikbaar Bron
-----------------------------------------------------------------------------------------------------------------------
PDF-XChange Editor TrackerSoftware.PDF-XChangeEditor 9.2.357.0 9.2.358.0 winget
Microsoft Visual C++ 2015-2019 Redistributable (x… Microsoft.VC++2015-2019Redist-x64 14.29.30133.0 14.29.30135.0 winget
Microsoft Visual C++ 2015-2019 Redistributable (x… Microsoft.VC++2015-2019Redist-x86 14.29.30133.0 14.29.30135.0 winget
Microsoft Teams Microsoft.Teams 1.4.0.7174 1.4.00.26376 winget
PowerToys (Preview) Microsoft.PowerToys 0.47.1 0.49.0 winget
5 beschikbare upgrades.
C:\Windows\system32>winget upgrade powertoys
Er is geen toepasselijke update gevonden.
C:\Windows\system32>winget upgrade microsoft.powertoys
Er is geen toepasselijke update gevonden.
C:\Windows\system32>winget upgrade --id microsoft.powertoys
Er is geen toepasselijke update gevonden.
C:\Windows\system32>winget upgrade --id Microsoft.PowerToys
Er is geen toepasselijke update gevonden.
C:\Windows\system32>winget upgrade --exact Microsoft.PowerToys
Er is geen toepasselijke update gevonden.
C:\Windows\system32>winget --version
v1.1.12653
@ffes PowerToys is a known issue. The installer is an MSI inside of an EXE. When we see the manifest telling us the installer is EXE, we stop trying to upgrade an MSI. We've already made changes to the schema to support this specific kind of a scenario, it's just a matter of finishing the work on the client and validating before we get that feature out in a preview build.
For some context, "--exact" is looking for a case sensitive match where the other default behaviors are looking for a case insensitive substring match.
I have the same issue with R. Is there any workaround?
>winget upgrade --exact --id RProject.R
Multiple installed packages found matching input criteria. Please refine the input.
Name Id
-------------------------------------------
R for Windows RProject.R
R for Windows 4.1.2 R for Windows 4.1.2_is1
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.
Worth pointing out this happens with Microsoft.dotnet as well; #1829 was marked as a duplicate of this issue but I see no mention of this specific package here. Instead I see specific issues with vcredist that I am not sure relates to this package.
When I do a package list:
PS C:\Windows\System32> winget list | findstr -i dotnet
Microsoft .NET SDK Microsoft.dotnet 5.2.921.52710 winget
Microsoft Windows Desktop Runtime - 3 (x64) Microsoft.dotnetRuntime.3-x64 3.1.22.30721 winget
Microsoft .NET SDK Microsoft.dotnet 6.1.121.56904 winget
There are two versions of dotnet here, I'm not sure why. The only one I want is v6. OR, if both should be present, it shouldn't appear when I do winget upgrade as it does now:
PS C:\Windows\System32> winget upgrade
Name Id Version Available Source
-------------------------------------------------------------------------
Microsoft .NET SDK Microsoft.dotnet 5.2.921.52710 6.1.121.56904 winget
Oracle VM VirtualBox Oracle.VirtualBox 6.1.26 6.1.30 winget
2 upgrades available.
And when doing winget upgrade --all, stuff happens and then this list stays the same. I'm running Winget version v1.2.3411-preview.
@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 am having the same issue,
When I run the following command winget upgrade I see the following
Name Id Version Available Source
---------------------------------------------------------------------------------------------------------------------
Microsoft Visual C++ 2008 Redistributable - x64 Microsoft.VC++2008Redist-x64 9.0.30729.4148 9.0.30729.6161 winget
After that when I try to run winget upgrade --id Microsoft.VC++2008Redist-x64 I can see the following
Multiple installed packages found matching input criteria. Please refine the input.
Name Id
-----------------------------------------------------------------------------------------------------
Microsoft Visual C++ 2008 Redistributable - x64 Microsoft.VC++2008Redist-x64
Microsoft Visual C++ 2008 Redistributable - x64 9.0.30729.6161 {5FCE6D76-F5DC-37AB-B2B8-22AB8CEDB1D4}
Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.6161 {9BE518E6-ECC6-35A9-88E4-87755C07200F}
This doesn't make any sense right? It (winget) should have chosen the first one, isn't it? Since the Id is different for all the packages! Moreover the string-based alphanumeric Id (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 two Id which are GUIDs may make sense as the output! Which brings me to my next question can't we pass GUID as input to winget upgrade --id ? Something like winget upgrade --id 5FCE6D76-F5DC-37AB-B2B8-22AB8CEDB1D4. Didn't work for me I got No 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
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 --all and then it works just fine.
I presume this belongs here too?
PS❯ winget upgrade | ConvertFrom-WingetStdout.ps1 | ? { $_.id -in @('Microsoft.VC++2008Redist-x86','Python.Python.2','Microsoft.dotnet') } | % { ("`n`n`nUpgrading '{0}' (id='{1}') using 'winget upgrade --id {1} --exact'" -f $_.Name, $_.Id); winget upgrade --id $_.Id --exact }
Upgrading 'Microsoft Visual C++ 2008 Redistributable - x86' (id='Microsoft.VC++2008Redist-x86') using 'winget upgrade --id Microsoft.VC++2008Redist-x86 --exact'
Multiple installed packages found matching input criteria. Please refine the input.
Name Id
-----------------------------------------------------------------------------------------------------
Microsoft Visual C++ 2008 Redistributable - x86 Microsoft.VC++2008Redist-x86
Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.6161 {9BE518E6-ECC6-35A9-88E4-87755C07200F}
Microsoft Visual C++ 2008 Redistributable - x64 9.0.21022 {350AA351-21FA-3270-8B7A-835434E766AD}
Microsoft Visual C++ 2008 Redistributable - x64 9.0.30729.6161 {5FCE6D76-F5DC-37AB-B2B8-22AB8CEDB1D4}
Microsoft Visual C++ 2008 Redistributable - x64 9.0.30729.17 {8220EEFE-38CD-377E-8595-13398D740ACE}
Microsoft Visual C++ 2008 Redistributable - x86 9.0.30729.17 {9A25302D-30C0-39D9-BD6F-21E6EC160475}
Microsoft Visual C++ 2008 Redistributable - x86 9.0.21022 {FF66E9F6-83E7-3A3E-AF14-8DE9A809A6A4}
Upgrading 'Python 2' (id='Python.Python.2') using 'winget upgrade --id Python.Python.2 --exact'
Multiple installed packages found matching input criteria. Please refine the input.
Name Id
-------------------------------------------------------------
Python 2 Python.Python.2
Python 2.7.16 (64-bit) {DCD5B320-89D9-4C7C-9E8B-84496588744e}
Upgrading 'Microsoft .NET SDK' (id='Microsoft.dotnet') using 'winget upgrade --id Microsoft.dotnet --exact'
Multiple installed packages found matching input criteria. Please refine the input.
Name Id
-----------------------------------------------------------------------
Microsoft .NET SDK Microsoft.dotnet
Microsoft .NET SDK 5.0.303 (x64) {b447173e-28f0-40ae-b0c8-15b9c0a1ad4b}
I have the opposite problem: There are NO installed packages found when trying to upgrade despite an update for it being found in the first place. I found bug https://github.com/microsoft/winget-pkgs/issues/47041#issue-1144122604 and wanted to comment there, but this got closed as duplicate and linked to here.
I am not sure these are the same bugs.
winget --version
v1.2.10271
winget upgrade
Name Id Version Available Source
------------------------------------------------------------------------------------------------------------------------------
<stuff before>
Microsoft Visual C++ 2008 Redistributable … Microsoft.VC++2008Redist-x86 9.0.30729.4148 9.0.30729.6161 winget
<stuff after>
52 upgrades available.
winget upgrade "Microsoft.VC++2008Redist-x86"
No installed package found matching input criteria.
winget upgrade --id "Microsoft.VC++2008Redist-x86"
No installed package found matching input criteria.
winget upgrade --name "Microsoft Visual C++ 2008 Redistributable - x86"
No installed package found matching input criteria.
winget upgrade --exact --id "Microsoft.VC++2008Redist-x86"
No installed package found matching input criteria.
winget upgrade --exact --name "Microsoft Visual C++ 2008 Redistributable - x86"
No installed package found matching input criteria.
I assume this is the error mentioned above:
PS C:\Users\username> winget upgrade --all
Found Microsoft Visual C++ 2015-2022 Redistributable (x86) [Microsoft.VC++2015-2022Redist-x86] Version 14.32.31302.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://download.visualstudio.microsoft.com/download/pr/79465679-7995-4f6c-984b-33de61668fe4/37E08B5D6EDC325ACD805AD35CEE6506ADAF88ACCC7086BE2E771E69400AADE8/VC_redist.x86.exe
██████████████████████████████ 13.0 MB / 13.0 MB
Successfully verified installer hash
Starting package install...
Successfully installed
PS C:\Users\username> winget upgrade
Name Id Version Available Source
-----------------------------------------------------------------------------------------------------------------------
Microsoft Visual C++ 2015-2022 Redistributa… Microsoft.VC++2015-2022Redist-x86 14.31.31103.0 14.32.31302.0 winget
1 upgrade available.
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.
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.
Indeed, the mess can be impressive:
I've cleaned that up on all my PCs, now will monitor if further upgrades will work as expected.
@alkampfergit this issue is quite old and was full of different classes of errors. I believe the original issue you reported was due to the situation identified by @PudottaPommin.
@sba923 Have you encountered any more trouble after removing the "extra" entries?
We've made several improvements in WinGet 1.4 related to matching and the upgrade scenario with packages that are installed side-by-side.
@alkampfergit this issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment.
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
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-x64
instead of it
winget upgrade --id Microsoft.VC++2013Redist-x64
