加快 WIX 编译速度
我有一个 WIX 3.0 安装程序，正在构建 88 个略有不同的版本（32 和 64 位、11 个区域设置、四个版本（测试版、零售版、评估版、不同评估版）的交叉积）。
除了本地化 UI 之外，每个版本的内容也略有不同，所以我不能只构建具有多个区域设置的一个配置，
我已经使用了 CabCache，
安装程序大约需要 3-5 分钟来构建，从而导致总体构建时间相当长。 显然，
在链接过程中安装会受到严重的磁盘限制（light.exe），
是否有人对如何设置可以更快地启动这些安装程序的计算机有帮助？ WIX 项目构建更高效？）
I have a WIX 3.0 installer that is building 88 slightly different builds (cross product of 32 and 64-bit, 11 locales, four editions (Beta, Retail, Evaluation, Different Evaluation).
Each build has slightly different contents in addition to localized UI, so I can't just build one configuration with multiple locales.
The resulting MSI is about 120MB. I'm already using the CabCache.
The installer takes about 3-5 minutes per release to build, resulting in a pretty lengthy overall build time.
The install appears to be heavily disk bound during linking (light.exe).
Clearly making the disks faster could help. Does anybody have advice on how to set up a machine that could crank through these installers faster? (or advice on reconfiguring my WIX project to build more efficiently?)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
获取 SSD。就像 OCZ 等具有内部 RAID 架构的产品之一。 SSD 是这十年来每个开发人员的升级。如果交换有问题，请加上更多 RAM。
Get an SSD. Like one of those with internal RAID architecture from e.g. OCZ. SSD is every developer's upgrade of the decade. Plus more RAM if swapping is an issue.
如果您有公共部分（未本地化），您可以使用公共部分创建一个合并模块，然后将差异内容添加到每个构建中。
If you have common parts (that are not localized) you can create a merge module with the common parts and then just add the differencing stuff to each build.
我不确定您是否对您正在安装的应用程序的开发人员有任何发言权或沟通，但如果您主要因为语言而必须创建那么多 MSI，您是否考虑过只提供一种语言 MSI 来提供所有特定于语言的语言文件到资源目录，然后用户可以选择他们想要使用的语言（但只有当他们需要默认语言以外的语言时才安装它）。此外，也许值得考虑的是，让用户可以选择最好的语言，然后从一开始就安装所有语言。
至于你关于加快构建速度的问题，这是一个棘手的问题。我会立即排除使用合并模块，因为我看不到从中产生任何实际收益。当然，更新硬件（正如你所说）会带来一些结果，但同样，我不确定你会做出多大的跳跃，所以很难说会带来什么样的增益。我认为最好用细齿梳子仔细检查一下您的 WXS，看看里面到底发生了什么。有时您会发现软件包开发中遗留下来的东西，或者以前的工具留下的东西，这些东西确实会减慢您的速度。一个例子是，我的公司最近从一种更自动化的设置创建实用程序切换到 WiX（故意省略名称，因为我列出了它的问题：P），它自动创建了 Windows 下可能需要的每个文件夹。 Windows 应用程序的运行，以及公共文件夹、当前用户配置文件等等。我想我最终删除了 100 多个空目录，而这项旧技术足以为我添加这些目录。这只是已完成的优化的一个示例。当你花时间真正回顾一下幕后发生的事情时，你会发现令人惊奇的东西。
I am not sure if you have any say or communication with the developers of the application that you are installing, but if you have to create that many MSI's mainly because of languages, have you considered just offering one Language MSI that delivers all the language specific files to a resources directory and then the user can choose which language they would like to use (but only install this if they need something other than the default language). Also it might be worth looking into having the product made in such a way that the user can pick from within which language is best, then having all the languages installed from the start.
As for your question about speeding up the build, that is a tricky one. Using Merge Modules I would rule out right away, as I don't see any actual gain coming out of that. Of course updating the hardware (as you said) will give some results, but again, I am not sure how much of a jump you would be making so it is hard to tell what kind of gain that would give. I think it might be best to go over your WXS with a fine tooth comb and see what is really going on in there. You can sometimes find things that are left over from the developement of the package, or from a previous tool that are really slowing you down. One example would be that my company recently switched to WiX from a more automated setup creation utility (leaving the name out on purpose cause I am listing the problems with it :P ) and it automatically created every folder under Windows that might possibly be needed in the running of a windows application, as well as the common files folder, the current user profile, and many many more. I think I ended up erasing in all over 100 empty directories that this old technology was nice enough to add for me. That is just one example of optimization that was done. It is amazing what can be found when you take the time to REALLY review what is going on under the hood.
在您的 wixproj 设置文件中，将其添加到
这将告诉 WIX 仅编译那些在上一次构建后更改的文件。
In your wixproj setup file add this just before the end of file in
<PropertyGroup>tagThis will tell WIX to compile only those files which are changed after the previous build.