我有一个相当大的 WiX 安装程序（250 Mb 以上），我正在尝试制定合适的升级策略。
安装程序中的大多数文件都不会更改，并且当只有一两个文件发生更改时，我们不希望分发整个包。
我研究了主要和次要升级，我的理解是，如果产品 ID 发生变化，只要升级 ID 保持不变，就会发生主要升级，如果这两个值保持不变，则可以使用次要升级补丁。
我的感觉是，使用补丁进行较小的升级将是处理只有少数文件发生变化并且仅在大量文件发生变化时重建整个安装程序的情况的最佳选择。
我已经使用“torch”对此进行了测试，根据两个“wixpdb”文件之间的差异生成“wixmst”文件，然后从中构建补丁。但是，我发现我只能从一个版本修补到另一个版本（例如，1.0.0 到 1.0.1，然后 1.0.1 到 1.0.2，但不能从 1.0.0 到 1.0.2）。是否可以针对补丁的最低版本并支持高于该版本的任何版本？
打补丁是一件很痛苦的事情，所以当你学习掌握它时，要做好应对大量补丁的准备。这是另一个可能适合您的策略。将您的 MSI 拆分为 2 个 MSI（微软称其为 Micropackages）。拥有一个基本 MSI，其中包含预计不会更改的大部分内容，以及一个小得多的第二个 MSI，其中包含您预计流失率较高的文件。
然后使用 Burn 是一个引导程序来处理将它们链接在一起并将它们一起卸载。这与 Visual Studio 的做法类似。
现在您可以交付第二个 MSI 的主要升级。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
