MSI diff 在包上创建补丁答案

【问题标题】：MSI diff on packages to create patchesMSI diff 在包上创建补丁
【发布时间】：2011-01-05 01:22:14
【问题描述】：

我正在寻找为我们的客户创建补丁的最佳选择。在进行小补丁（从 1.0 到 1.1）时，他们不想要完整的安装程序，因为他们需要对系统进行全面回归。

我想知道是否有一个工具（是否付费）需要 2 个 msi 构建进行差异/比较并输出可用的补丁安装程序。

大多数情况下，它会更新程序集（修改或新的），但可能需要一些自定义脚本（如果可能，在 c# 中）

【问题讨论】：

标签： installation windows-installer patch

【解决方案1】：

他们在做小补丁时不想要一个成熟的安装程序......因为他们需要对系统进行全面回归。

这句话是基于一些错误的逻辑，无论谁说这句话都是在吹口哨。补丁安装的风险与完整安装程序的风险一样大 - 如果测试人员对您的构建/发布过程没有信心，那么两者都需要进行全面测试。 msi 只是包装，完全安装或补丁安装都可以改变整个系统。如果测试人员想提出“随着补丁，文件 abc.dll 没有改变，所以我们不必测试其中的功能”的论点，那么你可以争辩说这种想法是错误的——如果使用 abc.dll 的代码发生了变化，那么 abc.dll 可能会表现出不同的行为。

IOW，我的论点是补丁安装或完整安装都具有相同级别的风险，并且两者都应测试到相同级别。为了最大限度地减少所需的重新测试量，您需要在发布过程中建立信任和确定性 - 自动化的构建/发布过程和可审计的源代码控制系统应该为您做到这一点。

无论如何，我同意@Christopher 的回答 - InstallShield 等工具可用于创建单个 msi，如果您的计算机上尚未安装该产品，则该 msi 可以是完整安装，或者它将切换如果它检测到已安装具有相同产品代码和较低版本号的项目，则升级模式。话虽如此，要使升级正常工作可能非常困难。

【讨论】：

我 100% 同意，但是我们正在处理他们的内部政策。他们需要查看文件没有被安装程序替换（我们的完整安装程序会这样做）。
ROFLMAO。 100% 同意，但遗憾的是，在过去的 15 年里，我听到这么多人说过多少次，你可能会感到惊讶，也可能不会感到惊讶。但我不同意完整和补丁之间的风险是相同的。补丁安装有更多的风险，因为您的完整安装过程是完全自动化的，而您的补丁定义过程不是。这就像一遍又一遍地练习相同的方式，然后到了释放的时候，你叫一个可听的，然后用另一种方式来做。
顺便说一句，取决于您如何定义“构建/发布过程”，我也可能不同意这一点。以我的经验，构建/发布过程是 100% 防弹的。问题更多地在于 SCM 方面的基线是如何锁定的。通常这不是构建问题，更多的是他们不知道签入的内容，或者他们知道签入的内容太多，他们现在正试图通过创建补丁安装程序来解决这个问题。
@user551962 - 如果您的安装程序正在替换不应被替换的文件，那么这是您的设置逻辑的问题。
Sascha- 定义“不应该”。也许他们进行了完整构建而不是增量构建，因此安装程序会看到实际上没有任何有意义的更改的“新”文件。

【解决方案2】：

InstallShield 可以做到这一点：

您严格遵守组件规则，并且有一个有效的次要升级服务故事。
您正在逐步构建程序集，以免系统认为您的所有文件都已更改。

还有其他方法可以做到这一点，但说实话，这需要相当多的努力。

老实说，我多次听过您的“我们必须全部测试”的故事，但我从未接受过这种说法。通常他们想把他们的基线拼凑起来，然后把头伸进沙子里，真正的测试表面是什么。通常，他们真正的问题是 SCM / Build / Release 规则之一，而不是安装程序是 Major Upgrade、Minor Upgrade 还是 Patch。（海事组织）

【讨论】：

我同意全部测试或不测试，但是他们是一家银行并且有我们必须遵守的内部政策。我会看看 InstallShield 谢谢。
InstallShield 也有一个 QuickPatch 模式。我从来没有找到一种方法来自动化它，但如果你的发布周期不是那么频繁，它可能会做你想做的事。基本上你给它1个MSI，然后选择一堆文件，它会为这些文件生成一个MSP。因此，如果您被告知每月一次左右我们需要修补这 5-10 个文件（您明白了），这可能对您有用。
是的，问题是至少每周一次，而且该过程目前相当手动且容易出错。感谢您的帮助。