Windows Installer "Error 1308. Source file not found" when removing a patch in a sequence script

Question

I need 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 it was removed when patch 1 and / or patch 2 has already been applied, causes 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 such errors for different files. There is no clear picture for files or components, or there are functions

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

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

My questions:

• Why does this only happen if a series of patches are installed, and not just the third patch?

• What do I need to do to prevent the removal of the patch, in order to try to extract the files from a location that should be only for development time when creating the patch? Or maybe it's a design sample, but the cache is too overloaded or confused ...

UPDATE - MORE INFORMATION (at the request of Glytzhkof): The patch contains 96 file changes, which is approximately half the size of the basic MSI package. In fact, this is due to the work of the "Dev" branch. Added a few new files. Some of them were initially removed (I had to return them when I discovered that we really did the patch ...). If I described the situation in more detail, this may offend you as a professional in this field.

I'm trying to sell Major Upgrade, and the installer will need only a few settings to save the user from the need to fix it. Removing our product requires a parameter to be non-interactive (we need this parameter to work in the Major Upgrade script, currently it is only part of the Uninstall sequence). This is the only real problem, but fixing it will be paid for by peaks. However, it was decided not to correct this issue. I try to pounce on each iteration. No dice. We need fixes for the major releases that they tell me about, so I'm trying to get a tail to swing my dog.

And yes, patches can be faster (let me play the devil's advocate here). But is there really a difference between 30 and 90 seconds when all this is automatically deployed? And yes, I also thought about finding ways to optimize the installer with adjusting the value of the file to make sure that it does it faster, but even then I’m sure there will be another reason why the patch will be fixed.

OTHER UPDATE: files mentioned in 1308 errors are not in the target system %windir%Installer\$PatchCache$\Managed\{PackedProductCodeOfMyBaseMSI??}

folder. This can cause 1308, because if I delete more files from this cache, I get the same error as the missing file. The question may be, why not ALL the file in this PatchCache folder?

Answer 1

I'm still looking for a solution, or at least some guidance, even though I agree that it goes beyond the usual good practices. - jJack 1 hour ago

I do not have access to my deployment tools, but I will try to present a perspective. Since I do not fully understand all aspects of what you write, there will be general comments. Hope this is at least related to what you are asking. He turned into a blog, as I wrote.

For me, the MSI patch is effective for 2 main scenarios :

• You fix the error in the uninstallation sequence of the installed product with a small update patch.
• You are delivering a small patch for several files as a “ patch ” for the released product, which can be huge and time-consuming to reinstall.

For these two purposes, I have used MSI fixes effectively professionally several times. In each case, there was no other good fix. The IMHO fix for a “fix” is what the whole technology is for, and not for deploying frequent, incremental updates. . Providing updates for 96 files is NOT ./p>

A patch is an update to work . Remember that a patch is just a more compact delivery mechanism for an update that already works. This can be a major, minor, or even minor update, and each will work differently. Before doing anything else, make sure you check the actual full MSI update before attempting to pack it as a patch. This is the best advice I can give you. All efforts spent on the correction are lost if the full update does not work correctly. And yes, this includes installing, uninstalling and updating in all interactions before making the patch itself. These are perhaps the most common bug fixes for everyone.

There are several barriers to removing a patch . There are dozens of technical issues that can lead to the removal of fixes (recommended reading). This is a huge problem from time to time because the patch that deployed the patch can be found defective and therefore must be completely discarded. In my opinion, this is one of the main uses of the small patch - deploy a quick fix, which can then be thrown back.

Patch conditions and user actions : for me, one of the worst aspects of the fix is ​​that user actions in packages may not be properly processed so as NOT to be triggered when a patch operation is performed, rather than a normal installation. A patch has patch properties such as PATCH and MSIPATCHREMOVE . Use these conditions for custom actions so that they start or do not start during the patch, depending on what you need. Be careful with the conditions of user actions, they are difficult to get right. The following is the " MSI Conditions Barcode " to help you. I have not tested these conditions - testing is the only guarantee.

Some additional troubleshooting tips :

• I would forget the basic fixes for the update. I tried them and will try them again, but they are usually not perfect. Absolute requirement for the main fix for the update is that RemoveExistingProducts is placed after InstallFinalize in InstallExecuteSequence. The reason for this is that otherwise the files will be deleted before the fix pack attempts to fix the existing files. Enough to catch 22.
• a minor update does not remove the existing installation, but rater re-caches the new MSI file for use in maintenance and uninstall operations. This means that a patch can fix the removal sequence before it is launched - one of the best fixes that I mentioned above. In fact, if a minor update works, a fix may not be necessary at all. Just use a minor update if your MSI file is not very large and you want to provide a small “fix”.
• If you need to include files in your patch, I recommend including " include whole files ". Otherwise, a bit-level fix is ​​performed, and this is unnecessary complexity (unless your binaries are huge).
• Include only what you need in the patch. Do not add 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: remember that a patch uses the same InstallExecuteSequence installation as a regular installation, but you can customize user actions differently using patch specific properties such as PATCH and MSIPATCHREMOVE . Use these conditions for custom actions so that they start or do not start during the patch, depending on what you need.
• The reference to the components must be 100% correct for any type of patch to work.
• Minor patch updates should be launched with the appropriate msiexec.exe command line to work if they are not supplied through the setup.exe / update.exe file.
• Third-party merge modules often lead to patch problems in my experience.
• Versions "as they call it - the black art of providing files is always updated by adding another version to the MSI file for the file on disk, it seems to cause fix errors.
• The patch will show the same graphical interface as the main installation. In my opinion, this is an erroneous design. User actions in the GUI can ruin the repair process.
• I believe that every patch should be cumulative - replacing all previous patches. I never got this working properly when I tested several patches installed sequentially and sequentially. For many reasons, I came to the conclusion that there was a useless approach to fixing it . I had problems exactly according to what you describe with patch families, target versions, etc. The patch is not too smart, it's just a complex package of several files trying to find the product to which it belongs.

The obvious thing is that I really do not recommend you go with this correction method, even when asked. However, I read this thread , which seems to indicate a successful fix for those who switched to using WIX instead of Installshield. You should also check out the CodeProject link.

As for your deployment scenario , I don’t fully understand all its aspects, but it seems like the developers want the patches to convert the direct application into the current version of QA through the patch? I would never agree with this, or the script should be different from how it sounds. The completely wasted effort to create the patch, when you should already perform small or large updates in the first place - they are more than enough to deliver software to ensure quality. You can use the dev branch to provide a separate MSI, and then create some patches and then check that the product is a patch, but I would never use patches to deliver the installers of your product from the inside. I do not know if you asked about this.

Work with small and large updates - it is advisable that the latter are not fixed, and deliver the patch when you really need it. If installation time is a problem, can you just schedule a major daily update after completing the nightly build on all development PCs and QAs? (including killing any running processes necessary for the installation to work). I don’t know if I will fully track what your scenario really is.

Check out Stefan Kruger installsite.org for additional updates and fixes.

Check out this famous wix tutorial for updates and fixes. And MSDN .

Answer 2

I will need to add this as an answer as it is too long for a comment. 200 file changes? I assume that the cost of the file will take longer than installing a small update. If I were you, I would refuse to provide such patches. They inevitably fail, with almost 100% certainty due to the complexity of the technology. Remember that the MSI patch is just a delivery mechanism for an already running update, basically just an added risk and complexity. It really is.

MSI patches are complex and registered for verification and deletion - they do not just reset and patch files, as in the world before MSI. If the user needs a fix, I would go for a different solution than MSI in general.

Can you describe the script a little better? I find that automated build processes that provide basic updates are very useful for daily QA builds. If installation speed is a problem, you can use methods to speed things up, such as enabling MSIFASTINSTALL . Using this property, you can say that the system performs less heavy and time-consuming operations, such as creating a system restore point and carefully calculating files (comparing installed and installed files and directory sizes).

Answer 3

I would look at any of the support articles about this error, of which there are several. In some cases, they may be product specific, but may indicate an error (for example, administrative installations or errors in the Windows installer). You may already have done this.

Otherwise, these problems tend to occur when patch replacement settings are incorrect. If you somehow said that one of the patches replaces the other, then by definition it includes all changes to the patch from earlier patches. Since this involves scrolling with guides in different places, the change may have been skipped if the same base PCP file was used, although I'm not sure how much IS provides or hides it all. The end result will be that Windows will think that other patches are no longer needed and will remove them. This can help:

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

Answer 4

The addressing of this recommendation is too long for comment, therefore:

Caching a copy of the actual MSI installation locally has always been a good idea (searching for Tao rules for Windows Installer) in case of repair, adding functions, etc., but the Heath article is about 5.0 changes in the internal cached MSI file which is not the same. IS may say “keep a copy of the actual MSI file,” Heath simply describes the internal modification of the “secret” cached MSI file, but the internally cached MSI is not considered a valid source. Make sure they are cached. I think they mean that you should keep a copy of the actual MSI available during installation.

I assume that IS sees the main problem not so much as the missing patch, but as Windows, which requires restoring the source files when the patch is deleted, so if the msp file is not available, it can get it from the original virtual MSI file, which consists of the source plus patches . If you are using the cached MSI IS parameter, I assume that it copies the MSI file somewhere and sets it there or otherwise makes this location a valid source. If it is necessary to restore files when the patch is deleted, their analysis is that it can be done (automatically?), Using (basic MSI + any applicable fixes) to restore previous files. I am trying to read the mind from your brief comment, and perhaps this helps, although I am sure that I do not have absolutely accurate information.