How to check "unchecked" from msiexec command line?

Question

I have msi (author of WIX) that has a checkbox tied to a custom property (name it MY_PROPERTY). I would like to run this msi from the command line, specifying 0 (unchecked) or 1 (checked) for this property. My script will determine the appropriate value (based on the environment) and enter that value in the msiexec command line. My command line looks something like this:

msiexec /i my_installer.msi MY_PROPERTY=$value 

Where $ value is 1 or 0, depending on the environment. The problem is that no matter what value I set for MY_PROPERTY on the command line, the checkbox is always checked (and the property will always be set to 1). The only way to clear the checkbox is to not specify the property (leave it undefined). It should be noted that this behavior occurs regardless of whether the user interface is displayed (adding "/ quiet" to the above command line does not change this behavior).

This msdn message seems to indicate that this is a known bug in the Windows installer (more precisely, regardless of which authoring system wrote msi). As a solution, post-build msi hack is proposed. I am wondering if someone ran into this problem and came up with a better workaround / solution. Thanks!

Update

I see three solutions to this problem:

• From @Damien so that the shell of the script does not pass the msiexec property when its value is 0. This makes the script more complicated and will probably prevent me from overriding the value of the checkbox, which defaults to "checked".
• From @Michael Urman, add a custom action that will clear the property if its value is zero. This makes msi more complicated, and I will need to add such a custom action for each checkbox in the user interface.
• Another idea is to simply prohibit the use of checkboxes in our MSI installers, and instead use radio boxes or drop-down lists for “true / false” questions. Although this limits the user interface settings for our installers, it allows shell scripts to remain simple and does not require special actions to “crack” properties.

I am currently leaning towards option 3, although option 1 is probably the best answer to my original question. Any thoughts?

Answer 1

This is how it is “supposed” to work - in principle, the property does not exist until the user checks the checkbox, then it is “set” (exists). Therefore, if you want to perform a custom action when the checkbox is selected, you check for the presence of a property as a condition for triggering a custom action, instead of checking the value that user support has.

I think the best way to deal with this from the command line is what you already mentioned: if you want this flag to be selected, specify a custom support in the command line, otherwise not, and the flag will not be selected.

Answer 2

As you have discovered, the checkboxes are true (checked) when the property is defined (not empty) and false (not checked) when the property is undefined (empty). It looks like you need to convert the environment line 1 or 0 to the true / false flag, where 1 or 0 is passed on the command line. Try using the custom set-property action, which sets your property to {} (empty) with the condition that the property is already "0" . Plan it early on in both the installation interface and the Execute installations.

Late update. Regarding the need to use multiple custom actions to handle multiple checkboxes, you have a choice. You can either create several set-property actions (advantage: it’s easy to understand what they do, cost: many of them), or you can create a single code user action that will go through the Checkbox table for a list of properties that need to be converted from 0 to empty (advantage: one action, cost: poorly documented, custom code). The second advantage of the latter approach is that you can handle unusual Value settings, such as a checkbox, which should set property 0 if it is set.