加快WiX安装程序的构建过程 [英] Speed up Build-Process of WiX-Installer

问题描述

对于我的Wix项目，我通过Visual Studio的预构建事件收获了4个目录，这将导致大约160mb的数据和大约220个文件，但是构建过程花费了很长时间.

For my Wix project I am harvesting 4 directories, via the pre-build-event of visual studio, which will result in about 160mb of data, and about 220 files, but the build process tooks very long.

我如何加快该过程?我有一个嵌入式的 media.cab 文件，该文件可以保存所有文件.是文件的大小或数量会减慢该过程的速度吗?还是在预建活动中使用加热工具进行收割? HeatDirectory元素会更快吗?

How can i speed that process up? I have one embedded media.cab file which will hold all the files. Is it the size or the amount of files that will slow the process down? Or is it the harvesting with the heat tool in the pre-build-event? Would it be faster with the HeatDirectory element?

有人在加快速度方面有一些经验吗?

Anyone made some experience with speeding this up?

推荐答案

WiX帮助文件 : 如何:优化构建速度 .换句话说: 1) Cabinet reuse 和 2) multi-threaded cab creation 是内置机制在WiX中加快构建速度.

WiX Help File: How To: Optimize build speed. In other words: 1) Cabinet reuse and 2) multi-threaded cab creation are built-in mechanisms in WiX to speed up builds.

---

压缩 :您可以尝试使用其他

---

Compression: You can try to compile your setup with a different compression level (for example none for debug builds). No compression makes builds faster. Here are illustrations for doing the opposite, setting higher compression (just use none instead of high for your purpose):

• CompressionLevel : Msi两个比msm大一倍
• MediaTemplate :

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

有关压缩的答案:什么是MSI文件使用的压缩方法吗?

单独的设置 :如果仍然压缩，则可以将先决条件和合并模块放在单独的设置，以避免为每个版本压缩它们(或者，如果您在Installshield中，请使用发布标志，或者检查

Separate Setup: If you still go compressed, you could put prerequisites and merge modules in a separate setup to avoid compressing them for every build (or use release flags if you are in Installshield, or check the Preprocessor features in Wix).

外部源文件 :我想如果可以接受的话，您可以使用外部源文件-那么您无需进行冗长的压缩操作在构建过程中发生，只是一个文件副本(它会越来越快-尤其是闪存驱动器).

External Source Files: I suppose you could use external source files if that's acceptable - then you don't have a lengthy compression operation taking place during the build, just a file copy (which keeps getting faster - especially with flash drives).

填充 :另一种方法是填充所有安装的文件，如果您安装的文件为 1 KB 正在测试的是安装程序本身及其GUI和自定义操作.然后，它只是安装程序的外壳"-这是测试安装程序新自定义操作的好方法.许多人为此编写了工具，但是我没有链接适合您.总是有 github.com 进行搜索.

Shim: Another technique is to shim all the files you install to be 1 KB if what you are testing is the setup itself and its GUI and custom actions. It is then just a "shell" of a setup - which is a great way to test new custom actions to your setup. Many have written tools for this, but I don't have a link for you. There is always github.com to search.

释放标志 :另一种节省时间的方法是使用特殊的释放标志(仅Installshield)来编译您设置的较小版本目前正在开发中(遗漏了许多功能). WiX通过其预处理器也具有类似的可能性.有关 WiX预处理器实际使用的更多信息.

Release Flags: Another way to save time is to use special release flags (Installshield only) to compile smaller versions of the setup you are working on at the moment (leaving out many features). WiX has similar possibilities via its preprocessor. More on WiX preprocessor practical use.

调试版本 :我通常结合使用这些技术来构建调试版本.

• 我通常在进行实验和添加新功能时会使用外部源文件，并始终保持重建和安装设置.
• 释放标志仅用于编译部分设置，机柜重用和释放标志结合起来可以节省大量时间，具体取决于设置的大小，文件数和硬件配置.
• 在我看来，也许最有效的方法是单独设置(前提是它稳定且不经常更改).不过请当心:要安装多个应用程序的向导(当它安装时涉及的问题来分割设置).

• I normally use external source files when I experiment and add new features and keep rebuilding and installing the setup all the time.
• Release flags to compile only part of the setup, cabinet reuse and release flags combined can save a lot of time depending on the size of your setup, the number of files and your hardware configuration.
• Perhaps the most effective is a separate setup in my opinion (provided it is stable and not changing that often). Beware though: Wix to Install multiple Applications (the problems involved when it comes to splitting setups).

我的看法 :进行仅前提条件的单独设置.这对于大规模部署方案也很有利，在该方案中，企业用户希望使用自己的标准化先决条件，并且由于庞大的设置而被大量嵌入式垃圾邮件"所困扰.在大型公司中，很多软件包准备时间都花在了过时的运行时和前提条件上.您也可以交付这些先决条件的更新，而无需重建整个设置.良好的去耦.

My take on it: go for a prerequisites-only separate setup. This is good also for Large Scale Deployment scenarios where corporate users want to use their own, standardized prerequisites and are annoyed with lots of embedded "junk" in a huge setup. A lot of package preparation time in large companies is spent taking out outdated runtimes and prerequisites. You can also deliver updates to these prerequisites without rebuilding your entire setup. Good de-coupling.

这篇关于加快WiX安装程序的构建过程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！