WiX is an open source project sponsored by Microsoft that exposes its operating system installer functionality via XML elements. The nuances of this declarative technology and inconsistent syntax have given birth to an entire classification of engineers in the software industry called deployment engineers.  These engineers are frequently tasked with packaging and distributing executable binaries for various versions of the Windows platform. All things considered WiX has matured nicely and is becoming quite powerful. That said it can be a real pain to start using if you’re a novice due to the lack of syntax consistency and plethora of contradictory information on the topic. Not to mention ensuring platform compatibility is nearly impossible given that most people don’t have a copy of every version of Windows ever released… and yes, the installer functionality changed with every version too That said, this post is intended to add to the developer WiX ‘entropy’.

Every book I’ve skimmed through and blog post I’ve read on WiX custom action sequencing is right in ‘theory’ but not always correct in practice… Through trial and error efforts along with the help of my Chief Architect we determined that WiX custom action sequencing is fairly arbitrary and to ensure consistent functionality the action should be schedule after what appears to be an undocumented sequence.

What books and other blogs say to do:

<CustomAction Id="RegisterSomething"
              Directory="INSTALLDIR"
              ExeCommand='regsvr32.exe /s "[INSTALLDIR]something.dll"'
              Return="check">
</CustomAction>

<InstallExecuteSequence>
            <Custom Action="RegisterSomething"
                    After="InstallFinalize">NOT Installed</Custom>
</InstallExecuteSequence>

What you should consider doing instead is:

<InstallExecuteSequence>
            <Custom Action="RegisterSomething"
                    After="RemoveExistingProducts">NOT Installed</Custom>
</InstallExecuteSequence>

Why? Most operations deployment engineers will want to perform during install time will require administrator (“elevated”) privileges. Which means if the Windows user is using UAC it will only run elevated if executed prior to the ‘InstallFinalize’ sequence, not after. Simply changing the original line above from ‘After’ to ‘Before’ will not work consistently either. This is because the sequencing is arbitrary. Meaning that it’s possible for your custom actions to be schedule to run before the ‘InstallExecute’ sequence… because it’s technically ‘Before’ ‘InstallFinalize’ In this case you’ll be running custom actions on binaries and runtimes that haven’t been committed to the system yet.