installshield - Windows Installer "Error 1308. Source file not found" when uninstalling patch in sequence scenario

Question

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?

Answer 1

I am still looking for a solution or at least some guidance, even though I agree that this is outside of normal good practices. – jJack 1 hour ago

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.