我有一个Wix3.0安装程序,它正在构建88个略有不同的版本( 32位和64位的交叉产品,11个地区,4个版本(Beta,Retail,评估,不同评估)。
除了本地化的UI之外,每个构建的内容都略有不同,因此我不能只构建一个具有多个区域设置的配置。
由此产生的MSI约为120MB。我已经在用CabCache了。
安装程序每个版本大约需要3-5分钟来构建,导致总体构建时间相当长。
在链接过程中,安装似乎受到大量磁盘限制(light.exe)。
显然,让磁盘更快可能会有所帮助。有谁有建议如何设置一台机器,可以更快地通过这些安装程序?(或者关于重新配置我的WIX项目以更有效地构建的建议?)
发布于 2010-10-14 05:14:27
获取SSD。例如,OCZ的内部RAID架构之一。SSD是十年来每个开发人员的升级。如果交换是一个问题,再加上更多的RAM。
发布于 2010-10-14 15:29:27
如果您有公共部分(未本地化),您可以创建一个包含公共部分的合并模块,然后将差异内容添加到每个构建中。
发布于 2010-10-21 22:55:06
我不确定你是否有任何发言权或与你正在安装的应用程序的开发人员沟通,但如果你必须创建那么多的MSI的主要原因是语言,你有没有考虑过只提供一种语言的MSI,提供所有语言特定的文件到一个资源目录,然后用户可以选择他们想要使用的语言(但只有当他们需要默认语言以外的东西时才安装此程序)。此外,让用户可以从其中选择哪种语言是最好的,然后从一开始就安装所有语言,这可能是值得研究的产品制作方式。
至于你关于加速构建的问题,这是一个棘手的问题。使用合并模块我会立即排除,因为我看不到任何实际的收益。当然,更新硬件(如您所说)会给出一些结果,但同样,我不确定您会有多大的进步,所以很难判断这会带来什么样的收益。我认为最好的办法是仔细梳理一下你的WXS,看看里面到底发生了什么。您有时会发现开发包过程中遗留下来的东西,或者以前的工具中真正拖慢您速度的东西。一个例子是,我的公司最近从一个更自动化的安装程序创建实用程序切换到WiX (故意忽略这个名称,因为我列出了它的问题:P ),它自动创建了Windows下运行windows应用程序时可能需要的每个文件夹,以及通用文件夹、当前用户配置文件和许多其他文件夹。我想我最终删除了100多个空目录,这项旧技术为我添加了足够好的目录。这只是一个已经完成的优化的例子。当你花时间真正回顾一下引擎盖下发生的事情时,你会发现令人惊叹的东西。
https://stackoverflow.com/questions/3927987
复制相似问题