Handling matching failures for single installer updates

[ryfu-msft]

Hi everyone,

Several members of the community have had issues with "matching" failures when using Winget-Create to update their single installer manifests.

For example, when entering the following command:

wingetcreate update Microsoft.WindowsSDK -u https://download.microsoft.com/download/9/7/9/97982c1d-d687-41be-9dd3-6d01e52ceb68/windowssdk/winsdksetup.exe

The output returns:

Multiple matches found for X86 Burn installer detected from the url: https://download.microsoft.com/download/9/7/9/97982c1d-d687-41be-9dd3-6d01e52ceb68/windowssdk/winsdksetup.exe

When comparing with the existing manifest, it shows the Windows SDK installer to be an x86 EXE installer.

Installers:
- Architecture: x86
  InstallerUrl: https://download.microsoft.com/download/4/2/2/42245968-6A79-4DA7-A5FB-08C0AD0AE661/windowssdk/winsdksetup.exe
  InstallerType: exe
  InstallerSha256: 2E28117E82B4D02FE30D564B835ACE9976612609271265872F20F2256A9C506B
  InstallerSwitches:
    Silent: /q
    SilentWithProgress: /q

How should we handle this scenario? Some users have pointed out that updating a single installer should just "work" since there is nothing else to match to, but we also don't want to overwrite existing metadata if the installerTypes don't match (i.e. switches for exe installers). We want the update command to support autonomously updating as many single-installer packages as possible, but we also don't want to overstep and cause issues by overwriting the manifest. What do people feel is the best solution?

[jedieaston]

I think that much of the problem is that Burn looks like an exe unless you poke inside the executable, which many people (me included) do not do unless we are curious.

What if the InstallerType was updated but the install switches were not unless they include some of the install switches winget uses by default (for example, Burn/Wix/MSI uses /quiet /passive and some other ones to set the logging directory)? Seems like the best of both worlds, although you might have to get a little bit fancy with the find and replace (since /q == /quiet for Burn). The only trouble with that is that it would end with some confusion on the user's part if their PR failed Installation Validation, but some messaging that the installer was corrected would fix it IMO (plus a --no-fix-installers option which doesn't touch the installers but explains what happened, I suppose).