【问题标题】:MSI uninstallation sequence after an MSP was installed安装 MSP 后的 MSI 卸载顺序
【发布时间】:2018-02-04 07:54:15
【问题描述】:

我有一个 CA 类型 1 的 MSI。后来,我意识到必须更改 CA,所以我对其进行了更新并创建了一个 MSP。

Q1:如果我安装 MSI 然后应用 MSP,我认为缓存的 MSI(Windows\Install 目录中的一个)不包含更新的 CA,对吗?

Q2:如果我卸载这个 MSI,安装程序会先卸载 MSP,然后再卸载 MSI?

Q3:卸载时会执行哪个CA?更新的 CA 还是原始 CA?还是先更新 CA,然后再使用原始 CA?

提前致谢。

【问题讨论】:

  • 这是次要升级还是主要升级 MSP?换句话说,您是否更改了产品代码、包代码和产品版本 - 保持升级代码相同?
  • 嗨@Stein,有问题的MSP 是一个小更新。由于我的无知,我仍然不知道是否有“重大升级MSP”,因为我从未听说过。我认为所有 MSP 都是次要更新(不是主要更新也不是升级)。
  • 多年前我确实对 MSP 进行了重大升级,但它从未正常工作。不知道现在有没有什么不同。听起来您的次要升级 MSP 应该可以正常工作。请记住测试安装、修补和卸载方案。理想情况下也是修补后的升级方案。
  • @Stein。谢谢你的建议!
  • 没问题,请务必阅读我的回答中的一些更新以及检查您的卸载是否在重大升级之外工作的建议(在这种情况下,您可以只使用卸载命令而不是修复问题的补丁 - 请参阅下面我的答案的结尾)。

标签: wix windows-installer


【解决方案1】:

在(通常)\windows\installer 目录中,有缓存的 MSI 和已为该产品安装的任何补丁。当执行某些安装操作时,缓存的 MSI 及其所有相关补丁被“合并”以创建实际当前安装的补丁产品的视图,因此:

所以 Q1 并不真正适用,因为缓存的 MSI 本身并没有做任何事情。如果您使用 Orca 查看它,它不会反映补丁,因为它位于单独的 MSP 文件中。

Q2:没有第一个和最后一个,因为 (MSI+Patches) 是卸载的,然后清理删除不再需要的文件。

Q3:(MSI+Patches)中只有一个 CA,这就是所谓的。

【讨论】:

    【解决方案2】:

    PhilDW 已经处理了您的具体问题,也许我可以猜测一下潜在问题到底是什么。

    这是次要或主要升级 MSP?一个小的升级补丁可用于“修复”已安装 MSI 的卸载序列中的错误 - 如果这是您真正要求的。我已经做过很多次了,当您先安装补丁然后卸载时,卸载时运行的是您包含在 MSP 中的内容 - 新 CA - 只要您正确安装了所有内容(命令行等...)。 MSP 在运行时被合并到缓存的 MSI - 正如 Phil 所说的那样。我有点模糊,是如何处理任何应用的转换 - 这是我从未有时间测试的东西。你在使用转换吗?

    当您在已安装的安装程序的卸载顺序中发现错误导致重大升级无法正常运行时,经常使用此方法。在常规的主要升级中,旧的自定义操作可能会或可能不会从旧设置运行,具体取决于 how it is conditioned(请参阅一些条件备忘单的链接),但通常它要么运行不正常,要么返回意外错误,触发不希望的回滚或整个自定义操作崩溃,导致主要升级失败(或卸载失败)。

    以上产生a catch 22 situation,您现有的安装似乎无法卸载和升级 - 但可以进行小升级(作为小升级安装的常规 MSI 也应该可以工作 - 它不应该需要以补丁的形式提供,前提是您从命令行正确地重新缓存了新的 MSI - 补丁只是已经工作的升级的分发机制。


    另一方面,主要升级补丁 (MSP) 不允许您修复现有安装的卸载顺序中的错误,因为它会触发预先存在的安装的卸载顺序并告诉它:“卸载自己” - 作为主要升级操作的一部分。发生这种情况时,将使用旧 CA - 它嵌入在旧设置的缓存 MSI 中。它是旧的设置运行 - 未更改。

    自从我进行重大升级补丁以来已经十多年了 - 我发现它们非常糟糕,如果可能的话我会避免它们。有太多问题 - 老实说:一些严重的逻辑缺陷(例如,您尝试修补的产品可能已经被卸载 - 如果您提前安排 RemoveExistingProducts - 见下文 - 一个相当荒谬的错误,一个会说)。我从未使用 WiX 进行过重大升级补丁,但我尝试使用 Installshield 并简要使用 Wise。为了让它们完全运行,您必须将旧版本的卸载设置为在安装新版本之后进行(因此在您尝试修补时旧版本还没有消失)。这意味着 RemoveExistingProducts 必须晚于 InstallExecuteSequence - 这使得设置容易受到组件引用错误的影响(另一个常见问题)。

    更新:我还应该补充一点,我的主要升级测试 - 很多很多年前完成的 - 也有功能状态迁移问题 (MigrateFeatureStates) - 补丁导致所有功能都以未知状态显示。到目前为止,我还没有时间弄清楚到底发生了什么,但我认为这可能是我自己做的。我对Preselected property 做了一些时髦的事情(我认为这可能与合并模块做一些愚蠢的事情有关 - 我试图“修复”它 - 另一个没有修复任何问题但导致新问题的修复 - 并且诸如此类的东西:-) - 部署很有趣)。只是报告失败,以及我拥有的任何情报 - 不声称有任何解决方案。还有其他问题 - 但我认为其中大多数是特定于 Installshield 的。 WiX 可能会做得更好。 Wise 非常适合小升级(它们确实有效),但我从未将 Wise 用于真正的大升级。

    一个典型的主要升级自定义操作问题是自定义操作被错误地调节并且将在旧版本的卸载和新版本的安装中运行。有许多模式可以测试您的条件,如果您花时间这样做,您会感到惊讶:安装修复修改uninstallpatch等...而且您经常会发现自定义操作在修改或修复操作或类似操作时会意外运行。我为上述条件链接了一些备忘单,这里又是:Is it possible to run a custom action only in repair mode

    更新:一个常见的补丁问题是自定义操作可能会意外运行,因为它们不是以NOT PATCH 为条件的。 Rant:我希望修补程序在 MSI 中是它自己的事情,而不仅仅是定期更新的交付机制,它只针对文件并有自己的安装顺序(就像管理员安装一样)。这将允许“有针对性的补丁”和大型产品的小修补程序 - 这确实需要一些工作的、脚踏实地的补丁,而且不会过于雄心勃勃和过于复杂(这是 MSI 目前的补丁 - 老实说)。


    建议?使用次要升级补丁或常规次要升级(未作为补丁提供)修复卸载问题,然后继续使用正常升级方法。应该可以在 WiX Burn 包中提供所有这些 - 但我从来没有时间测试它。

    我的 2 美分?如果您的产品很小,请忘记打补丁,只需使用常规的次要升级 MSI。如果你的产品很大,那么使用补丁包(或者你的下载包会比需要的大很多)。请注意,您未来的安装包还应包含“修补程序”补丁/MSI,以允许安装较旧的用户在安装最新版本之前修复卸载错误。有点笨拙,但它应该是可以管理的。如果您的旧设置有一个有效的卸载,但作为主要升级失败(因为卸载序列中的一个微不足道的错误导致整个过程失败),您可以使用传递给msiexec.exe 的常规卸载命令卸载旧设置然后安装新版本(通过先执行手动卸载来避免主要升级情况)。我还没有用 Burn 测试过。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 2011-11-29
      • 2023-03-24
      • 2011-02-16
      • 1970-01-01
      • 1970-01-01
      • 2019-05-18
      • 1970-01-01
      相关资源
      最近更新 更多