2

我需要使用带有 Installshield 2012 的 Patch Design 创建的一系列可卸载补丁。前两个补丁在卸载时工作正常。然而，第三个补丁，当且仅当在补丁 1 和/或补丁 2 已经应用时卸载，会产生错误：

MSI (c) (48:C4) [19:02:54:135]: Font created.  Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg
Error 1308.Source file not found: {pathToFile}.  Verify that the file exists and that you can access it.

其中有 26 个关于不同文件的错误。文件或组件没有明显的模式，或者没有特征

注意：如果我只应用了补丁 3，卸载不会产生此错误..

我在补丁设计中使用相同的选项创建了所有三个补丁。我理解的唯一明显区别是补丁 3 包含比前两个更多的更改（文件更新）。让我重复一遍：更多的变化。

我的问题是：

  1. 为什么只有在安装了一系列补丁的情况下才会发生这种情况，而不仅仅是第三个补丁本身？

  2. 为了防止补丁卸载尝试从构建补丁时仅用于设计时的位置获取文件，我必须做些什么？或者也许这是设计使然，但是缓存太重或太混乱了..？

更新 - 更多信息（由 Glytzhkof 请求）：该补丁包含 96 个文件更改，大约是基本 MSI 软件包大小的一半。它实际上与“开发”分支工作无关。添加了几个新文件。有些最初被删除（当我发现我们真的在做补丁时不得不把它们放回去......）。如果我再描述这种情况，可能会冒犯您作为该领域的专业人士。

我一直在尝试销售主要升级，只需对安装程序进行一些调整即可使其不再需要补丁。我们产品的卸载需要参数才能使其成为非交互式（我们需要此参数才能在主要升级方案中工作，它目前只是卸载序列的一部分）。这是唯一真正的问题——但解决它会付出很多。但是，决定不解决该问题。我尝试在每次迭代中“解决”这个问题。没有骰子。有人告诉我，我们需要主要版本的补丁 - 所以在这里我试图让尾巴摇摆不定。

是的，补丁可以更快（让我在这里扮演魔鬼的拥护者）。但真的，30 秒和 90 秒之间的区别，这些东西什么时候自动部署？是的，我还考虑通过调整文件成本来优化安装程序，以查看它是否会使其更快，但即便如此，我相信还有另一个原因会要求提供补丁。

另一个更新：1308 错误中提到的文件不在目标系统的%windir%Installer\$PatchCache$\Managed\{PackedProductCodeOfMyBaseMSI??}

文件夹。这可能会导致 1308，因为如果我从此缓存中删除更多文件，我会得到与丢失文件相对应的相同错误。问题可能是，为什么不是所有文件都在这个PatchCache文件夹中？

4

4 回答 4

7

我仍在寻找解决方案或至少一些指导，尽管我同意这超出了正常的良好做法。– 杰克 1 小时前

我无权访问我的部署工具，但我会尝试提供一个视角。由于我没有完全掌握您所写内容的所有方面，因此将是一般评论。我希望它至少与您的要求有关。当我写的时候，它变成了一个博客。

对我来说，MSI 补丁对2 个基本场景有效：

  1. 您使用次要升级补丁修复了已安装产品的卸载顺序中的错误。
  2. 您为几个文件提供了一个小的升级补丁，作为一个已发布产品的“修补程序”，重新安装可能非常庞大且耗时。

出于这两个目的，我多次专业地使用 MSI 补丁。在每种情况下，都没有其他好的解决方法。修补恕我直言是为了“修补程序”——这是整个技术的设计目的，而不是为了部署频繁的增量更新。提供 96 个文件更新不是修补程序。

补丁是一种有效的升级：请记住，补丁只是一种更紧凑的交付机制，用于已经有效的升级。它可以是一个主要的、次要的甚至是小的更新，并且每个更新都会有所不同。在您执行任何其他操作之前，请确保在尝试将其打包为补丁之前测试您的实际完整升级 MSI。这是我能给你的最好建议。如果完全升级不能正常工作，那么在修补上花费的所有精力都将被浪费。是的，这包括在制作补丁之前的所有交互中的安装、卸载和升级。这可能是最常见的修补错误。

存在一些阻碍补丁卸载的障碍。有许多技术问题可能会导致补丁无法卸载（推荐阅读）。有时这是一个大问题，因为部署了修补程序的补丁可能会被发现有缺陷，因此应该完全撤回。在我看来，这是一个小补丁的核心用途之一——部署一个快速修复，然后可以回滚。

修补和自定义操作条件：对我来说，修补最糟糕的方面之一是包中的自定义操作可能无法正确调整为在执行修补操作而不是正常安装时不运行。补丁具有特定于补丁的属性，例如PATCH和MSIPATCHREMOVE。根据需要，对自定义操作使用这些条件，使它们在补丁期间运行或不运行。请注意自定义操作的条件，它们很难正确处理。这是一份“ MSI 条件备忘单”来帮助您。我没有测试过这些条件——测试是唯​​一的保证。

一些进一步的修补建议：

  • 我会完全忘记主要的升级补丁。我已经尝试过它们，并将再次尝试它们，但它们往往不太理想。主要升级补丁工作的绝对要求是 RemoveExistingProducts 放置在 InstallExecuteSequence 中的 InstallFinalize 之后。这样做的原因是，否则这些文件会在补丁包尝试修补现有文件之前被卸载。很好抓到 22。
  • 次要升级不会卸载现有安装，但评估者会重新缓存新的 MSI 文件以用于维护和卸载操作。这意味着补丁可以在运行之前修复卸载顺序——我上面列出的一个很好的补丁使用。事实上，如果次要升级有效，则可能根本不需要补丁。只需使用次要升级，除非您的 MSI 文件非常大并且您想要提供一个小的“修补程序”。
  • 如果您需要在补丁中包含文件，我建议启用“包含整个文件”。否则会完成位级修补，这是不必要的复杂性（除非您的二进制文件很大）。我也不确定位级修补如何与签名文件和数字签名一起工作。
  • 仅在补丁中包含您需要的内容。不添加不需要的文件或设置，您可以制作可靠的补丁。尽可能避免添加自定义操作。
  • 如前所述：请注意，补丁使用与常规安装相同的 InstallExecuteSequence，但您可以使用特定于补丁的属性（例如PATCH和MSIPATCHREMOVE ）以不同的方式调整自定义操作。根据需要，对自定义操作使用这些条件，使它们在补丁期间运行或不运行。
  • 组件引用必须 100% 正确才能使任何类型的补丁正常工作。没有例外。
  • 次要升级补丁必须使用正确的 msiexec.exe 命令行运行才能工作，除非通过 setup.exe / update.exe 交付。
  • 根据我的经验，第三方合并模块经常会导致补丁问题。
  • 正如他们所说的“版本谎言”——通过在 MSI 文件中为磁盘上的文件添加不同版本来确保文件始终得到更新的黑色艺术似乎会导致修补错误。
  • 补丁将显示与主安装相同的 GUI。在我看来，这是错误的设计。GUI 中的自定义操作可能会打乱修补过程（您是否应该接受新的用户输入以获取修补程序的值？）。
  • 我相信每个补丁都应该是累积的——替换所有以前的补丁。当我测试了几个按顺序安装的补丁时，我再也没有让它正常工作。出于多种原因，我得出结论，这是一种徒劳的修补方法。我遇到的问题与您在补丁系列、目标版本等方面所描述的完全一致……补丁不是太聪明，它只是一个复杂的文件包，试图找到它所属的产品。

显而易见的结论是，我真的不建议您使用这种修补方法，即使在被要求时也是如此。但是，我阅读了这个线程，这似乎表明已成功修补已转换为使用 WIX 而不是 Installshield 的人。您也应该查看 CodeProject 链接。

至于您的部署方案- 我没有完全掌握它的所有方面，但听起来开发人员希望补丁通过补丁将实时应用程序转换为当前的 QA 版本？我永远不会同意这一点，或者场景必须与听起来不同。当您必须首先交付次要或主要升级时，创建补丁完全是浪费精力 - 它们足以为 QA 交付软件。您可以使用 dev-branch 提供单独的 MSI，然后不时创建一些补丁来测试产品是否可修补，但我绝不会使用补丁在内部提供产品的安装程序。我不知道这是否是你被要求做的。

使用次要和主要升级 - 最好是后者用于非补丁，并在您真正需要时提供补丁。如果安装持续时间是一个问题，您可以安排在所有开发人员和 QA PC 上的每晚构建完成后进行每日重大升级？（包括杀死使安装工作所需的任何正在运行的进程）。我不知道我是否完全偏离了您的实际情况。

查看 Stefan Kruger 的installsite.org以获取更多升级和修补提示。

查看这个众所周知的 wix 教程以获取升级和补丁。和MSDN。

于 2014-05-03T23:15:13.487 回答
2

我将不得不将此添加为答案，因为评论太长了。200个文件更改？我猜文件成本计算将比安装整个小升级花费更长的时间。如果我是你，我会拒绝提供这类补丁。由于技术的复杂性，它们注定会失败，几乎 100% 肯定会失败。请记住，MSI 补丁只是已经工作升级的交付机制，基本上只是增加了风险和复杂性。确实是这样。

MSI 补丁很复杂，并且已注册以供检查和卸载 - 它们不只是像在 MSI 之前的世界中那样转储和修补文件。如果用户需要打补丁，我会选择与 MSI 完全不同的解决方案。

你能更好地描述一下这个场景吗？我发现提供重大升级的自动化构建流程非常适合将日常构建交付给 QA。如果安装速度是一个问题，您可以使用一些技术来加快速度，例如启用MSIFASTINSTALL。使用此属性，您可以告诉系统执行较少繁重和耗时的操作，例如创建系统还原点并进行彻底的文件成本计算（比较已安装和安装的文件和目录大小）。

于 2014-05-03T14:12:20.560 回答
1

我会查看有关此错误的任何支持文章，其中有几篇。在某些情况下，它们可能是特定于产品的，但可能指向错误（例如管理安装或 Windows Installer 中的错误）。也许你已经这样做了。

否则，当补丁取代设置在某些方面不正确时，往往会出现这些问题。如果您以某种方式说其中一个补丁取代了另一个补丁，那么根据定义，它包括早期补丁的所有补丁更改。由于这涉及在各个地方摆弄 guid，如果使用相同的基本 PCP 文件，可能会错过更改，尽管我不确定 IS 暴露或隐藏了多少。最终结果是 Windows 会认为不再需要其他补丁并将其删除。这可能会有所帮助：

http://msdn.microsoft.com/en-us/library/aa368345(v=vs.85).aspx

于 2014-05-06T16:51:54.887 回答
0

解决这个 IS 建议对于评论来说太长了，所以：

在本地缓存实际安装 MSI 的副本一直是一个好主意（搜索 Windows Installer 规则之道），以防修复、添加功能等，但 Heath 的文章是关于内部缓存 MSI 文件的 5.0 更改，这不是同样的事情。IS 可能会说“保留可用的实际 MSI 文件的副本”，Heath 只是描述了对“秘密”缓存 MSI 文件的内部更改，但内部缓存的 MSI 不被视为有效来源。确定它们是指哪个“缓存”。我认为他们的意思是您应该在安装时保留一份实际可用的 MSI 副本。

我的猜测是，IS 看到的根本问题不是缺少补丁，而是因为 Windows 需要在补丁卸载时恢复原始文件，所以如果 msp 文件不可用，那么它可以从原始虚拟 MSI 中获取它由原始加补丁组成的文件。如果您使用 IS 的缓存 MSI 选项，我假设它会将 MSI 文件复制到某处并从那里安装它，或者以其他方式使该位置成为有效来源。如果需要在补丁卸载时恢复文件，他们的分析是可以（自动？）使用（基本 MSI+任何适用的补丁）来恢复以前的文件。我试图从你的简短评论中读懂 IS 的想法，也许它会有所帮助，尽管我确信我没有完全准确。

于 2014-05-13T16:30:42.920 回答