Windows Installer“错误1308.找不到源文件".按顺序卸载补丁时

问题描述

我需要使用带有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，则卸载不会产生此错误.

我在补丁设计中创建了所有三个具有相同选项的补丁.我了解的唯一值得注意的区别是，补丁3包含的更改(文件更新)比前两个更多.我再说一遍:还有很多变化.

我的问题是:

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

2. 为了防止卸载修补程序以尝试从仅在设计时才构建修补程序的位置获取文件，我该怎么办?也许这是设计使然，但是缓存太重载或混乱了.??

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

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

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

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

上

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

解决方案

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

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

1. 您已修复带有次要升级补丁的已安装产品的卸载顺序中的错误.
2. 您为发布的产品提供了几个文件的次要升级补丁作为"修补程序"，该产品可能庞大且需要重新安装.

出于这两个目的，我已经在专业上有效地多次使用了MSI修补程序.在每种情况下，都没有其他好的解决方法. 修补IMHO用于修补程序"-这是整个技术的目的，而不是用于部署频繁的增量更新.传送96个文件更新不是否修补程序. /p>

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

存在许多障碍，无法卸载补丁程序. 有数十种技术问题可能导致可卸载补丁(建议阅读).有时这是一个巨大的问题，因为已发现部署了修补程序的修补程序有缺陷，因此应将其完全撤回.在我看来，这是一个小补丁的核心用途之一-部署一个快速修复程序，然后可以将其回滚.

修补程序和自定义操作条件:对我来说，修补的最糟糕方面之一是，与正常安装相反，在执行修补操作时，可能无法将软件包中的自定义操作适当地设置为不运行.修补程序具有特定于修补程序的属性，例如 PATCH 和 MSIPATCHREMOVE .在自定义操作上使用这些条件，以使其在补丁程序期间运行或不运行，具体取决于必要的条件.注意自定义操作的条件，这些条件很难正确处理.这是" MSI条件速查表"为您提供帮助.我还没有测试这些条件-测试是唯一的保证.

其他一些修补建议:

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

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

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

进行次要和主要升级-对于非补丁，最好是后者，并在真正需要时提供补丁.如果安装持续时间有问题，您可以安排在所有开发人员和QA PC上完成每晚构建后的每日主要升级吗? (包括终止安装所需的所有正在运行的进程).我不知道我是否完全不了解您的情况.

检查Stefan Kruger的 installsite.org 以获取更多升级和修补信息提示.

查看此著名的wix教程进行升级和修补.并且 MSDN .

I require a series of uninstallable patches created using Patch Design with Installshield 2012. The first two patches work fine when uninstalling. However, the third patch, if and only if uninstalled when patch 1 and/or patch 2 have already been applied, produce errors:

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.

There are 26 of these errors regarding different files. There isn't an obvious pattern to the files or the components, or there features

Note: If I only have patch 3 applied, uninstalling does NOT produce this error..

I created all three patches with the same options in Patch Design. The only noticeable difference I understand is that patch 3 contains many more changes (file updates) than the first two. Let me repeat: MANY more changes.

My questions are:

1. Why does this happen only in the case where the series of patches are installed, instead of just the third patch itself?

2. What do I have to do in order to prevent the patch uninstall to try to fetch files from a location which should only be for design-time when building the patch? Or perhaps this is fetching is by design, however the cache is just too overloaded or confused..?

UPDATE - MORE INFO (requested by Glytzhkof):The patch contains 96 file changes, which is roughly half the size of base MSI package. It is actually off of 'Dev' branch work. Several new files have been added. Some were originally removed (had to put them back when I found we really were doing a patch...). If I described the situation any more, it might offend you as a professional in the field.

I have been trying to sell the Major Upgrade, and it would take just a few tweaks to the installer to make it obsolete the need for patches. The uninstall of our product requires parameter in order for it to be non-interactive (we would need this parameter to work in Major Upgrade scenario, it is currently only part of the Uninstall sequence). That is the only real issue - but fixing it would pay in spades. It was decided not to fix that issue, however. I try to 'bump' that issue every iteration. No dice. We need patches for major releases I am told - so here I am trying to get the tail to wag the dog.

And yes, patches can be faster (let me play devil's advocate here). But really, the difference between 30 and 90 seconds, when these things are automatically deployed anyway? And yes, I have also considered finding ways to optimize the installer with adjusting the file costing to see if it makes it any faster, but even then I'm sure there will be another reason why a patch will be requested.

ANOTHER UPDATE: The files mentioned in the 1308 errors are not on the target system's %windir%Installer\$PatchCache$\Managed\{PackedProductCodeOfMyBaseMSI??}

folder. This could cause the 1308, because if I remove more files from this cache, I get same error corresponding to the missing file. The question could be, why aren't ALL the file's in this PatchCache folder?

解决方案

I don't have access to my deployment tools, but I will try to provide a perspective. Since I don't fully grasp all aspects of what you write it will be generic comments. I hope it has at least something to do with what you are asking. It turned into a blog as I wrote.

To me an MSI patch is effective for 2 basic scenarios:

1. You fix an error in the uninstall sequence of an installed product with a minor upgrade patch.
2. You deliver a minor upgrade patch for a couple of files as a "hotfix" for a released product that might be huge and time consuming to reinstall.

For these two purposes I have used MSI patching effectively professionally several times. In every case there was no other good fix. Patching IMHO is for "hotfixing" - it is what the whole technology is designed for, not for deployment of frequent, incremental updates. Delivering 96 file updates is NOT hotfixing.

A Patch is a Working Upgrade: Remember that patching is just a more compact delivery mechanism for an upgrade that already works. It can be a major, minor or even small update, and each one will work differently. Before you do anything else at all, make sure you test your actual full upgrade MSI before attempting to package it as a patch. This is the best advice I can give you. All effort spent on patching is wasted if the full upgrade isn't working correctly. And yes, this includes install, uninstall, and upgrading in all interactions before making the patch itself. This is perhaps the most common patching mistakes of all.

Several obstacles exist preventing the uninstall of a patch. There are dozens of technical issues that may result in uninstallable patches (recommended read). This is a huge problem at times, since a patch that has deployed a hotfix may be found defective and hence should be pulled back entirely. In my view this is one of the core uses of a little patch - deploy a quick fix that can then be rolled back.

Patching & Custom Action Conditions: to me, one of the worst aspects of patching is that custom actions in packages may not be conditioned properly to NOT run when a patch operation is being performed as opposed to a normal installation. A patch features patch-specific properties such as PATCH and MSIPATCHREMOVE. Use these conditions on custom actions to make them run or not run during a patch depending on what is necessary. Be careful with the conditions on custom actions, they are complicated to get right. Here is a "MSI Conditions Cheat Sheet" to help you. I have not tested these conditions - testing is the only guarantee.

Some further patching advice:

• I would forget major upgrade patches entirely. I have tried them, and will try them again, but they tend to be less than ideal. An absolute requirement for a major upgrade patch to work is that RemoveExistingProducts is placed after InstallFinalize in the InstallExecuteSequence. The reason for this is that otherwise the files are uninstalled before the patch package tries to patch the existing files. Quite catch 22.
• A minor upgrade does not uninstall the existing installation, but rater re-caches a new MSI file to use for maintenance and uninstall operations. This means the patch can fix the uninstall sequence before it is run - one of the good patch uses that I listed above. In fact if the minor upgrade works, a patch may not be necessary at all. Just use the minor upgrade unless your MSI file is enormously big and you want to deliver a small "hotfix".
• If you need to include files in your patch, I recommend enabling "include whole files". Otherwise bit-level patching is done, and this is unnecessary complexity (unless your binaries are enormous). I am also not sure how bit-level patching works with signed files and digital signatures.
• Include only what you need in a patch. Add no files or settings that are not required, and you can make a reliable patch. Avoid adding custom actions if at all possible.
• As already mentioned: be aware that a patch uses the same InstallExecuteSequence as a regular install, but you can condition custom actions differently with patch-specific properties such as PATCH and MSIPATCHREMOVE. Use these conditions on custom actions to make them run or not run during a patch depending on what is necessary.
• Component referencing must be 100% correct for ANY type of patch to work. No exceptions.
• Minor upgrade patches must be run with the proper msiexec.exe command line to work unless delivered via a setup.exe / update.exe.
• Third party merge modules frequently cause patching problems in my experience.
• "Version lying" as they call it - the black art of ensuring files are always updated by adding a different version in the MSI file for the file on disk seem to cause patching errors.
• A patch will show the same GUI as the main install. In my opinion this is erroneous design. Custom actions in the GUI could mess up the patching process (should you accept new user input for values for a patch?).
• I believe each patch should be cumulative - replacing all previous patches. I never got this working properly back when I tested several patches installed in series and sequence. I concluded, for many reasons, that this was a futile patching approach to begin with. I had problems exactly along the lines of what you describe with the patching families, target releases etc... A patch isn't too smart, it is just a complex bundle of a few files trying to find the product it belongs to.

The obvious thing to conclude is that I really don't recommend that you go with this patching approach, even when asked to. However, I read this thread which seems to indicate successful patching for someone who has converted to using WIX instead of Installshield. You should check out the CodeProject link too.

As to your deployment scenario - I don't fully grasp all aspects of it, but it sounds like the developers want patches to convert a live application into the current QA version via a patch? I would never go along with this, or the scenario must be different from what it sounds like. Totally wasted effort to create a patch when you already must deliver minor or major upgrades in the first place - they are more than enough to deliver software for QA. You could use the dev-branch to deliver a separate MSI and then create a few patches now and then to test that the product is patchable, but I would never use patches to deliver installers of your product internally. I don't know if that is what you are asked to do.

Work with minor and major upgrades - preferably the latter for non-patches, and deliver a patch when you really need it. If installation duration is an issue, you could just schedule a daily major upgrade happening after the nightly build is complete on all developer and QA PCs? (including killing any running processes required to make the install work). I don't know if I am totally off track with what your scenario really is.

Check Stefan Kruger's installsite.org for more upgrades and patching tips.

Check out this well known wix tutorial for upgrades and patches. And MSDN.

这篇关于Windows Installer“错误1308.找不到源文件".按顺序卸载补丁时的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！