对于我的 Wix 项目，我通过 Visual Studio 的预构建事件收集了 4 个目录，这将产生大约 160mb 的数据和大约 220 个文件，但构建过程需要很长时间。
我怎样才能加快这个过程？我有一个嵌入的 media.cab 文件，它将保存所有文件。是文件的大小或数量会减慢进程吗？还是在预建活动中使用加热工具进行收获？使用 HeatDirectory 元素会更快吗？
有人在加快这方面取得了一些经验吗？
【问题讨论】：
标签： visual-studio wix windows-installer installation heat
WiX 帮助文件：How To: Optimize build speed。换句话说：
1)Cabinet reuse和2)multi-threaded cab creation是内置机制在 WiX 中以加快构建速度。
硬件：不可避免的"throw hardware at it"。新的 SSD 和 NVMe 磁盘比旧的 IDE 驱动器快得多，您可能想尝试使用它们作为另一种提高构建速度和安装速度的方法。显然是的，但非常重要。它确实可以提高开发速度。 See this answer.
NVMe 驱动器面临挑战？：1) 它们运行很热，2) 它们通常有容量（大小）有限，3) 在笔记本电脑上使用时，它们可能比旧的 2.5 英寸驱动器更容易受到攻击（我不确定 - 请记住，某些 NVMe 驱动器是焊接在主板上的笔记本电脑），4) 如果您没有优质的外壳（外形等...），数据救援可能会有点挑战性，5) NVMe据说驱动器会随着时间的流逝而烧毁，6)它们仍然有点贵 - 尤其是容量更大的驱动器，而且肯定还有进一步的挑战 - 但总的来说：这些驱动器很棒。
压缩：您可以尝试使用不同的 compression level 编译您的设置（例如 none 用于 debug构建）。没有压缩使构建更快。以下是相反的说明，设置更高的压缩率（只是使用 none 代替 high 来达到您的目的）：
CompressionLevel：Msi two times larger than msm
MediaTemplate：How can I reduce the size of a 1GB MSI file using Orca?
关于压缩的相关答案：What is the compression method used by MSI files?
单独设置：如果您仍然进行压缩，您可以将 先决条件 和 合并模块 放在 单独设置以避免在每次构建时都压缩它们（或者如果您在 Installshield 中使用发布标志，或者检查 Wix 中的 Preprocessor 功能）。
外部源文件：我想你可以使用外部源文件如果这是可以接受的 - 那么你没有冗长的压缩操作在构建过程中发生，只是一个文件副本（速度越来越快 - 尤其是使用闪存驱动器）。
Shim：另一种技术是 shim 您安装的所有文件为 1 KB正在测试的是设置本身及其 GUI 和自定义操作。然后它只是设置的“外壳” - 这是测试设置的新自定义操作的好方法。许多人为此编写了工具，但我没有给你的链接。总有github.com 可以搜索。
发布标志：另一种节省时间的方法是使用特殊的发布标志（仅限 Installshield）来编译您安装的较小版本目前正在开发中（省略了许多功能）。 WiX 通过其preprocessor 具有类似的可能性。更多关于WiX preprocessor practical use。
调试构建：我通常结合使用这些技术来进行调试构建。
我的看法：进行仅先决条件的单独设置。这也适用于大规模部署场景，在这些场景中，企业用户希望使用自己的标准化先决条件，并且对大型设置中的大量嵌入式“垃圾”感到恼火。大公司的大量包准备时间都花在了淘汰过时的运行时和先决条件上。您还可以在不重建整个设置的情况下提供这些先决条件的更新。良好的解耦。
链接：
【讨论】：
对我们来说，大部分时间都花在调用 light（用于链接阶段）上。
light 压缩箱体的速度非常慢。将.wixproj 中的DefaultCompressionLevel 从high 更改为mszip（或low 或none）有很大帮助。但是，我们的构建仍然太慢了。
原来light独立处理cabinet，默认自动链接到多个线程。要利用这种并行性，您需要生成多个机柜。在我们的 .wxs Product 元素中，我们有以下内容将所有内容放在一个柜子中：
<MediaTemplate EmbedCab="yes" />
事实证明，您可以使用MaximumUncompressedMediaSize 属性来声明您希望文件自动分片到不同 .cab 文件的阈值（以 MB 为单位）：
<MediaTemplate EmbedCab="yes" MaximumUncompressedMediaSize="2" />
现在light 更快了，即使使用high 压缩，但对于增量构建（只有少数文件更改）仍然不够快。
回到 .wixproj 中，我们可以使用以下内容来设置文件柜缓存，这对于文件更改较少且大多数文件柜不需要重新生成的增量构建来说非常理想：
<CabinetCachePath>$(OutputPath)cabcache\</CabinetCachePath>
<ReuseCabinetCache>True</ReuseCabinetCache>
抑制验证也提供了很好的加速（默认情况下，light.exe 花费了大约三分之一的时间来验证 .msi）。我们为调试版本激活它：
<SuppressValidation>True</SuppressValidation>
通过这些更改，对于 32 MB 的 .msi 输出，我们的最终（增量）构建从一分钟多到几秒，即使使用 high 压缩级别，完全重建也保持不到一分钟。
【讨论】：
简单地说，不要收集文件。请看我的博文：Dealing with very large number of files
第三个缺点是您的构建将需要更长的时间 执行，因为它不仅是创建你的包，而且它也是 创作和验证您的组件定义。
我在 CodePlex 上维护了一个名为 IsWiX 的开源项目。它包含项目模板（脚手架）和图形设计器，可帮助您设置和维护 WiX 源。也就是说，它是围绕合并模块设计的，这会稍微减慢构建速度，因为必须构建 .MSM 然后将其合并到 .MSI 中。如果您真的关心纯速度，纯片段会更快。也就是说，我有很多安装程序，大约 160mb，而且根本不需要很长时间。
当然不要忘记拥有一台快速构建机器。 CPU、RAM 和 SSD 磁盘 I/O 都有助于快速生成 MSI。对于我的咨询，我使用 Microsoft Visual Studio Online (VSO)。我有一个带有 32GB 内存和三星 850evo SSD 的 Core i7-2600k Hyper-V 服务器。我的构建服务器 (VM) 为本地 SCC 缓存运行 TFS 代理服务器。
为了好玩，在上面的机器上，我从我的 system32 文件夹中取出了 220 个文件，总计 160MB。构建 MSM 需要 30 秒，构建 MSI 需要 30 秒，总共需要 60 秒。这对我来说“足够快”。我预计仅使用片段创作的 MSI 需要 30 秒。
【讨论】：