AppSearch 的序列号为 50 - 对吧? [英] AppSearch has sequence number 50 - right?
问题描述
这不是一个好问题，但请稍等片刻.
This doesn't feel like a good question, but please bear with me for a moment.
为了正确看待它，我使用的是 Remember Pattern 来保存 CMD 行输入属性值，并且遇到了一个问题来安排我的 25 多个自定义操作以在 AppSearch 之前保存 CMD 行提供的属性，因为记住模式依赖于 CMD 提供的属性值保存在 AppSearch 之前.我收到的错误消息如下所示:
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:
错误 LGHT0179:InstallUISequence 表包含一个操作'SaveCmdLine_SERV ICE_ACCOUNT' 不能有唯一的序列编号，因为它安排在操作AppSearch"之前或之后.在此操作之前或之后没有足够的空间来分配唯一的序列号.请安排其中一项操作以不同的方式，使其处于具有更多序列的位置可用的号码.请注意，序列号必须是1 - 32767(含)范围内的整数.
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).
在检查使用 Orca 编译的 MSI 时，AppSearch 的序列为 50.如果有的话，很难找到有关 MSI 序列表的文档，但根据来自 这个 SO 问题，AppSearch 应该有一个 400 的序列.我的解决方法使用是在使用 Orca 检查生成的 MSI 时将 AppSearch 转移到更大的序列号.看起来不错.
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.
但是 50 是一个很低的数字，为什么设置为 50 而不是 400?它是由 Windows Installer API 还是 Wix 控制的?
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?
更新: 将 AppSearch 更新到序列 400 后，我遇到了一个问题，即使用以下代码使用引导程序要求 .Net 4.5 将失败.
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>
经检查，看起来我必须将 LaunchConditions 从序列号 100 安排到序列号 600 以便它仍然在 AppSearch 之后发生，以便检查 .Net 框架预请求仍然有效.我想这可能是 WiX 这么早就安排了 AppSearch 的原因之一.
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 默认标准操作序列号:我怀疑 - 无法确定 -WiX 使用以下 XML 文件 (actions.xml) 来定义默认的标准操作序列编号):https://github.com/wixtoolset/wix3/blob/develop/src/tools/wix/Data/actions.xml(这是存储在 github.com 上的 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>
答案:所以我认为答案是 WiX 定义了这个源文件(actions.xml).该命令与 MSI API 完全没有任何关系 - 但只有少数其他配置有意义或被允许.因此，MSI API 施加了适用的限制.这些标准动作必须以标准顺序相互关联——有一定的余地.
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.
例外情况:标准操作 RemoveExistingProducts 可以移动到几个不同的位置 - 作为余地"的示例.上述 (actions.xml) 文件中缺少该特定标准操作 - 可能是因为:它没有固定的默认定位.它有(至少)3 个可配置的.我假设它在链接器代码 (light.exe) 的深处动态处理.
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?:我相信用不同的标准动作序列号默认方案编译你自己的 WiX 二进制文件并非不可能，但编译 WiX 并不小任务.
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:请注意，在 WiX 4 中，相应的源文件似乎位于:https://github.com/wixtoolset/wix4/blob/develop/src/libs/WixToolset.Data/数据/actions.xml
来自 MSI SDK:
以下链接中描述了标准动作顺序的限制.AppSearch 排序似乎不受限制 - 下面的第三个链接):
The restrictions on standard action sequencing are described in the links below. It appears AppSearch sequencing is unrestricted - third link below):
这篇关于AppSearch 的序列号为 50 - 对吧?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
