在序列方案中卸载修补程序时,Windows Installer"错误1308.找不到源文件"

Question

我需要使用Patch Design和Installshield 2012创建一系列可卸载的补丁.前两个补丁在卸载时工作正常.但是,第三个补丁,当且仅当已经应用补丁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,卸载不会产生此错误.

我在Patch Design中使用相同的选项创建了所有三个补丁.我理解的唯一明显的区别是补丁3包含比前两个更多的更改(文件更新).让我再说一遍:更多的变化.

我的问题是:

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

2. 为了防止修补程序卸载尝试从构建修补程序时仅用于设计时的位置获取文件,我该怎么办？或者这可能是设计中的提取,但缓存太过重载或混淆..？

更新 - 更多信息(由Glytzhkof请求):补丁包含96个文件更改,大约是基本MSI包大小的一半.它实际上是在'Dev'分支工作之外.添加了几个新文件.有些人最初被删除了(当我发现我们真的在做补丁时,不得不把它们放回去......).如果我不再描述这种情况,它可能会冒犯你作为该领域的专业人士.

我一直在尝试销售大型升级,只需要对安装程序进行一些调整就可以使其过时需要补丁.卸载我们的产品需要参数,以便它是非交互式的(我们需要此参数在Major Upgrade场景中工作,它目前只是卸载序列的一部分).这是唯一真正的问题 - 但修复它会支付成本.然而,决定不解决这个问题.我尝试在每次迭代时"碰撞"这个问题.没有骰子.我告诉我们需要主要版本的补丁 - 所以在这里我试图让尾巴摇尾巴.

是的,补丁可以更快(让我在这里扮演魔鬼的拥护者).但实际上,30到90秒之间的差异,当这些东西自动部署时？是的,我还考虑通过调整文件成本来找到优化安装程序的方法,看看它是否能让它变得更快,但即使这样,我也确定会有另一个原因要求修补程序.

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

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

Answer 1

我仍在寻找解决方案或至少一些指导,即使我同意这不属于正常的良好做法. - jJack 1小时前

我无法访问我的部署工具,但我会尝试提供透视图.由于我没有完全掌握你写的所有方面,因此将是通用评论.我希望它至少与你提出的问题有关.我写的时候它变成了一个博客.

对我来说,MSI补丁对2种基本场景有效:

1. 您使用次要升级修补程序修复了已安装产品的卸载顺序中的错误.
2. 您为一些文件提供了一个次要的升级修补程序,作为已发布产品的" 修补程序 ",重新安装可能会非常耗时且耗时.

出于这两个目的,我已经多次专业地使用MSI修补.在每种情况下都没有其他好的解决办法.修补IMHO用于"修复" - 它是整个技术的设计目的,而不是用于频繁的增量更新的部署.提供96个文件更新不是修补程序.

补丁是一种工作升级:请记住,补丁只是一种更紧凑的传输机制,适用于已经可以运行的升级.它可以是主要的,次要的甚至是小的更新,每个更新都会有所不同.在您完成任何其他操作之前,请确保在尝试将其打包为补丁之前测试实际的完整升级MSI.这是我能给你的最佳建议.如果完全升级无法正常运行,则会浪费所有用于修补的工作.是的,这包括在制作补丁之前在所有交互中安装,卸载和升级.这可能是所有人中最常见的修补错误.

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

修补和自定义操作条件:对我来说,修补的最糟糕方面之一是,在执行修补程序操作而不是正常安装时,程序包中的自定义操作可能无法正常调整到不运行.修补程序具有特定于修补程序的属性,如PATCH和MSIPATCHREMOVE.在自定义操作上使用这些条件,以使它们在修补程序期间运行或不运行,具体取决于所需的操作.小心自定义操作的条件,它们很难做到正确.这是一个" MSI条件备忘单 ",以帮助您.我没有测试过这些条件 - 测试是唯一的保证.

一些进一步的补丁建议:

• 我会完全忘记主要的升级补丁.我尝试过它们,并会再次尝试它们,但它们往往不太理想.主要升级补丁的绝对要求是,InstallExistingProducts放在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.