AppSearch has sequence number 50 - right?

This doesn't feel like a good question, but please bear with me for a moment.

To put it into perspective, I am using Remember Pattern to save CMD line input property values, and have encountered an issue to schedule my 25+ custom actions to save CMD line supplied properties before AppSearch, as Remember Pattern rely on CMD supplied property values saved before AppSearch. The error message I got looks like this:

error LGHT0179: The InstallUISequence table contains an action 'SaveCmdLine_SERV ICE_ACCOUNT' which cannot have a unique sequence number because it is scheduled before or after action 'AppSearch'. There is not enough room before or after this action to assign a unique sequence number. Please schedule one of the actions differently so that it will be in a position with more sequence numbers available. Plea se note that sequence numbers must be an integer in the range 1 - 32767 (inclusive).

Upon inspection MSI compiled using Orca, the Sequence for AppSearch is 50. It's hard to find documentation about MSI Sequence table if anything at all, but according to link from this SO quesion, AppSearch should have a Sequence of 400. The workaround I am using is to shift AppSearch to a larger sequence number upon inspection of the generate MSI using Orca. Which seems Ok.

But 50 is quite a low number, why it is set to 50 instead of 400? Is it controlled by Windows Installer API or Wix?

Update: After update AppSearch to sequence 400, I encounter an issue where using the following code using bootstrap to require .Net 4.5 will fail.

  <Chain>
  <PackageGroupRef Id="NetFx451Redist" />
  <MsiPackage Name="$(var.OutputName).msi" SourceFile="MyInstaller.msi" DisplayInternalUI="yes" />
</Chain>

Upon inspection, look like I have to schedule LaunchConditions from sequence number 100 to sequence number 600 so that it still happens after AppSearch, so that the check .Net framework pre-request still working. I guess that's probably (one of) the reason why AppSearch was scheduled so early by WiX.

WiX Default Standard Action Sequence Numbers: I suspect - without being able to confirm it for sure - that WiX uses the following XML file (actions.xml) to define the default standard action sequence numbering): https://github.com/wixtoolset/wix3/blob/develop/src/tools/wix/Data/actions.xml (this is the WiX source stored on github.com).

Extract: Inlining the content you specifically asked for:

<actions xmlns="http://schemas.microsoft.com/wix/2003/04/actions">
  <..>
    <action name="AppSearch" sequence="50" InstallExecuteSequence="yes" InstallUISequence="yes" />
  <..>
</actions>

Answer: So I think the answer is that WiX defines the order of most standard actions in this source file (actions.xml). The order does not have anything to do with the MSI API outright - but only a few other configurations would make sense or be allowed. Hence the MSI API impose the restrictions that apply. These standard actions must relate to each other in a standard order - with some leeway.

Exceptions: The standard action RemoveExistingProducts can be moved to a few different locations - as an example of the "leeway". That particular standard action is missing from the above (actions.xml) file - and probably for that reason: it has no fixed, default positioning. It has (at least) 3 configurable ones. I would assume it is handled dynamically deep in the linker code (light.exe).

Roll Your Own?: I believe it is not impossible to compile your own WiX binaries with a different standard action sequence number default scheme, but compiling WiX is no small task.

WiX 4: Note that in WiX 4 the corresponding source file appears to be at: https://github.com/wixtoolset/wix4/blob/develop/src/libs/WixToolset.Data/Data/actions.xml

From the MSI SDK:

The restrictions on standard action sequencing are described in the links below. It appears AppSearch sequencing is unrestricted - third link below):