Auto-updates weren't working with the current installers because msiexec /i is now refusing to reinstall an already-installed package. Based on my research and experimentation, it looks like we need to use msiexec /fvomus instead.
Also, here we finally tackle #133. This turned out to be an enormous, dumb can of worms. The salient issues are as follows:
When you specify something like AUTOUPDATE=0 on an msiexec command line, that's a "property".
Our current installer UI is a checkbox labeled "Automatically check for updates on launch" that is enabled by default. It's wired to a property AUTOUPDATE.
As far as the Windows Installer system is concerned, properties are string-typed. Their truthiness is false for an undefined (empty-valued) property, and true for everything else.
Windows Installer checkboxes link to properties using the above definition of truthiness. If the UI ends up with the box checked, the property is given a specific string value. Otherwise, the property is deleted.
The Visual Studio installer creator has a bug where if you have a checkbox referring to a property, any value for the property specified on the command line will be overridden by the checkbox initialization, even if the checkbox UI is never actually shown. Discussion here.
As far as I can tell, you can't set integer-typed registry keys from properties since the latter are string-typed.
So the mess is:
To work around the Visual Studio bug, the most convenient thing to do is apply a condition to the custom action that overrides the command-line property. The straightforward condition is NOT(AUTOUPDATE), i.e. only run the defaulting custom action if the property isn't already defined.
But since AUTOUPDATE defaults to true, that condition would override our desired behavior of being able to force it to false on the command line
Furthermore, the syntax for clearing properties on the command line is unnatural: AUTOUPDATE="" ... which also just doesn't work in PowerShell. It only works in cmd
The above problems would be a lot simpler to tackle if we inverted the meaning of checkbox and property: NOAUTOUPDATE, with a default of being unchecked. But that kind of double-negative is confusing and changes the existing behavior.
If we don't want to make that inversion, we can make the following change:
Say that valid values of AUTOUPDATE are undefined, OFF, or ON
Add a condition on the checkbox initializer to only run if AUTOUPDATE is undefined
Set the conditions on the registry key creation to be:
Set to 1 if AUTOUPDATE AND AUTOUPDATE<>"OFF"
Set to 0 if NOT(AUTOUPDATE) OR AUTOUPDATE="OFF"
This way, in the no-UI case, we'll default to ON, but AUTOUPDATE=OFF on the command line will change that. Non-empty values other than OFF will default to updates on. In the UI case, we'll get the intended behavior, with the wrinkle that if the user unchecks the box the property will be deleted, not set to OFF. (This is why the registry settings have to check for NOT(AUTOUPDATE).
The biggest limitation here is that in the UI case, if you set AUTOUPDATE on the command line too, the setting is ignored -- specifically, AUTOUPDATE=OFF still results in the checkbox being checked. I believe this is a limitation of the checkbox initialization code. We could potentially work around it with some kind of custom action that deletes/clears AUTOUPDATE if it is set to OFF early on, but that's just more than I want to deal with right now.
Other notes:
Debug logs help a lot. msiexec /i path\to\msi.msi /l*vx log.log That's slash-ell-asterisk-vee-ex
Use /qb for visible-but-no-prompts installation
If you specify the installer path as .\setup.msi, msiexec will tell you that the installer is invalid for some reason. If you remove the leading dot-slash, it's fine.
Auto-updates weren't working with the current installers because
msiexec /iis now refusing to reinstall an already-installed package. Based on my research and experimentation, it looks like we need to usemsiexec /fvomusinstead.Also, here we finally tackle #133. This turned out to be an enormous, dumb can of worms. The salient issues are as follows:
AUTOUPDATE=0on anmsiexeccommand line, that's a "property".AUTOUPDATE.So the mess is:
NOT(AUTOUPDATE), i.e. only run the defaulting custom action if the property isn't already defined.AUTOUPDATEdefaults to true, that condition would override our desired behavior of being able to force it to false on the command lineAUTOUPDATE=""... which also just doesn't work in PowerShell. It only works incmdThe above problems would be a lot simpler to tackle if we inverted the meaning of checkbox and property:
NOAUTOUPDATE, with a default of being unchecked. But that kind of double-negative is confusing and changes the existing behavior.If we don't want to make that inversion, we can make the following change:
AUTOUPDATEare undefined,OFF, orONAUTOUPDATEis undefinedAUTOUPDATE AND AUTOUPDATE<>"OFF"NOT(AUTOUPDATE) OR AUTOUPDATE="OFF"This way, in the no-UI case, we'll default to ON, but
AUTOUPDATE=OFFon the command line will change that. Non-empty values other thanOFFwill default to updates on. In the UI case, we'll get the intended behavior, with the wrinkle that if the user unchecks the box the property will be deleted, not set to OFF. (This is why the registry settings have to check forNOT(AUTOUPDATE).The biggest limitation here is that in the UI case, if you set
AUTOUPDATEon the command line too, the setting is ignored -- specifically,AUTOUPDATE=OFFstill results in the checkbox being checked. I believe this is a limitation of the checkbox initialization code. We could potentially work around it with some kind of custom action that deletes/clearsAUTOUPDATEif it is set toOFFearly on, but that's just more than I want to deal with right now.Other notes:
msiexec /i path\to\msi.msi /l*vx log.logThat's slash-ell-asterisk-vee-ex/qbfor visible-but-no-prompts installation.\setup.msi,msiexecwill tell you that the installer is invalid for some reason. If you remove the leading dot-slash, it's fine.