我有一个带有CA类型1的MSI。后来，我意识到必须更改CA，所以我更新了它并创建了一个MSP。
Q1 ：如果我安装MSI然后应用MSP，我认为缓存的MSI（Windows \ Install目录中的一个）不包含更新的CA，对吗？
Q2 ：如果我卸载此MSI，安装程序是先卸载MSP还是MSI？
Q3 ：在卸载过程中会执行哪个CA？更新的CA或原始CA？或者首先更新CA，然后是原始CA？
提前致谢。
答案 0 :(得分：1)
PhilDW已经解决了您的具体问题，也许我可以猜测底层问题到底是什么。
这是MSP的次要或主要升级吗？一个小的升级补丁可用于＆＃34; hotfix＆＃34;已安装的MSI卸载顺序中的错误 - 如果这是您真正要求的。我已经做了很多次，当你先安装补丁然后再卸载时，卸载的是你在MSP中包含的内容 - 新的CA - 只要你正确安装了所有东西（命令行等等）。 MSP在运行时合并到缓存的MSI - 正如菲尔所说。我有点模糊，是如何处理任何应用的变换 - 这是我从未有时间测试的东西。你在使用变换吗？
当您在安装的安装程序的卸载顺序中发现错误时，经常会使用此方法，以防止主要升级正常运行。在常规主要升级中，旧的自定义操作可能会或可能不会从旧设置运行，具体取决于how it is conditioned（请参阅某些调节备忘单的链接），但通常它会不合需要地运行，会返回意外错误，从而触发不良操作回滚或整个自定义操作崩溃，导致主要升级失败（或卸载失败）。
以上产生a catch 22 situation，其中您的现有安装显示为不可卸载且无法升级 - 但是可以进行一次小的升级（作为次要升级安装的常规MSI也应该起作用 - 它不应该＆＃39} ; t需要作为补丁提供，前提是您从命令行正确地重新缓存新的MSI - 补丁只是一种已经正在运行的升级的分发机制。）
另一方面，主要升级补丁（MSP）将不允许您修复现有安装的卸载顺序中的错误，因为它会触发预先存在的安装的卸载顺序并告诉它：＆＃34;卸载自己＆＃34; - 作为主要升级操作的一部分。当发生这种情况时，则使用旧的CA--它嵌入在旧设置的缓存MSI中。这是旧设置运行 - 未更改。
自从我制作了一个重要的升级补丁以来已经过去了十多年 - 我发现它们非常糟糕，如果可能的话我会避开它们。存在太多问题 - 老实说：一些严重的逻辑缺陷（例如，您尝试修补的产品可能已经卸载 - 如果您提前安排RemoveExistingProducts - 请参阅下文 - 一个相当荒谬的错误，可能会有说）。我从来没有使用过WiX进行过主要的升级补丁，但我尝试使用Installshield并简单地使用Wise。为了让它们完全运行，你必须在安装新版本后设置旧版本的卸载（所以旧版本在你尝试修补时已经没有了）。这意味着RemoveExistingProducts必须在InstallExecuteSequence中延迟 - 这使得设置容易受到组件引用错误的影响（另一个常见问题）。
更新：我还应该补充一点，我的主要升级测试 - 多年前完成 - 也遇到了功能状态迁移问题（ MigrateFeatureStates ） - 修补程序导致所有功能都显示在未知状态。到目前为止，我还没来得及确切地知道发生了什么，但我认为这可能是我自己做的。我使用Preselected property做了一些时髦的事情（我认为它可能与合并模块做了一些愚蠢的事情有关 - 我试图修复＆＃34;它 - 另一个没有修复的问题。修复任何问题，但引起了新的问题 - 以及诸如此类的东西:-) - 部署很有趣）。只是报告失败，无论我有什么英特尔 - 都没有声称有任何解决方案。还有其他问题 - 但我认为其中大部分都是特定于Installshield的。 WiX可能做得更好。 Wise对于小型升级非常有用（他们确实有效），但我从未使用Wise进行真正的重大升级。
典型的主要升级自定义操作问题是自定义操作被错误调整，并且将在旧版本的卸载和新版本的安装中运行。有许多模式可以测试您的情况，如果您花时间这样做，您会感到惊讶：安装，修复，修改 ，卸载，补丁等等。您经常会发现自定义操作在修改或修复操作或类似操作上意外运行。我链接到几张上面条件的备忘单，这里又是：Is it possible to run a custom action only in repair mode。
更新：常见的修补程序问题是自定义操作可能会意外运行，因为它们不受NOT PATCH限制。 Rant：我希望修补在MSI中是自己的东西，而不仅仅是定期更新的交付机制，它只会定位文件并拥有自己的安装顺序（如admin install）。这将允许＆＃34;有针对性的修补＆＃34;和大型产品的小修补程序 - 这真的需要一些工作，脚踏实地的修补，这不是过于繁琐和过于复杂（这是MSI目前的修补 - 诚实地说。）
么？使用次要升级修补程序或常规次要升级（不作为修补程序提供）来修复卸载问题，然后继续使用常规升级方法。应该可以在WiX Burn软件包中提供所有这些 - 但我从未有时间对其进行测试。
我的2美分？如果您的产品很小，请忘记修补，只需使用常规的次要升级MSI即可。如果您的产品很大，那么请使用补丁包（或者您的下载包将比必要的更大）。请注意，您未来的安装程序包还应包含＆＃34;修补程序＆＃34; patch / MSI允许使用较旧安装的用户在安装最新版本之前修复卸载错误。有点笨重，但它应该是可管理的。如果您的旧设置具有正常工作卸载，但作为主要升级失败（由于卸载序列中的重大错误导致整个过程失败），您可以使用传递给{{1}的常规卸载命令卸载旧设置然后安装新版本（通过先执行手动卸载来避免主要升级方案）。我还没有用Burn测试过这个。
答案 1 :(得分：0)
在（通常）\ windows \ installer目录中，有缓存的MSI以及为该产品安装的所有补丁。执行某些安装操作时，缓存的MSI及其所有相关补丁将被＆＃34;合并＆＃34;创建实际当前安装的修补产品的视图，所以：
因此Q1并不真正适用，因为缓存的MSI本身没有做任何事情。如果你用Orca来看它，它就不会反映这个补丁，因为那是在一个单独的MSP文件中。
Q2：没有第一个和最后一个，因为（MSI + Patches）是卸载的，然后清理删除不再需要的文件。
问题3：（MSI +补丁）中只有一个CA，这就是所谓的。