Schema extension to support multiple ARP entries.

[jedieaston]

Description of the new feature/enhancement

It would be really nice if there was a extension to the schema to allow a package manifest to list all of the ARP entries that an installer adds to support edge cases when winget tries to match packages to entries in the ARP table.

Proposed technical implementation details (optional)

Per installer entry, there would be a array of "Programs" which captures the major metadata that the ARP table captures (property names are off the dome, they may conflict with something):

...installer info
Programs:
   - ProgramName: Mozilla Firefox en-US
     ProgramVersion: 89.0
     ProgramPublisher: Mozilla
     ProductCode: "{AAAAA-AAAAA-AAAAA-AAAAA-AAAAA}"
   - ProgramName: Mozilla Maintenance Service
     ProgramVersion: 3.4.1
     ProgramPublisher: Mozilla
     ProductCode: "{BBBBB-BBBBB-BBBBB-BBBBB-BBBBB}"

This would also require changes to the package manager client to allow it to match an ARP entry to a manifest even if the outer PackageName/Publisher/etc didn't match but there was a entry in the Programs array that did, of course. Maybe there's a better way to do this, but we're running into lots of issues where one language/architecture/etc adds a different entry to the ARP table than another language/architecture/etc meaning that winget has trouble matching them.

Edit: In addition to the client itself, there will have to be some (probably breaking) changes to the SQLite preindexed file that is used for the data from the community repo. I'm not jealous of whoever has to implement those...

[sredna]

You probably need wildcard support to find the Firefox ARP key: Mozilla Firefox * as it seems to change the key name every time you update Firefox.

[jedieaston]

Or we can just update it every time we make a new manifest. I just used Firefox as a example, the JetBrains apps, Python, and a lot of other apps have funny ways of naming things for the ARP table that are different than how you'd want them to appear in the package repository.

[denelon]

@sredna we've been playing with various regex combinations and the wildcard leads to other trouble with packages that do side by side installs with minor variations depending on architecture, and user vs. machine. We're still thinking through the next best solutions.

[denelon]

We need to make sure we include documentation on the logic used to perform the matching between the manifest and the entry in Add / Remove Programs.

[denelon]

How about:

AppsAndFeaturesEntries:
  - AppName: Foo
    AppPublisher: Contoso
    AppVersion: 1.2.3
    ProductCode: "{AAAAA-AAAAA-AAAAA-AAAAA-AAAAA}"
    UpgradeCode: "{ABAAA-ABAAA-ABAAA-ABAAA-ABAAA}"
  - AppName: FooService
    AppPublisher: Contoso
    AppVersion: 2.3.4
    ProductCode: "{BBBBB-BBBBB-BBBBB-BBBBB-BBBBB}"
    UpgradeCode: "{BCBBB-BCBBB-BCBBB-BCBBB-BCBBB}"

Edit: Changed "ProgramsAndFeaturesEntries" to "AppsAndFeaturesEntries" to align with Windows 11 UI naming. "Name", "Publisher", and "Version" renamed to "AppName", "AppPublisher", "AppVersion".

[denelon]

https://github.com/microsoft/winget-cli/releases/tag/v1.0.12576

The validation pipelines aren't updated yet. Building the new client is a prerequisite as we use the client itself in the validation pipelines. This should be testable via local manifest files, but they are not yet supported in the community repository. That work is in progress.