使用 MSBuild 将使用 WiX 的任何 CPU 构建部署到 x86答案

【问题标题】：Deploy Any CPU build with WiX to x86 using MSBuild使用 MSBuild 将使用 WiX 的任何 CPU 构建部署到 x86
【发布时间】：2015-08-15 08:54:04
【问题描述】：

我有一套解决方案可以构建完整的 .NET Any CPU 应用程序。我有一个 WiX 项目，它将将该应用程序部署为 x86，我可以在 Visual Studio 2013 中手动运行这一切，没有任何问题。现在我正试图让它在 MSBuild / TFS 中工作。冲突是我需要为代码指定任何 CPU，为 WiX 指定 x86。我最初的想法是将 WiX 解决方案 / 项目破解为名义上的任何 CPU，但让它实际上制作一个 x86 MSI。但是，wixproj 设置不允许使用任何 CPU。我希望任何 CPU 和 64 位安装程序都会出现同样的问题。 WiX 似乎下定决心不允许任何 CPU。

我在这里看到的其余选项是不使用 MSBuild 构建 WiX 部分，而是在构建后的批处理文件中处理它。然而，看起来你应该能够使用 WiX 部署任何 CPU 代码。

【问题讨论】：

标签： visual-studio-2013 tfs msbuild wix

【解决方案1】：

只需告诉它构建任何 CPU 和 x86 平台，它就会根据需要构建或跳过项目。它应该工作得很好。您会在构建日志中看到类似平台无效跳过的消息，如果您不希望这样，只需在每个解决方案中创建缺少的平台并将项目配置为不为其构建。

【讨论】：

是的，这很有效，但@Petrik 的答案更清晰。我确实找到了一个旧的解决方案，它在我清理的配置中有一些废话。
还有一个叫做“混合平台”的平台。这实际上比构建“任何 CPU”更干净，然后让它构建一个 x86 的项目平台。我试图解释这个问题，而不是提出一个具体的答案，因为每个人的构建需求都不同。在这种情况下，我个人喜欢创建名为“Application”和“Installer”的平台以及 TFS 归档清理器。

【解决方案2】：

您可以使用额外的 MSBuild 步骤创建自定义 xaml 构建模板，以便在主构建之后构建您的设置项目。我将此技术与三个不同的 MSBuild 构建步骤一起使用：

在其他 MSBuild 步骤中，您可以对解决方案名称进行硬编码，如果您只构建一个产品，这可能是合适的。如果您想要更大的灵活性，您可以重新安排构建过程参数并将它们提供给 MSBuild 步骤。团队构建流程编辑器将自动选择新的流程参数布局：

有关自定义构建模板的一般指南，请参阅 https://msdn.microsoft.com/en-us/library/dd647551.aspx。与早期版本相比，TFS Build 2013 中的构建模板更易于遵循和修改。

【讨论】：

我已经提出了这个想法，但希望我不需要弄乱构建模板。 @Petrik 的回答是我需要的技巧。
@约翰。我曾经在团队构建 2012 中使用 Petrik 的技术，但在将新项目添加到解决方案时总是被抓到，因为我忘记调整构建配置。自从采用自定义模板路线后，我发现解决方案更易于维护。

【解决方案3】：

似乎 WiX 项目使用平台配置来确定它们正在构建的模式，因此它们只允许 x86 或 x64 平台配置。因此，无法在“任何 CPU”平台配置中构建 WiX 项目，因为该平台不存在。

在 32 位（或 64 位）中构建 WiX 项目的最简单选择是设置一个同时包含 .NET 项目和 WiX 项目的解决方案，如下图所示。第一个矩形中的项目是 C# 项目，第二个矩形中有 WiX 项目。

然后为此解决方案设置一个或多个解决方案配置，将 .NET 项目设置为“任何 CPU”，将 WiX 项目设置为 x86（或 x64 用于 64 位安装程序）。比如这样：

如果您想要同时拥有 32 位和 64 位安装程序，那么我建议您进行 x86 解决方案配置和 x64 解决方案配置。将您的 .NET 项目设置为在“任何 CPU”配置或相应的位数（x86 或 x64）中构建，并将 WiX 项目设置为构建正确的位数（x86 用于 32 位安装程序，x64 用于 64-位安装程序）。

请注意，无论哪种情况，您都需要确保安装程序项目从编译器放置二进制文件的位置选择二进制文件。

然后设置您的 TFS 构建定义以使用您创建的解决方案配置构建此解决方案。如下图所示

然后，TFS 将使用正确的解决方案配置构建您的解决方案，这应该在各自正确的配置中构建您的 .NET 项目和 WiX 项目。

【讨论】：

谢谢，这就是我错过的技巧。这里的重点是解决方案配置/平台和个别项目平台设置不需要匹配。正如您所说，我将 Any CPU|Release 从 MSBuild 传递给解决方案，然后解决方案使用自己的值遍历项目。在这种情况下，x86|部署。在我的场景中，我有一堆解决方案都设置为 AnyCPU，现在是 WiX 的单一解决方案，解决方案配置为 AnyCPU|Release，它包含项目 x86|Release。
FWIW，我不建议将安装程序和应用程序项目放在同一个解决方案中。当开发人员准备迁移到下一个 Visual Studio 但 WiX 或 InstallShield 或其他尚不支持它时，我已经看到了太多的痛苦。最好将其与 IMO 解耦。
@ChristopherPainter 这似乎很公平。在工作中我们只会考虑不升级到下一个 VS 的原因之一。就像我们不能同时升级每个人并且其他依赖项不可用一样。一般来说，我们已经等了至少一年的 VS 版本，我们可以再等一段时间。将安装程序和应用程序项目放在同一个解决方案中确实意味着开发人员可以快速获得有关他们是否破坏了安装程序的反馈。
我还看到了一些关于应用程序与安装程序代码的政治问题，以及谁能触及什么。虽然这是个案，但讨论非常微妙。
最终原因.... WiX 项目通常是最后一个要构建的项目，它需要大量明确的项目依赖关系才能确保是这种情况。错过他们，订单错误导致构建损坏。将 WiX 放入它自己的解决方案可以解决这个问题，并且不会因为每次都构建安装程序而减慢应用程序的构建速度。