对于我的Wix项目，我正在通过visual studio的预构建事件收集4个目录，这将导致大约160mb的数据和大约220个文件，但构建过程花费了很长时间。
我如何加快这个过程？我有一个嵌入的 media.cab 文件，它将保存所有文件。文件的大小或数量会减慢进程吗？或者是在预制活动中使用加热工具进行收割？使用HeatDirectory元素会更快吗？
任何人都有加快速度的经验吗？
答案 0 :(得分：1)
简单地说，不要收集文件。请参阅我的博客文章：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内存的Core i7-2600k Hyper-V服务器和一台Samsung 850evo SSD。我的构建服务器（VM）运行TFS代理服务器以进行本地SCC缓存。
为了好玩，在上面的机器上，我从我的system32文件夹中获取了总共160MB的220个文件。构建MSM需要30秒，构建MSI需要30秒，总共60秒。这足够快＆＃39;为了我。我希望MSI只使用片段创作30秒。
答案 1 :(得分：1)
我认为您可以使用外部源文件（如果可以接受） - 那么您在构建过程中不会进行冗长的压缩操作，只需要一个文件副本（不断加快 - 特别是使用闪存驱动器。）
另一种技术是 shim 您安装的所有文件 1 KB ，如果您正在测试的是设置本身及其GUI和自定义操作。它只是一个＆＃34; shell＆＃34;设置 - 这是测试设置的新自定义操作的好方法。许多人已经为此编写了工具，但我没有为您提供链接。搜索总是github.com。
通过使自己成为调试版本的技术，您可以节省大量时间。我通常在实验和添加新功能时使用外部源文件，并不断重建和安装设置。这可以节省大量时间，具体取决于您的设置大小，文件数量和硬件配置。
另一种节省时间的方法是使用特殊的发布标志（仅限Installshield）来编译您当前正在处理的部分设置。 Wix通过其preprocessor具有类似的可能性。
如果您仍然进行压缩，则可以将先决条件和合并模块置于单独设置中，以避免为每次构建压缩它们（或如果您在Installshield中，请使用发布标志，或者检查Wix中的Preprocessor功能。）
最后，您可以尝试使用不同的compression level编译设置（例如 none 调试版）。
答案 2 :(得分：1)
对于我们来说，绝大多数时间都花在调用light上（用于链接阶段）。
light在压缩机柜时非常慢。将.wixproj中的DefaultCompressionLevel从high更改为mszip（或low或none）很有帮助。但是，我们的构建仍然太慢。
事实证明，light独立处理文件柜，默认情况下会自动在多个线程上链接它们。要利用这种并行性，您需要生成多个文件柜。在我们的.wxs Product元素中，我们将以下内容放置在单个机柜中：
<MediaTemplate EmbedCab="yes" />
事实证明，您可以使用MaximumUncompressedMediaSize属性声明阈值（以MB为单位），您希望在该阈值处将文件自动分片为不同的.cab文件：
<MediaTemplate EmbedCab="yes" MaximumUncompressedMediaSize="2" />
现在light的速度要快得多，即使使用high压缩也是如此，但是对于增量构建（仅更改少量文件）来说仍然不够快。
回到.wixproj，我们可以使用以下内容来设置文件柜缓存，这是增量构建的理想选择，增量构建中文件更改很少，不需要重新生成大多数文件柜：
<CabinetCachePath>$(OutputPath)cabcache\</CabinetCachePath>
<ReuseCabinetCache>True</ReuseCabinetCache>
有了这些更改，对于32 MB .msi输出，我们的最终（增量）构建从一分多钟缩短到了几秒钟，并且即使在压缩级别为high的情况下，完全重建也可以在一分钟之内完成。