对于我的Wix项目，我正在通过Visual studio的预构建事件收集4个目录，这将产生大约160mb的数据和大约220个文件，但构建过程需要很长时间。
我怎样才能加快这个过程？我有一个嵌入式媒体.cab文件，它将容纳所有文件。是文件的大小还是数量会减慢进程？还是在预构建事件中使用加热工具进行收获？使用HeatDirectory元素会更快吗？
有人在加速这一点方面取得了一些经验吗？
对我们来说，绝大多数时间都花在调用light上(对于链接阶段)。
light压缩机柜的速度非常慢。将.wixproj中的DefaultCompressionLevel从high更改为mszip(或low或none)有很大帮助。但是，我们的构建仍然太慢了。
事实证明，light独立处理机柜，默认情况下自动将它们链接到多个线程上。要利用这种并行性，您需要生成多个机柜。在我们的 .wxsProduct元素中，我们有以下内容将所有内容放在一个机柜中：
<MediaTemplate EmbedCab="yes" />
事实证明，您可以使用MaximumUncompressedMediaSize属性来声明您希望文件自动分片到不同.cab文件中的阈值(以 MB 为单位)：
<MediaTemplate EmbedCab="yes" MaximumUncompressedMediaSize="2" />
现在，即使压缩high，light也快得多，但对于增量构建(只有少数文件更改)来说仍然不够快。
回到 .wixproj，我们可以使用以下方法来设置文件柜缓存，这非常适合增量构建，其中文件更改很少，并且大多数文件柜不需要重新生成：
<CabinetCachePath>$(OutputPath)cabcache</CabinetCachePath>
<ReuseCabinetCache>True</ReuseCabinetCache>
抑制验证还可以提供很好的加速(轻.exe默认情况下花费大约三分之一的时间验证.msi)。我们为调试版本激活此功能：
<SuppressValidation>True</SuppressValidation>
通过这些更改，我们的最终(增量)构建从一分钟多到几秒钟，输出为 32 .msi MB，即使压缩级别high，完全重建也保持在一分钟以内。
WiX 帮助文件 ：如何：优化构建速度。换句话说：
1)Cabinet reuse和2)multi-threaded cab creation是WiX中的内置机制，用于加快构建速度。
硬件
：不可避免的"throw hardware at it".新的SSD和NVMe磁盘比旧的IDE驱动器快得多，因此您可能希望尝试将它们作为提高构建速度和安装速度的另一种方法。显然是的，但非常重要。它确实可以提高开发速度。看到这个答案。
NVMe 驱动器的挑战？
：1)它们运行得很热，2)它们通常容量(大小)有限，3)它们在笔记本电脑中使用时可能比旧的 2.5 英寸驱动器更容易受到攻击(我不确定 - 请记住，一些 NVMe 驱动器牢固地焊接在笔记本电脑的主板上)，4)如果您没有高质量的外部机箱(外形等)，数据救援可能会有点挑战性，5)据说 NVMe 驱动器会随着时间的推移而烧坏，6)它们仍然有些昂贵 - 尤其是容量较大的驱动器，并且肯定会有进一步的挑战 -但总的来说：这些驱动器很棒。
压缩 ：您可以尝试使用不同的压缩级别编译设置(例如，对于调试版本，无压缩级别)。无压缩使生成速度更快。以下是执行相反操作的插图，设置更高的压缩率(只需使用"无"而不是"高"即可达到您的目的)：
-
CompressionLevel： 微星是男男性行为者的两倍 -
MediaTemplate： 如何使用逆戟鲸减小 1GB MSI 文件的大小？
关于压缩的相关答案：MSI文件使用的压缩方法是什么？
单独 设置：如果您仍然压缩，您可以将先决条件和合并模块放在单独的设置中，以避免在每次构建时压缩它们(如果您在 Installshield 中使用发布标志，或者检查 Wix 中的预处理器功能)。
外部源文件：我想如果可以接受，您可以使用外部源文件 - 那么在构建过程中不会进行冗长的压缩操作，只需文件复制(速度越来越快 - 尤其是使用闪存驱动器)。
填充程序：另一种技术是将安装的所有文件填充为1 KB，前提是您正在测试的是设置本身及其 GUI 和自定义操作。然后，它只是设置的"shell" - 这是测试设置的新自定义操作的好方法。许多人为此编写了工具，但我没有为您提供链接。总有 github.com 需要搜索。
发布标志：节省时间的另一种方法是使用特殊的发行标志(仅限 Installshield)来编译您当前正在处理的安装程序的较小版本(省略许多功能)。WiX 通过其预处理器具有类似的可能性。更多关于 WiX 预处理器的实际应用。
调试版本：我通常使用这些技术的组合来制作调试版本。
- 当我试验和添加新功能时，我通常会使用外部源文件，并一直不断重建和安装安装程序。 发布标志仅
- 编译部分设置，机柜重用和发布标志相结合可以节省大量时间，具体取决于设置的大小、文件数量和硬件配置。
- 在我看来，也许最有效的是单独的设置(前提是它是稳定的并且不经常更改)。但要注意：Wix安装多个应用程序(拆分设置时涉及的问题)。
我的看法是：选择仅先决条件的单独设置。这也适用于大规模部署方案，在这些方案中，企业用户希望使用自己的标准化先决条件，并且对大型设置中的大量嵌入式"垃圾"感到恼火。大公司的大量包准备时间都花在了过时的运行时和先决条件上。还可以提供对这些先决条件的更新，而无需重新生成整个设置。良好的解耦性。
<小时 />友情链接：
- 如何加快 MSI 软件包的安装和卸载速度？
简单地说，不要收集文件。 请参阅我的博客文章：处理大量文件
第三个缺点是你的构建需要更长的时间 执行，因为它不仅创建您的包，而且还 创作和验证组件定义。
我在CodePlex上维护着一个名为IsWiX的开源项目。它包含项目模板(脚手架)和图形设计器，以帮助您设置和维护WiX源。 也就是说，它是围绕合并模块设计的，这减慢了构建速度，因为.必须构建 MSM，然后将其合并到.MSI中。 如果你真的关心纯速度，纯片段会更快。 也就是说，我有很多大约 160mb 的安装程序，而且根本不需要很长时间。
当然，不要忘记拥有一台快速构建的机器。 CPU、RAM 和 SSD 磁盘 I/O 都有助于快速生成 MSI。对于我的咨询，我使用Microsoft Visual Studio Online(VSO)。 我有一个Core i7-2600k Hyper-V服务器，具有32GB的内存和三星850evo SSD。我的生成服务器 (VM) 运行用于本地 SCC 缓存的 TFS 代理服务器。
为了好玩，在上面的机器上，我从我的 system32 文件夹中获取了 220 个文件，总计 160MB。 构建 MSM 需要 30 秒，构建 MSI 总共需要 30 秒，总共需要 60 秒。 这对我来说"足够快"。 我希望仅使用片段创作的 MSI 需要 30 秒。