windows-installer - Windows Installer“错误1308。找不到源文件”在按顺序方案中卸载修补程序时

Question

我需要使用在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包含的更改（文件更新）比前两个更多。让我重复一遍：还有很多变化。

我的问题是：


为什么仅在安装了一系列补丁而不是第三个补丁本身的情况下才发生这种情况？
为了防止补丁程序卸载以尝试从构建补丁程序时仅用于设计时的位置获取文件，我该怎么办？还是这是设计使然，但是缓存太重载或混乱了。


更新-更多信息（由Glytzhkof请求）：
该补丁包含96个文件更改，大约是基本MSI软件包大小的一半。它实际上不在“ Dev”分支工作范围内。几个新文件已添加。其中一些最初被删除（当我发现我们确实在做补丁时，不得不将它们放回原处...）。如果我再描述这种情况，它可能会冒犯您作为该领域的专家。

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

是的，补丁可以更快（让我在这里扮演魔鬼的拥护者）。但是，实际上，何时自动部署这些东西的时间在30到90秒之间？是的，我还考虑过通过调整文件成本来优化安装程序的方法，以查看它是否能够使其更快地运行，但是即使如此，我仍然肯定会有另一个原因要求安装补丁。

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

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

Answer 1

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


我没有访问部署工具的权限，但是我将尝试提供一个视角。由于我没有完全掌握您所写内容的所有方面，因此将使用通用注释。我希望它至少与您的要求有关。如我所写，它变成了一个博客。

对我来说，MSI补丁对2种基本情况有效：


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


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

补丁程序是可行的升级：请记住，补丁程序只是用于已经生效的升级的更紧凑的交付机制。它可以是主要更新，次要更新甚至是很小的更新，每个更新的工作方式都不同。在进行其他任何操作之前，请确保先测试了实际的完整升级MSI，然后再尝试将其打包为补丁程序。这是我能给您的最佳建议。如果完整升级无法正常工作，则浪费了所有修补工作。是的，这包括在制作补丁程序之前进行所有交互的安装，卸载和升级。这也许是最常见的修补错误。

存在一些阻碍卸载补丁程序的障碍。 There are dozens of technical issues that may result in uninstallable patches（建议阅读）。有时这是一个巨大的问题，因为已发现部署了修补程序的补丁有缺陷，因此应将其完全撤回。在我看来，这是一个小补丁的核心用途之一-部署一个快速修复程序，然后可以将其回滚。

修补程序和自定义操作条件：对我而言，修补程序最糟糕的方面之一是，与正常安装相反，在执行修补程序操作时，可能无法将软件包中的自定义操作适当地设置为不运行。修补程序具有修补程序特定的属性，例如PATCH和MSIPATCHREMOVE。在自定义操作上使用这些条件，以使其在补丁程序期间运行或不运行，具体取决于必要的条件。注意自定义操作的条件，这些条件很难正确处理。这是一个“ MSI Conditions Cheat Sheet”可以帮助您。我尚未测试这些条件-测试是唯一的保证。

一些进一步的修补建议：


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


显而易见，我确实不建议您使用这种修补方法，即使在被要求时也是如此。但是，我读了this thread，这似乎表明已成功转换为使用WIX而不是Installshield的用户进行了修补。您也应该查看CodeProject链接。

关于您的部署方案-我没有完全掌握它的所有方面，但是听起来像开发人员想要补丁程序通过补丁程序将实时应用程序转换为当前的质量检查版本？我永远不会同意这一点，否则情况必须与听起来不同。当您必须首先交付较小或较大的升级时，就完全浪费了创建补丁的精力-它们足以交付用于QA的软件。您可以使用dev分支来交付单独的MSI，然后不时创建一些补丁，然后测试该产品是否可补丁，但是我绝不会使用补丁在内部交付产品的安装程序。我不知道这是否是您要执行的操作。

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

查看Stefan Kruger的installsite.org了解更多升级和补丁提示。

查看this well known wix tutorial以获得升级和补丁。还有MSDN。