winget install support specifying installer extension/type (EXE vs. MSI)

[o-l-a-v]

Description of the new feature / enhancement

For new installs where several install types/ extensions are available, I'd like the ability to specify it with winget install.

Examples packages with both EXE and MSI available:

• 7-Zip
  • Because Igor prefers and recommends EXE over MSI.
    • https://sourceforge.net/p/sevenzip/support-requests/289/
• KeePass
  • Because Winget does not work with --location on this specific package
    • -l,--location option not working on all msi packages #1857.
  • Important because EXE and MSI installs to different locations, potentially four different locations historically, thus specifying install location makes making detection rules easier.

This should of course be combined with the ability to:

• Specify architecture with winget install, which is already supported:
  • https://docs.microsoft.com/en-us/windows/package-manager/winget/install
• Specify preferred installer type/ extension inside the settings file -> Install behavior, which is currently not supported.
  • https://github.com/microsoft/winget-cli/blob/master/doc/Settings.md#install-behavior

Proposed technical implementation details

I don't know. This get's messy quick. Manifest already has installertype, but that hints towards installer vendor (Inno, Nullsoft etc.) rather than MSI vs. EXE.

installertype should be used to store the general installer type IMO, like:

• EXE
• MSI
• MSIX
• ZIP\EXE
• ZIP\MSI
• ZIP\MSIX

While installervendor could store the vendor/ creator of the installer, like:

• Inno
• Microsoft (MSI, MSIX)
• Nullsoft

[Trenly]

I don't know. This get's messy quick. Manifest already has installertype, but that hints towards installer vendor (Inno, Nullsoft etc.) rather than MSI vs. EXE.

INNO, BURN, NULLSOFT, and EXE are all .exe files
WIX and MSI are .msi files
PORTABLE is a loose binary file, which is an .exe without an installer
MSIX is a .msixbundle
APPX is an .appxbundle
ZIP is a .zip file, which has another installer type nested inside of it. The specification for this is still in progress
PWA is a portable web app

I don't see a need to add an InstallerVendor field, when the InstallerType can inherently be equated to a file extension.

I do agree that being able to specify installer type would be a great feature, but I dont think it needs to be at the file extension level. Rather, the InstallerType as it currently stands would be good enough in my opinion

[denelon]

Duplicate of #1166

[ghost]

@o-l-a-v we've identified this Issue as a duplicate of another one that already exists. This specific instance is being closed in favor of tracking the concern over on the referenced Issue. Thanks for your report! Be sure to add your 👍 to the other issue to help raise the priority.