加速WiX安装程序的构建过程

Question

对于我的Wix项目，我通过Visual Studio的预构建事件收集了4个目录，这将导致约160MB的数据和约220个文件，但构建过程非常耗时。如何加快此过程？我有一个嵌入式的media.cab文件，其中包含所有文件。是文件大小还是数量会减慢处理速度？或者是在预构建事件中使用热工具进行收集？使用HeatDirectory元素会更快吗？是否有人有加速此过程的经验？

- Postback

Answer 1

对我们而言，绝大部分时间都花在了调用light（用于链接阶段）上。

light在压缩cabinet时非常慢。将.wixproj中的DefaultCompressionLevel从high改为mszip（或low或none），可以很大程度上帮助加快构建速度。但是，我们的构建速度仍然太慢了。

事实证明，light独立处理cabinet，并默认通过多个线程进行链接。要利用这种并行性，您需要生成多个cabinet。在我们的.wxs Product元素中，我们有以下内容将所有内容放在单个cabinet中：

<MediaTemplate EmbedCab="yes" />

原来您可以使用MaximumUncompressedMediaSize属性来声明文件自动分裂为不同的.cab文件的阈值（以MB为单位）:

<MediaTemplate EmbedCab="yes" MaximumUncompressedMediaSize="2" />

现在，即使使用高压缩率，light速度也更快了，但对于增量构建（只有少数文件发生更改）仍然不够快。

回到.wixproj文件中，我们可以使用以下方法设置一个cabinet缓存，这对于增量构建非常理想，因为只有少数文件更改，大多数cabinet不需要重新生成：

<CabinetCachePath>$(OutputPath)cabcache\</CabinetCachePath>
<ReuseCabinetCache>True</ReuseCabinetCache>

禁用验证还能提高速度（默认情况下，light.exe 要花费约三分之一的时间来验证 .msi）。我们会在调试版本中启用此功能：

<SuppressValidation>True</SuppressValidation>

通过这些改变，我们的最终（增量）构建时间从一分钟以上缩短到了几秒钟，对于一个32 MB的.msi输出文件，即使使用高压缩级别，完全重新构建的时间也保持在一分钟以下。

- Cameron

Answer 2

简单来说，不要收集文件。请参考我的博客文章：处理大量文件的方法

第三个缺点是，由于它不仅在创建软件包，还在编写和验证组件定义，因此您的构建时间将非常长。

我在CodePlex上维护一个开源项目，名为IsWiX。它包含项目模板（脚手架）和图形化设计工具，帮助您设置和维护WiX源代码。话虽如此，它是基于合并模块设计的，这会使构建速度有所下降，因为必须先构建.MSM，然后再将其合并到.MSI中。如果您真的关心纯速度，那么使用纯碎片会更快。话虽如此，我有许多安装程序大小约为160mb，但用时很短。

当然，别忘了拥有一台快速的构建机器。 CPU、RAM和SSD磁盘I/O都有助于快速生成MSIs。在我的咨询中，我使用Microsoft Visual Studio Online (VSO)。我有一台Core i7-2600k Hyper-V服务器，配备32GB内存和三星850evo SSD。我的构建服务器（VM）运行TFS代理服务器，用于本地SCC缓存。

为了好玩，我从我的system32文件夹中选了220个文件，总计160MB。构建MSM花费了30秒钟，构建MSI花费了30秒钟，总共60秒钟。这对我来说已经足够快了。我期望仅使用片段编写的MSI需要30秒钟。

- Christopher Painter

---

我现在实际测量了速度。使用加热工具，我得到了102秒；禁用加热并只采取生成的文件时，时间大约为101秒，因此生成文件不是问题所在。那么问题出在预处理器变量上还是真的数据量太大？我的电脑不慢，而且我用的是I7-3770 @ 3.4GHz。 - Postback

病毒扫描器？你需要与我分享你的内容，以便我深入了解。在你的情况下，热度可能不会变慢，但我见过这种情况。特别是当你开始涉及COM收集时。 - Christopher Painter

Answer 3

WiX帮助文件：如何优化构建速度。换句话说：1) 柜子重用 和 2) 多线程制作柜子 是WiX中内置的机制，可加快构建速度。

---

硬件: 不可避免的 "扔硬件加速"。新的SSD和NVMe磁盘比旧的IDE驱动器快得多，因此您可能希望尝试它们作为改善构建速度和安装速度的另一种方式。显而易见，但非常重要。它确实可以提高开发速度。请参阅此答案。

挑战NVMe驱动器？：1）它们发热，2）它们通常容量有限（大小），3）当在笔记本电脑中使用时，它们可能比旧的2.5英寸驱动器更容易受到攻击（我不确定-请记住，某些NVMe驱动器已经焊接在笔记本电脑的主板上），4）如果您没有高质量的外部盒子（形式因素等等...），数据恢复可能会有一些挑战，5）据说随着时间的推移，NVMe驱动器会烧毁，6）它们仍然有点昂贵-特别是大容量的驱动器，并且肯定还有进一步的挑战-但总的来说：这些驱动器非常棒。

---

压缩：您可以尝试使用不同的压缩级别编译设置（例如，对于调试构建，使用none）。不压缩会使构建速度更快。这里有一些示例来进行相反的操作，设置更高的压缩级别（只需将“high”替换为“none”即可）：

• CompressionLevel：Msi two times larger than msm
• MediaTemplate：How can I reduce the size of a 1GB MSI file using Orca?

关于压缩的相关回答：MSI文件使用的压缩方法是什么？

单独设置：如果您仍然选择压缩，可以将前提条件和合并模块放在单独的安装包中，以避免为每个构建压缩它们（或者在Installshield中使用发布标志，或者在Wix中检查预处理器功能）。

外部源文件：我想如果这是可接受的，您可以使用外部源文件 - 然后在构建过程中不需要进行冗长的压缩操作，只需进行文件复制（特别是使用闪存驱动器会更快）。

Shim：另一种技术是将您安装的所有文件都“shim”为“1 KB”，如果您要测试的是设置本身及其GUI和自定义操作，则可以使用该技术。然后它只是一个设置的“外壳” - 这是测试新自定义操作的绝佳方式。许多人已经为此编写了工具，但我没有提供链接。总有github.com可供搜索。

发布标志：节省时间的另一种方法是使用特殊的“发布标志”（仅限Installshield），以编译当前正在进行的设置的较小版本（省略许多功能）。WiX通过其预处理器也具有类似的功能。更多WiX预处理器实际用途。

---

调试版本: 我通常使用这些技术的组合来制作一个调试版本。

• 当我尝试添加新功能时，我通常使用外部源文件，并不断重建和安装设置。
• 发布标志用于编译设置的部分内容，结合柜子重复使用和发布标志可以节省很多时间，具体取决于您的设置大小、文件数量和硬件配置。
• 在我看来，可能最有效的是一个单独的设置（前提是它是稳定的且不经常更改）。但要注意：Wix to Install multiple Applications （涉及拆分设置时的问题）。

我的看法: 选择仅先决条件的单独设置。这对于企业用户想要使用自己的标准化先决条件并对巨大设置中嵌入的“垃圾”感到恼火的大规模部署场景也很有用。大公司在包准备上花费了很多时间去除过时的运行时和先决条件。您还可以向这些先决条件提供更新而无需重新构建整个设置。良好的解耦。

---

链接：

• 如何加速MSI软件包的安装和卸载？

- Stein Åsmul

---

实际上，压缩级别基本上为我节省了一半的构建时间，但现在我有大约450MB而不是160MB。您所说的“外部源文件”是什么意思？ - Postback

“外部源文件”意味着这些文件被放置在编译后的MSI旁边的文件夹层次结构中，它们根本没有嵌入到cab中。这种构建形式最常用于安装DVD或CD-ROM，因为它可以使安装更快，无需解压缩要求，并且不需要制作单个文件以便轻松下载。源文件夹看起来类似于您的MSI的管理员安装（提取所有cab文件并创建网络安装点）。请参见此处的详细信息：管理员安装。 - Stein Åsmul

好奇，你设置了压缩级别为none吗？低性能如何？ - Stein Åsmul

是的，我已将其设置为“无”，然后得到了450MB的文件，但建立时间也减少了一半。 - Postback