[Package Issue]: Microsoft.VCRedist.2012.x64 points to x86 version! #97053
Comments
K8-and-a-half-1000
added
the
Issue-Bug
microsoft-github-policy-service
bot
added
the
Needs-Triage
|
Can you share your install logs and the full output from According to the manifest, the only installer in VCRedist.2012.x64 is the x64 version |
|
Sure thing. And if I do it with the x64 specification, I get a weird mashup. Add and remove programs list confirms that only the 2012 x86 package is installed. |
|
Some code is obviously altering the (x64) specification, and it's not handled properly. These are the logs for installing the x64 package: |
|
Interesting. The logs say that nothing was installed because there was
Do you have the logs from installing with |
|
After checking my environment, I see the same issue has occurred for the package Microsoft.VCRedist.2013.x64. |
|
Thanks! |
|
This is for |
|
My best guess: The issue seems to be that the There is no upgrade log. The output is this: Found an existing package already installed. Trying to upgrade the installed package...
No applicable upgrade found. |
|
You're mostly correct; the package matching especially for the VCRedists is a bit finnicky. Using |
|
Any solution for this check? I need to be able to detect if this package is installed. ^ Update: I'll detect the presence of (x86) in the list result via powershell, and ignore that output. |
stephengillie
added
Help-Wanted
|
We've got some ideas, and we will do some experimentation. We have some fuzzy matching heuristics where we essentially ignore anything at the end of a "displayName" like: "(*)". We're going to run some tests against manifests with the "AppsAndFeatures" entry for "displayName" to see if anything messes up, or if it improves matching in some cases. |
|
Fuzzy matching on the A search can be fuzzy or exact, but it can't be both. |
|
@K8-and-a-half-1000 the "-e" applies to the package identifier. That's getting an "exact" match to the manifest. The challenge is what's in the manifest and which registry entry values are present. Several packages modify the string in the "displayName" property in Windows Apps & Features. We often see architecture at the end of the "displayName" like "(x86)" or "(x64)" which leaves some ambiguity. We also see cases where different installers may not report the "displayVersion" properly or they may not upgrade it properly. This is where the fuzzy matching comes into play. We're working on changing the heuristic for those cases where we have an "AppsAndFeatures" entry, so we don't ignore what's in parenthesis. Unfortunately, VCResist packages don't all follow semantic versioning, and there are no standard keys for specifying installer architecture. I'm working with other teams to see about adding those keys as standard keys for installers to leverage, but that is a much bigger scope work item, and it will have a long lead time both in terms of getting it into the OS, and the length of time it takes various software publishers to start using those values. |
|
@denelon - seems like a "quick fix" would be to also make -e make the --name parameter strict, not just the ID |
|
@denelon Let me show you what I mean: The |
|
Ah, I see the issue; It isn't that the package identifier or name points to the wrong version, it's that the matching to existing ARP entries isn't accurate. This is a much deeper issue than just the ID or DisplayName |
|
@Trenly |
|
We're experimenting with some additional logic like: We're testing to see if it improves matching or if it worsens matching. |
|
@denelon Please stop moving the goalpost to something else. |
|
@K8-and-a-half-1000 "packageIdentifier" is a manifest construct. Installers (except for portable packages) are writing the registry keys WinGet depends on to determine a "match". The "--exact" argument is working to match the given input to a manifest and somewhat indirectly to a package based on the metadata in the manifest. There is a level of mapping necessary to match a manifest with an installed package. When the installer doesn't provide accurate, correct, unique data for WinGet to match on. The only option left is heuristics to find a "best match". The goal post hasn't moved. It's more a matter of how we get there. We're trying to meet developers where they are in terms of their current installers and enabling a way for them to operate as well formed "packages". In many cases, it's a matter of bad data in bad data out. I'm open to suggestions that are going to improve the situation. |
🙈 https://learn.microsoft.com/en-us/windows/package-manager/winget/install
Look at the package IDs ☝️ One of these next outputs is wrong, can you spot it? The -e flag either finds an exact match, or it fails. |
|
IMO, this boils down to being a CLI bug around Area-Matching and Area-Side-By-Side Its specifically an issue with list due to how currently installed packages are matched to Package Identifiers, which is why it isn’t occurring with search but is converting the install flow to an upgrade flow |
|
Yes. Before we had the "displayName" key available in the manifest, we had to try and match the "packageName" against the "displayName". Now we need to change the behavior so that when the "displayName" key is present in the manifest WinGet will stop trying to find a match by dropping the values in parenthesis at the end of the registry key mapped to the Windows Apps & Features "displayName" . |
|
Ok, seems like we're all on the same page now. I have some spare time during the weekend to debug this issue further. |
|
Several other issues are tracking issues related to VC Runtimes and side-by-side. I'm closing this issue in favor of the work over at the CLI. Close with reason: Tracked at CLI; |
Please confirm these before moving forward
Category of the issue
Installation issue.
Brief description of your issue
If I run:
winget install -e --id=Microsoft.VCRedist.2012.x64or:
winget install -e --name='Microsoft Visual C++ 2012 Redistributable (x64)'winget only installs the x86 version of this package!
This is breaking some orchestration scripts I maintain, please fix this ASAP.
As a workaround, I need to download and install the x64 via powershell, which is not ideal.
Steps to reproduce
If I run:
winget install -e --id=Microsoft.VCRedist.2012.x64or:
winget install -e --name='Microsoft Visual C++ 2012 Redistributable (x64)'Actual behavior
winget installs the x86 version.
Expected behavior
winget installs the x64 version.
Environment
Screenshots and Logs
No response
The text was updated successfully, but these errors were encountered: