我仍在寻找解决方案或至少一些指导，甚至
尽管我同意这不符合正常的良好做法。 – j杰克
1小时前
我无法访问我的部署工具，但我会尝试提供一个视角。由于我没有完全掌握您所写内容的所有方面，因此这将是一般性评论。我希望它至少与你所问的问题有关。正如我所写，它变成了博客。
对我来说MSI补丁有效于2 基本场景:
- You 修复卸载顺序中的错误带有次要升级补丁的已安装产品。
- 您为几个文件提供了一个小升级补丁作为“hotfix“对于已发布的产品，重新安装可能会非常庞大且耗时。
为了这两个目的，我多次有效地专业地使用了 MSI 补丁。在每种情况下都没有其他好的解决办法。恕我直言，修补是为了“修补”——这是整个技术的设计目的，而不是为了部署频繁的增量更新。提供 96 个文件更新NOT热修复。
补丁是有效的升级：请记住，修补只是一种更紧凑的交付机制，用于已经有效的升级。它可以是重大更新、次要更新，甚至是小更新，每一项的工作方式都不同。在执行任何其他操作之前，请确保在尝试将其打包为补丁之前测试实际的完整升级 MSI。这是我能给你的最好建议。如果完整升级无法正常工作，则所有花在修补上的努力都会被浪费。是的，这包括在制作补丁之前的所有交互中的安装、卸载和升级。这可能是最常见的修补错误。
存在一些阻碍补丁卸载的障碍. 有数十个技术问题可能导致补丁无法卸载 http://msdn.microsoft.com/en-us/library/aa372102(v=vs.85).aspx（推荐阅读）。这有时是一个大问题，因为部署了修补程序的补丁可能会被发现有缺陷，因此应该完全撤回。在我看来，这是一个小补丁的核心用途之一 - 部署一个可以回滚的快速修复。
修补和自定义操作条件：对我来说，修补最糟糕的方面之一是，包中的自定义操作可能无法正确调节，以便在执行修补操作（而不是正常安装）时不运行。补丁功能补丁特定的属性例如PATCH and MSI补丁删除。在自定义操作上使用这些条件，使它们在修补程序期间运行或不运行，具体取决于必要的情况。请注意自定义操作的条件，正确执行它们很复杂。这里有一个"MSI 条件备忘单 http://www.flexerasoftware.jp/webdocuments/PDF/IS-CHS-Common-MSI-Conditions.pdf"来帮你。我没有测试过这些条件——测试是唯一的保证。
还有一些修补建议:
-
我会完全忘记主要的升级补丁。我已经尝试过，并将再次尝试，但它们往往不太理想。一个绝对要求要使主要升级补丁发挥作用，请将RemoveExistingProducts 放置在InstallExecuteSequence 中的InstallFinalize 之后。这样做的原因是，否则在补丁包尝试修补现有文件之前，文件会被卸载。相当抓住22。
- A 小升级不卸载现有安装，但评估重新缓存新的 MSI 文件用于维护和卸载操作。这意味着该补丁可以在运行之前修复卸载顺序 - 我上面列出的良好补丁用途之一。事实上，如果小升级有效，则可能根本不需要补丁。除非您的 MSI 文件非常大并且您想要提供一个小的“修补程序”，否则只需使用较小的升级即可。
- 如果您需要在补丁中包含文件，我建议启用“包括整个文件”。否则将完成位级修补，这是不必要的复杂性（除非您的二进制文件非常庞大）。我也不确定位级修补如何与签名文件和数字签名一起使用。
- 仅在补丁中包含您需要的内容。不添加不需要的文件或设置，您就可以制作可靠的补丁。如果可能的话，避免添加自定义操作。
- 如前所述：请注意，补丁使用与常规安装相同的 InstallExecuteSequence，但您可以使用特定于补丁的属性（例如PATCH and MSI补丁删除。在自定义操作上使用这些条件，使它们在修补程序期间运行或不运行，具体取决于必要的情况。
- 组件引用必须 100% 正确才能使任何类型的补丁发挥作用。没有例外。
- 次要升级补丁必须使用正确的 msiexec.exe 命令行运行才能工作，除非通过 setup.exe / update.exe 提供。
- 第三者合并模块根据我的经验，经常会导致修补问题。
- "版本说谎正如他们所说 - 通过在 MSI 文件中为磁盘上的文件添加不同版本来确保文件始终更新的黑术似乎会导致修补错误。
- 补丁将显示与主安装相同的 GUI。在我看来，这是一个错误的设计。 GUI 中的自定义操作可能会扰乱修补过程（您是否应该接受新的用户输入的修补程序值？）。
- 我相信每个补丁都应该是累积的 - 替换所有以前的补丁。当我测试串联和顺序安装的多个补丁时，我再也没有恢复正常工作。出于多种原因，我得出的结论是，这是一个徒劳的修补方法首先。我遇到的问题与您所描述的补丁系列、目标版本等完全一致……补丁不太聪明，它只是一个由几个文件组成的复杂包，试图找到它所属的产品。
显而易见的结论是，我真的不建议您采用这种修补方法，即使被要求时也是如此。然而，我读到这个线程 https://stackoverflow.com/questions/9471790/patching-multiple-instance-installs-with-either-installshield-or-wix这似乎表明对于已转换为使用 WIX 而不是 Installshield 的人来说，修补成功。您还应该查看 CodeProject 链接。
As to 您的部署场景- 我没有完全掌握它的所有方面，但听起来开发人员希望通过补丁将实时应用程序转换为当前的 QA 版本？我永远不会同意这一点，否则情况一定与听起来不同。当您首先必须交付次要或重大升级时，创建补丁的精力完全是浪费——它们足以交付用于 QA 的软件。您可以使用 dev-branch 提供单独的 MSI，然后时不时地创建一些补丁来测试产品是否可修补，但我绝不会使用补丁在内部提供产品的安装程序。我不知道这是否是你被要求做的。
处理次要和主要升级 - 最好是后者用于非补丁，并在您真正需要时提供补丁。如果安装持续时间是一个问题，您可以安排在所有开发人员和 QA PC 上的夜间构建完成后进行每日重大升级吗？ （包括终止安装工作所需的任何正在运行的进程）。我不知道我是否完全偏离了你的场景的真实情况。
检查斯特凡·克鲁格的安装站点.org http://www.installsite.org/pages/en/msi/updates.htm了解更多升级和修补技巧。
查看这个著名的 wix 教程 http://wix.tramontana.co.hu/tutorial/upgrades-and-modularization用于升级和补丁。和MSDN http://msdn.microsoft.com/en-us/library/windows/desktop/aa370579.aspx.
