`candle` 命令行上的 `-arch` 参数到底有什么作用？答案

【问题标题】：What exactly does the `-arch` argument on the `candle` command line do?`candle` 命令行上的 `-arch` 参数到底有什么作用？
【发布时间】：2013-05-15 15:16:42
【问题描述】：

我在 WiX 3.7 版中设置了 32 位和 64 位版本。 WiX 文档在充分解释这一点方面存在缺陷。在documentation for Package/@Platform 中，它说“不鼓励使用此属性；相反，请在candle.exe 命令行中指定-arch 开关”，但没有解释此参数的实际作用（至少我找不到）。 "documentation" for the compiler 完全值得在“文档”一词周围加上引号，因为它基本上是一个存根（例如，与 linker documentation 不同）。对于历史记录，这是编译器文档的全部内容：

candle.exe 公开了 Windows Installer XML 编译器。蜡烛是负责将输入的 .wxs 文件预处理为有效的针对 WiX 模式 wix.xsd 的格式良好的 XML 文档。那么，每个后处理的源文件编译成 .wixobj 文件。

编译过程相对简单。 WiX 架构适合于一个简单的递归下降解析器。编译器依次处理每个元素创建新符号，计算必要的引用并为 .wixobj 文件生成原始数据。

命令行帮助提供了一些，但还不够。

-arch      set architecture defaults for package, components, etc.
           values: x86, x64, or ia64 (default: x86)

在一个相关的问题Platform identification in WiX 3.0 中，one answer with a sliver of hint 关于可能发生的事情，但这还不够，我不知道它是否准确。

-arch 参数是否与设置Package/@Platform 属性具有相同的效果，还是作用更多？
该参数是否会影响preprocessor 中可用的任何内容？特别是，它是否设置了PLATFORM 预处理器变量？它还有其他设置吗？
什么是架构“默认”？显式 Package/@Platform 属性是否会覆盖命令行？或相反亦然？或者（更好的是）如果平台声明不一致，是否会出现错误？

其中一些问题的答案似乎应该是显而易见的，而且我确实在编写问题时学到了一些东西。但我想要一个明确的答案，最好（提示）一个指向candle 命令行的更新且准确的文档页面的链接。但是，我确实希望在有人回答时已经解决了这个问题，但是我会尽快节省其他人我花时间解决这个问题的时间。

另一个相关问题WIX: is the Platform attribute of the Package element truly deprecated? 讨论了Package/@Platform 属性，但没有解决命令行参数。

关于 PLATFORM 预处理器变量。现在显然是BUILDARCH，尽管您很难从文档中知道它。

warning CNDL1034 : The built-in preprocessor variable '$(sys.PLATFORM)' is 
deprecated. Please correct your authoring to use the new '$(sys.BUILDARCH)' 
preprocessor variable instead.

【问题讨论】：

标签： wix

【解决方案1】：

以下代码 sn-ps 启用了 32 位和 64 位版本之间的编译时配置，而无需引入代表平台的用户变量，而是使用系统提供的用户变量。这两个定义的变量对于普通安装都是通用的。 64 位系统的最低版本更高。 32 位和 64 位版本的基本程序文件目录不同。

<?if $(sys.BUILDARCH)="x86"?>
    <?define Minimum_Version="100"?>
    <?define Program_Files="ProgramFilesFolder"?>
<?elseif $(sys.BUILDARCH)="x64"?>
    <?define Minimum_Version="200"?>
    <?define Program_Files="ProgramFiles64Folder"?>
<?else?>
    <?error Unsupported value of sys.BUILDARCH=$(sys.BUILDARCH)?>
<?endif?>

稍后在 WiX 源代码中使用这些定义。

<Package [...]
    InstallerVersion="$(var.Minimum_Version)"
/>

<Directory Id="$(var.Program_Files)">
    [...]
</Directory>

【讨论】：

跨多个 SO 和博客文章的最佳答案。

【解决方案2】：

部分答案：

-arch 参数确实设置了 sys.BUILDARCH 变量以及 sys.PLATFORM 一个。
-arch 参数以静默方式覆盖属性Package/@Platform。至少看起来，如果看sys.BUILDARCH 就足够了。
- 因此命令行帮助是错误的。这是一个覆盖，而不是默认值。

【讨论】：

如果您在 Visual Studio 中构建 WiX 安装程序，如何将 -arch 开关设置为 x64？
@Jammer -arch 开关在编译后在candle 的命令行上设置；它不参与构建该编译器。如果您问是否有办法将 -arch x64 设为此类二进制文件的默认值，我不知道答案。
啊，我确实解决了这个问题。如果您在.wixproj 文件中将PlatformInstaller 属性设置为x64，则candle 的命令行将包含-arch x64 开关。
如果使用candle -arch 以两种不同的方式构建相同的产品定义，它对产品代码和升级代码有何影响？
@Wayne 我认为默认情况下它不会影响这两者中的任何一个。如果您构建它的两种方式足够不同，您可能应该为不同的构建使用不同的产品和升级代码。

【解决方案3】：

除了定义 MSI 的体系结构（Package/@Platform）之外，它还为 MSI 中的 msidbComponentAttributes64bit 属性（WiX 中的 Win64）设置了默认组件表值。

IE。如果 sys.BUILDARCH = x86 则未设置，如果 x64 则已设置 (+256)。这在 WIX.chm 中没有提到，它只是重新迭代 MSI.chm 关于上述属性

将此属性设置为“是”以将其标记为 64 位零件。该属性便于安装包包括 32 位和 64 位组件。如果这个位不是设置，组件注册为 32 位组件。** 如果这是 64 位组件替换 32 位组件，设置该位并分配 Guid 属性中的新 GUID。

（所以不告诉你）：使用 BUILDARCH 时，您只需要在想要覆盖默认值时编写 Win64 WiX 属性，这在从相同的 WiX 代码构建不同的拱 MSI 时很有帮助。在此之前，我在每个组件上为 Win64 属性使用环境变量。

【讨论】：