AppSearch的序列号为50 - 对吧（） _序列

满堂花醉三千客，一剑霜寒十四州。这篇文章主要讲述AppSearch的序列号为50 - 对吧？相关的知识，希望能为你提供帮助。
这不是一个好问题，但请耐心等待一下。
【AppSearch的序列号为50 - 对吧（）】为了正确看待，我使用Remember Pattern来保存CMD行输入属性值，并且遇到了一个问题，即在AppSearch之前安排我的25多个自定义动作来保存CMD行提供的属性，因为Remember Pattern依赖于之前保存的CMD提供的属性值AppSearch。我得到的错误信息如下：

错误LGHT0179：InstallUISequence表包含一个动作'SaveCmdLine_SERV ICE_ACCOUNT'，它不能具有唯一的序列号，因为它是在动作'AppSearch'之前或之后安排的。在此操作之前或之后没有足够的空间来分配唯一的序列号。请以不同方式安排其中一个操作，以使其处于可用序列号更多的位置。请注意，序列号必须是1-32767（含）范围内的整数。

在使用Orca编译MSI时，AppSearch的序列为50.如果有任何内容，很难找到有关MSI Sequence表的文档，但根据this SO quesion的链接，AppSearch应该有400的序列。我使用的解决方法是在使用Orca检查生成MSI时，将AppSearch转移到更大的序列号。哪个好看。
但50是一个相当低的数字，为什么它设置为50而不是400？它是由Windows Installer API还是Wix控制的？
更新：将AppSearch更新为序列400后，我遇到一个问题，即使用以下代码使用bootstrap来要求.Net 4.5将失败。

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

在检查时，看起来我必须将LaunchConditions从序列号100安排到序列号600，以便它仍然在AppSearch之后发生，以便检查.Net框架预请求仍然有效。我想这可能是（其中之一）AppSearch被WiX如此早安排的原因之一。
答案WiX默认标准动作序列号：我怀疑 - 无法确认 -WiX使用以下XML文件（actions.xml）来定义默认的标准动作序列编号）：https://github.com/wixtoolset/wix3/blob/develop/src/tools/wix/Data/actions.xml（这是存储在github.com上的WiX源）。
提取：内联您特别要求的内容：

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

答：所以我认为答案是WiX定义了此源文件（actions.xml）中大多数标准操作的顺序。该命令与MSI API完全没有任何关系 - 但只有少数其他配置才有意义或被允许。因此，MSI API强加了适用的限制。这些标准行动必须以标准顺序相互关联 - 有一些余地。
例外：标准动作RemoveExistingProducts可以移动到几个不同的位置 - 作为“余地”的一个例子。上面（actions.xml）文件中缺少特定的标准操作 - 可能是因为这个原因：它没有固定的默认定位。它具有（至少）3个可配置的。我认为它是在链接器代码（light.exe）中动态处理的。
自己滚动？：我认为使用不同的标准动作序列号默认方案编译自己的WiX二进制文件并非不可能，但编译WiX并非易事。
WiX 4：请注意，在WiX 4中，相应的源文件似乎位于：https://github.com/wixtoolset/wix4/blob/develop/src/libs/WixToolset.Data/Data/actions.xml
从MSI SDK：
标准动作排序的限制在下面的链接中描述。看来AppSearch测序不受限制 - 下面的第三个链接）：