Patches can be built but do not update previous installs (for large installs?)

[abreed]

Hello,

I have a program that is a 10GB install and contains over 40,000 files. Originally, in InstallShield 2010 I was getting the error ‘-6415 package that includes more than 32,767 files’ when trying to build a patch and I noticed that was fixed with 2011/2012. I am now using 2012 and still experiencing some issues building a patch.

What we changed between '1.5' and '1.0' was an update to a handful of dlls and we also added a few new model/texture/jpeg files. Using the Patch Design, I pointed to the two setups of the software (both were originally compressed, but the Patch Design uncompressed them) and tried to build the patch. This resulted in another -6415 error, but this time with no information.

After reading though old forum postings for suggestions, I successfully built the patch by unchecking ‘Use default patch sequencing’ under Patch Configuration -> Sequence (I added nothing to the Family Name table).

As I would expect, the patch built into a 35MB Update.exe, which is close to the size of the files that are new/changed.

Now, when executing the patch on our test environment, the patch opened, and ran as expected, but no files were updated/changed and the new files were not added. The version number inside Add or Remove Programs was also not updated. Just to debug, I tried to patch an empty folder and nothing was added to that empty folder.

I looked through the PatchCreation.log and the Patch Design is noticing the files it should add and files it should update.

Some other options that might be of interest, Include Whole Files is set to Yes, and Optimize Path for Large Files is unchecked. I have tried variations on all settings.

The package/product codes of the latest and previous setups are different, while the upgrade codes are the same.

We are using InstallShield 2012 Professional.

Any ideas why the patch would be doing nothing to a previous install? How can I debug this further?

[Cary R]

Hi There,

I would take a look at the patch installation logfile, which you can create via the MSI logging policy, or something like:

update.exe /v"/l*v c:\patch.log"

If MSI is rejecting the transforms inside the patch, it'll say why. Although, typically you get an error dialog indicating a problem.

[abreed]

Enabled logging through the registry and reviewed the log file. It seems that it thinks it is doing everything correctly. The end of the output is:

MSI (c) (34:A4) [13:28:15:102]: Product: XXX - Update 'XXX' installed successfully.

MSI (c) (34:A4) [13:28:15:102]: Windows Installer installed an update. Product Name: XXX. Product Version: 1.5.3334.0. Product Language: 1033. Manufacturer: XXX. Update Name: XXX. Installation success or error status: 0.

MSI (c) (34:A4) [13:28:15:102]: Note: 1: 1707
MSI (c) (34:A4) [13:28:15:102]: Product: XXX -- Installation operation completed successfully.

MSI (c) (34:A4) [13:28:15:102]: Windows Installer installed the product. Product Name: XXX. Product Version: 1.5.3334.0. Product Language: 1033. Manufacturer: XXX. Installation success or error status: 0.

MSI (c) (34:A4) [13:28:15:117]: Grabbed execution mutex.
MSI (c) (34:A4) [13:28:15:117]: Cleaning up uninstalled install packages, if any exist
MSI (c) (34:A4) [13:28:15:117]: MainEngineThread is returning 0

Still, no luck figuring out why it is not working. Anything I should look for? Any other ideas?

[Cary R]

Take a look for lines early on the log talking about "Patch Sequencing" or "Patch Transforms".

Also, take a look at the InstallValidate section. If you broke component rules (which is the most common cause of this) you'll see the behavior described in this article:

http://kb.flexerasoftware.com/selfservice/viewContent.do?externalId=Q200372

[abreed]

Take a look for lines early on the log talking about "Patch Sequencing" or "Patch Transforms".

I do not notice any errors:

MSI (c) (60:60) [08:17:14:614]: Validating transform 'Prev1ToLatest1' with validation bits 0x880
MSI (c) (60:60) [08:17:14:614]: Transform 'Prev1ToLatest1' is valid.
..
MSI (c) (60:60) [08:17:14:833]: Validating transform 'Prev1ToLatest1' with validation bits 0x880
MSI (c) (60:60) [08:17:14:833]: Transform 'Prev1ToLatest1' is valid.
..
MSI (c) (60:60) [08:17:15:880]: Baseline: Patch {D813D775-2336-4262-9F87-13E1C4E1E3E4} modified xxx.dll with full-file update.
MSI (c) (60:60) [08:17:15:880]: Baseline: First patch for xxx.dll, saving native info.
MSI (c) (60:60) [08:17:15:880]: Baseline: xxx.dll version for baseline at patch Native: , , 312832.



Also, take a look at the InstallValidate section. If you broke component rules (which is the most common cause of this) you'll see the behavior described in this article:

http://kb.flexerasoftware.com/selfservice/viewContent.do?externalId=Q200372

It looks okay to me, here is an example:

MSI (s) (04:64) [08:23:54:191]: Component: xxx.dll; Installed: Absent; Request: Null; Action: Null; Client State: Unknown

Nothing in the log about cases 2 or 3 in the kb link you posted. Not sure why it is saying the Component installed is Absent though...

[Cary R]

What I might do at this point is to add a Minor Upgrade item in your InstallShield project, and point it to your baseline setup. Then, build the new full MSI package you're using as the Latest version in the Patch config.

This likely will crop up one or more critical upgrade issues, and will be quicker than digging through the log more. Post what the results of this are, and hopefully we can make sense of it.