Foxit Reader installer type has been changed again

[manelrodero]

Our automated process to install Foxit Reader using winget has been failing since last Friday.

We get an error code:

0x8A150010 -1978335216 APPINSTALLER_CLI_ERROR_NO_APPLICABLE_INSTALLER None of the installers are applicable for the current system

We review the commits and see that the INNO type installer (which still exists) has been changed to an MSI type installer a few days ago:

5d90bdd

This has already happened in the past and since then we forced the type of installer we want to use to be able to use the override options.

We asked it here microsoft/winget-cli#1166 (comment) and used it since winget version 1.6:

--installer-type inno --override "/COMPONENTS="pdfviewer,ffSpellCheck" CPDF_DISABLE="1" DISABLE_UNINSTALL_SURVEY="1" /TASKS="startmenufolder" /VERYSILENT"

Who should we ask to put back the INNO type installer that still exists? You cannot change the available installers just like that because it affects the users who use them. @SpecterShell ??

Thank you.

[SpecterShell]

The Inno installers have been moved to a separate package Foxit.FoxitReader.Inno due to a bug from WinGet: When both the EXE (MSI) installer and the Inno installer coexist in the manifest, WinGet can't distinguish between the two types of installers and always select the EXE (MSI) one for upgrade even if the existing installation comes from the Inno installer. This was reported in #156396.

[SpecterShell]

I moved the Inno ones out because I thought most enterprise users were using the MSI version for deployment. Sorry about this.

[manelrodero]

I understand the problem.

Back in the day, before the option appeared to specify the type of installer you want, Denelon commented on the order in which they are selected:

microsoft/winget-cli#1166 (comment)

We use the INNO installer since parameters can be passed to it to configure it with only the components we need.

For now, we will change the name of the package we use while we investigate whether the "normal" package can accept parameters.

Thanks for the explanation.

[manelrodero]

@denelon,

Would it be possible to review the problem with the selection of installers?

The idea is that there would be a single package for each application and different installers that you could select by forcing the type.

More than anything to know if this division will be like this for life or will everything be put back together in a single package later and our installation process will fail again ;-)

Thank you.

[denelon]

I do want to get to a point where we have a single manifest for any particular version of a package. I agree that this is challenging right now. I don't remember if there is already an issue opened for this scenario or not.

We do need to revisit our package selection logic. One of the trickiest areas is when the "installer" we download is one type, but the installer being reported in the registry is another. We used to have more trouble when it was an .exe installer, but there was a nested MSI. I've seen a few more cases like this recently where WSL is an MSI with a nested MSIX.

I know there is an Issue for us to treat WIX and MSI as "equal", but that's also adjacent here.

Feel free to create an issue, and if it's a duplicate, we will find the duplicate to track the "real" work and look at how we can address this issue. I think another thing I've seen a couple of times is when we're looking to do an upgrade and we have mismatched "default" scopes in the manifest. I'd keep that issue separate.

[RokeJulianLockhart]

@manelrodero, microsoft/winget-cli#1166 (comment)