Specify InstallerType

[denelon]

Add an argument and settings to specify installer type

As a user I would like to be able to specify which installer type to use on my machine.

Proposed technical implementation details (optional)

This could be an argument like: winget install foo.bar --installer-type exe

There could also be settings to specify a "preferred" installer type or a "required" installer type.

Given a "required" installer type, the search results could be trimmed to include only packages with manifests supporting my "required" installer type.

• Code updated to allow for an ordering
• Settings to enable preference/requirement and the ordering thereof
• Command line argument to specify immediate requirement
• COM API update to enable a choice there

[Trenly]

Just a question for consideration -

Would you expect that such a feature would consider the installer type inside of an archive, or the archive itself? E.g - If a user specifies --installer-type msi, would a Zip with a NestedInstallerType of msi satisfy the search criteria?

[denelon]

Great question, I'm glad you brought it up. I would say it should, but I'm open to opposing viewpoints.

[borque]

Any news on this?

[denelon]

I believe the default ordering should be:

1. MSIX
2. MSI
3. EXE
4. Portable

The .zip type should follow the same ordering as above and logically isn't an installer type per se' but more about a distribution mechanism.

The settings should use the installer types as an enumeration for the purposes of validation. We should also reason about users having the ability to exclude installer types so they could for example only allow MSIX based packages, or they could exclude portable packages.

[denelon]

This is being included in 1.6 due to the work to support:

• #658

[manelrodero]

It would be very interesting to advance in this process to be able to specify the type without depending on the order that has been indicated in the manifest.

For example, for a few months the usual installation of Foxit Reader has not worked because the default installer used by winget has been changed. I explained this more than a month ago in this tweet https://twitter.com/manelrodero/status/1674022113085145089 and later indicated it in the SpecterShell commit.

Today a new version has appeared with the same "problem", it does not support the parameters that are passed through an override.

Any ideas on how to use the second installer as long as we can't specify the type?

[denelon]

@manelrodero this is a new feature in WinGet 1.6. I don't believe there is a workaround until this gets released. We're expecing a Release Candidate build in the next week or so and plan to go out with this at the end of September.

[ryfu-msft]

It would be very interesting to advance in this process to be able to specify the type without depending on the order that has been indicated in the manifest.

For example, for a few months the usual installation of Foxit Reader has not worked because the default installer used by winget has been changed. I explained this more than a month ago in this tweet https://twitter.com/manelrodero/status/1674022113085145089 and later indicated it in the SpecterShell commit.

Today a new version has appeared with the same "problem", it does not support the parameters that are passed through an override.

Any ideas on how to use the second installer as long as we can't specify the type?

@manelrodero, this feature has been checked in but won't be available until our 1.6 release. Once that is available, you will be able to specify the exact installer type you want by using the --installer-type flag.

example: winget install foo.bar --installer-type inno