Advinst as another default installer

[PirvulescuDaniel]

• I have signed the Contributor License Agreement.
• This pull request is related to an issue.

---

Microsoft Reviewers: Open in CodeFlow

[PirvulescuDaniel]

@microsoft-github-policy-service agree

[PirvulescuDaniel]

• the issue: [New Feature]: add adv installer as another default installer #4429

[Trenly]

I had opened a PR for this previously - One issue with this is that AdvancedInstaller is an installer technology and not an insaller type. AdvancedInstaller can be used to build multiple types of installers, each having different install switches.

See the comments in #2617

[PirvulescuDaniel]

I had opened a PR for this previously - One issue with this is that AdvancedInstaller is an installer technology and not an insaller type. AdvancedInstaller can be used to build multiple types of installers, each having different install switches.

See the comments in #2617

Through the listed installer types, there are also vendors that create these installations (Wix/Inno/Nullsoft). From what I've noticed, if the installer type is a vendor, the installer is considered as an .exe. Am I wrong?

[Trenly]

I had opened a PR for this previously - One issue with this is that AdvancedInstaller is an installer technology and not an insaller type. AdvancedInstaller can be used to build multiple types of installers, each having different install switches.
See the comments in #2617

Through the listed installer types, there are also vendors that create these installations (Wix/Inno/Nullsoft). From what I've noticed, if the installer type is a vendor, the installer is considered as an .exe. Am I wrong?

The difference here is that WiX will always be an MSI thpe, Nullsoft / Inno / Burn will always be an EXE type. However, AdvancedInstaller could be an EXE, an MSI, or an APPX

This comment specifically describes that supporting only an EXE implementaion for AppInstaller would "not look very good" - #2617 (comment)

[PirvulescuDaniel]

I had opened a PR for this previously - One issue with this is that AdvancedInstaller is an installer technology and not an insaller type. AdvancedInstaller can be used to build multiple types of installers, each having different install switches.
See the comments in #2617

Through the listed installer types, there are also vendors that create these installations (Wix/Inno/Nullsoft). From what I've noticed, if the installer type is a vendor, the installer is considered as an .exe. Am I wrong?

The difference here is that WiX will always be an MSI thpe, Nullsoft / Inno / Burn will always be an EXE type. However, AdvancedInstaller could be an EXE, an MSI, or an APPX

This comment specifically describes that supporting only an EXE implementaion for AppInstaller would "not look very good" - #2617 (comment)

I don't see any difference in the way to install an MSI, regardless of which vendor it is made. MSI is something generic. Why should an MSI made with WiX be treated as WiX, not as an MSI? Differences between vendors appear only in EXEs.

[Trenly]

I don't see any difference in the way to install an MSI, regardless of which vendor it is made. MSI is something generic. Why should an MSI made with WiX be treated as WiX, not as an MSI? Differences between vendors appear only in EXEs.

Because there are differences between MSI's made with different vendors. Default silent install parameters and install location switches are the most common, but uninstall switches, how they write ARP data, and the internal properties can all differ with the vendor. The point of specified installer types in the client is to provide meaningful default behaviors where there are differences between vendors - and that includes MSI installers.

Not only that but some implementations of MSI have bugs specific to their vendor. Take WIX for example - Regardless of what scope (user scope or machine scope) a WIX installer is installed in, the application's uninstaller entry will always be written to HKLM, which should only be for machine scoped installs (user scoped installs should write to HKCU). Other MSI vendors don’t have this issue.

---

For a specific example - If the installer type is specified as msi in the manifest - using --location <path> with the winget install command will result in TARGETDIR=<path> being passed to the installer. However, for MSI's built with AdvancedInstaller, this will not work, as the default location switch for AdvancedInstaller MAI's is APPDIR=<path>

[PirvulescuDaniel]

So, from what I understand, winget cannot support "advinst" as install-type because this technology can produce multiple types of installers. However, as in the case of AdvancedInstaller, WiX can produce several types of installers too (.msi and .exe). Why is WiX always considered MSI?

[Trenly]

I'm not saying that Advanced Installer can't be supported, I was just trying to make you aware of the history and previous PR and the comments on it from @yao-msft; especially since the comments aren't just nits.

---

WiX can produce several types of installers too (.msi and .exe). Why is WiX always considered MSI?

I think there is a nuance there that an msi produced by WiX is wix amd an exe produced by WiX is a burn because when Wix is used to produce an exe, it's really just an MSI inside a bundle that uses the Burn Engine

[PirvulescuDaniel]

I think there is a nuance there that an msi produced by WiX is wix amd an exe produced by WiX is a burn because when Wix is used to produce an exe, it's really just an MSI inside a bundle that uses the Burn Engine

In this case, is it a solution to use different entries in the install-type for the installers made with AdvancedInstaller, "advinstMsi", "advinstExe" and "advinstMsix", as was proposed here? I don't see another solution.

[Trenly]

In this case, is it a solution to use different entries in the install-type for the installers made with AdvancedInstaller, "advinstMsi", "advinstExe" and "advinstMsix", as was proposed here? I don't see another solution.

I would think so, but I still don’t think there has been an answer to -

Mainly, the team may need a bit more time to try and understand what this installer technology is doing and decide how much we will support.

[PirvulescuDaniel]

From what I can see, the unit tests have changed since the last approach. Are tests still required for installation types? For example, I can't find the tests for Wix and Burn. If they are required, is there a more recent example of such tests?