microsoft / microsoft/winget-cli

Matching logic needs to be updated.

Open
#2,995 16 comments 28 reactions 1 assignee View on GitHub

@yao-msft is already working on this.

Since Mar 1, 2023.

Area-Matching Issue-Bug
Dominant language
C++
Stars
26.4k
Forks
1.8k
Avg merge
1d 11h
Merged PRs (30d)
15

Description

Brief description of your issue

Several packages aren't correctly being matched for several command flows.

Before we had the "displayName" key available in the manifest, we had to try and match the "packageName" in the manifest against the "displayName" in the registry.

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".

Steps to reproduce

This is only one example of how this bug manifests:

This exact example was reported by @K8-and-a-half-1000

PS C:\> winget install -e --id Microsoft.VCRedist.2012.x86; winget install -e --id Microsoft.VCRedist.2012.x64
Found Microsoft Visual C++ 2012 Redistributable (x86) [Microsoft.VCRedist.2012.x86] Version 11.0.61030.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.microsoft.com/download/1/6/B/16B06F60-3B20-4FF2-B699-5E9B7962F9AE/VSU_4/vcredist_x86.exe
  ██████████████████████████████  6.25 MB / 6.25 MB
Successfully verified installer hash
Starting package install...
Successfully installed
Found an existing package already installed. Trying to upgrade the installed package...
No applicable upgrade found.

In this example, WinGet installs the right package "Microsoft Visual C++ 2012 Redistributable (x86)", but during the subsequent install of "Microsoft Visual C++ 2012 Redistributable (x64)", the previous package is a false positive match leading to the upgrade flow for the "(x86)" which is already up to date.

Expected behavior

When a manifest contains the "displayName" key, the heuristics trying to match the "packageName" with the installed packages "displayName" should be ignored.

Actual behavior

False positives matching the wrong package are occurring.

Environment
Windows Package Manager (Preview) v1.5.441-preview

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.