This seems unnecessarily complicated. If the property is not defined to any value, it's already unset by Windows Installer's definition, thus not needing all the explicit ...=1 conditions below.

It's also fine to just bind the actual property to the RegistrySearch. See https://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern/.

The reason for this complexity is explained in the comments above. What that "Remember Property" pattern doesn't handle is allowing the option to be changed via a checkbox in the UI. If a property has a value, the checkbox that uses that property will be initially checked. It doesn't matter whether the property's value is 0 or 1 or something else; if the property exists, the checkbox is checked. So if the option was disabled, we would remember the property value as 0. On the next install, that property would be initialized to the value of 0, but because the property exists, the checkbox would initially be checked.

I'm definitely not a WiX expert, so if there's a simpler way to do this, I'd love to know.

If 0 is checking the check box, it could be that the Integer attribute needs to be set on it. It should be able to bind directly if treated as an integer instead of the default string (which is set if it has any value since 0 is actually "0" in that case).

😞 Unfortunately that didn't help. I tried it out on the checkbox for ADD_FILE_CONTEXT_MENU_RUNPOWERSHELL like so:

<Control Id="ContextMenuRunPowerShell" Type="CheckBox" X="20" Y="160" Width="290" Height="17" Property="ADD_FILE_CONTEXT_MENU_RUNPOWERSHELL" Integer="yes" CheckBoxValue="1" Text="Add '$(var.PowerShellFileContextSubMenuDialogText)' context menu for PowerShell files"/>

And I reduced the property initialization back to just getting the previous value and restoring the previous value:

<Property Id="PREVIOUS_ADD_FILE_CONTEXT_MENU_RUNPOWERSHELL">
  <RegistrySearch Id="GetSavedAddFileContextMenuRunPowerShell" Root="HKLM" Key="$(var.InstallerPropertiesKey)" Name="AddFileContextMenuRunPowerShell" Type="raw" />
</Property>
<SetProperty Id="ADD_FILE_CONTEXT_MENU_RUNPOWERSHELL" Action="AddFileContextMenuRunPowerShell_SetFromSaved" After="AppSearch" Value="[PREVIOUS_ADD_FILE_CONTEXT_MENU_RUNPOWERSHELL]" Sequence="first">
  PREVIOUS_ADD_FILE_CONTEXT_MENU_RUNPOWERSHELL
</SetProperty>

Running the installer like this...

msiexec /i PowerShell-7.4.2-test-win-x64.msi ADD_FILE_CONTEXT_MENU_RUNPOWERSHELL=0

... causes the checkbox to be initially checked. So does:

• Running with ADD_FILE_CONTEXT_MENU_RUNPOWERSHELL=1.
• Having the registry value AddFileContextMenuRunPowerShell equal to 0.
• Having the registry value AddFileContextMenuRunPowerShell equal to 1.

That's unfortunate. I'm reaching out to a colleague who has done more Windows Installer UI, but it could be that the extra CAs are needed. It'd be nice to avoid, though. I'll flag this for follow up.

MSI, both in general and specifically for check boxes, uses the logic that a null string is false and anything else is true.

The selected state of the box sets the property either to the value specified in the Value column of the CheckBox table or to the initial value of the property specified in the Property table.

So this behavior seems consistent.

I wonder how the Integer flag is actually supposed to work then.

I'll re-review this, but might play around a bit with a scratch package. The number of CAs necessary to make this work seem like overkill, but maybe not. What you have certainly works.

I don't advise permanent components. This means users will have a hard time changing in the future, and leaves cruft behind in the registration. Perhaps it's better to change the MajorUpgrade element to use afterInstallExecute. Not only is it faster to upgrade, it will prefer existing components until the product is removed (not via upgrade).

@TravisEz13 this would need to be well-tested, though. The current behavior removes the old product first then installs the new product. This is inefficient, but safe for refactorings that might otherwise change component GUIDs. Doubt that's happened in a very long time, though - not since I did a bunch of preview vs. stable refactorings a long time ago. May not be worth retaining that behavior anymore.