我正在研究为客户创建补丁的最佳选择。当他们需要对系统进行完全回归时，他们不需要一个完整的安装程序（1.0到1.1）。
我想知道是否有一个工具（付费与否）需要2 msi版本才能进行差异/比较并输出一个可用的补丁安装程序。
大多数情况下它会更新程序集（已修改或新增），但可能需要一些自定义脚本（如果可能，请使用c＃）
答案 0 :(得分：3)
他们在进行小补丁时不需要完整的安装程序......因为他们需要对系统进行完全回归。
这句话是基于一些错误的逻辑，无论是谁说出来都是吹出众所周知的烟雾。补丁安装的风险与完整安装程序的风险相同 - 如果测试人员对您的构建/发布过程不信任，那么两者都需要进行全面测试。 msi只是打包，完整安装或补丁安装都可以改变整个系统。如果测试人员想要提出“与补丁的论点，文件abc.dll没有改变，所以我们不必测试其中的功能”，那么你可以争辩说这种想法是错误的 - 如果使用abc.dll的代码发生了变化，那么abc.dll可能会表现出不同的行为。
IOW，我的论点是补丁安装或完全安装都带有相同级别的风险，并且两者都应该测试到同一级别。为了最大限度地减少重新测试所需的数量，您需要在发布过程中建立信任和确定性 - 自动构建/发布过程和可审计的源代码控制系统应该为您做到这一点。
在任何情况下，我同意@Christopher的答案 - 如果您还没有在您的计算机上安装该产品，或者它将切换，则可以使用InstallShield等工具创建一个完整安装的msi。如果检测到具有相同产品代码且已安装较小版本号的项目，则升级模式。话虽如此，让升级工作正常非常困难。
答案 1 :(得分：2)
InstallShield可以提供：
您严格遵守组件规则，并有一个有效的小型升级服务故事。
您正在逐步构建程序集，以免系统认为您的所有文件都已更改。
还有其他方法可以实现这一目标，但诚实需要相当多的管道。
说实话，我已经多次听过你的“我们必须全部测试”的故事，而且我从来没有买过这个论点。通常他们想要将他们的基线分片，然后将他们的头部贴在真正测试表面的沙子上。通常他们的真正问题是SCM / Build / Release规则之一，而不是安装程序是主要升级，次要升级还是补丁。 （IMO）