This doesn’t seem to be causing an issue as yet, but it’s something I really want to understand.
Basically, we have four versions of our product: 1.0 (2.6.0.0), 1.0.1 (2.6.1.0), 1.1.1 (2.6.3.0) and 1.1.2 (2.6.4.0). We’re just testing the full and patch installers for 1.1.2.
The odd things we’re seeing is that when applying a patch from 1.0 -> 1.1.2, the log for the installer shows that it chooses to use the 1.0.1 -> 1.1.2 patch transform first, which to me is silly as there is a transform from 1.0 -> 1.1.2 it can use. The log is below:
SequencePatches starts. Product code: {A9206E66-68A6-4A64-8ECA-F96D2635FB33}, Product version: 2.6.0.0, Upgrade code: {58142252-3B0E-44CA-99EC-F9FB3C4D976E}, Product language 1033
MSI (c) (A4:18) [14:11:53:235]: PATCH SEQUENCER: verifying the applicability of minor upgrade patch C:\DOCUME~1\Testuser\LOCALS~1\Temp\{3E3C7709-FF95-48AF-8836-5D62996F0FD4}\[productname]112enu_x86.msp against product code: {A9206E66-68A6-4A64-8ECA-F96D2635FB33}, product version: 2.6.0.0, product language 1033 and upgrade code: {58142252-3B0E-44CA-99EC-F9FB3C4D976E}
MSI (c) (A4:18) [14:11:53:235]: PATCH SEQUENCER: minor upgrade patch C:\DOCUME~1\Testuser\LOCALS~1\Temp\{3E3C7709-FF95-48AF-8836-5D62996F0FD4}\[productname]112enu_x86.msp is applicable.
MSI (c) (A4:18) [14:11:53:245]: SequencePatches returns success.
MSI (c) (A4:18) [14:11:53:245]: Final Patch Application Order:
MSI (c) (A4:18) [14:11:53:245]: {1721243D-5A87-4972-9226-E87EE0B87A08} - C:\DOCUME~1\Testuser\LOCALS~1\Temp\{3E3C7709-FF95-48AF-8836-5D62996F0FD4}\[productname]112enu_x86.msp
MSI (c) (A4:18) [14:11:53:245]: {1721243D-5A87-4972-9226-E87EE0B87A08} - C:\DOCUME~1\Testuser\LOCALS~1\Temp\{3E3C7709-FF95-48AF-8836-5D62996F0FD4}\[productname]112enu_x86.msp
MSI (c) (A4:18) [14:11:53:245]: Machine policy value 'DisablePatch' is 0
MSI (c) (A4:18) [14:11:53:245]: Machine policy value 'AllowLockdownPatch' is 0
MSI (c) (A4:18) [14:11:53:245]: Machine policy value 'DisableLUAPatching' is 0
MSI (c) (A4:18) [14:11:53:245]: Machine policy value 'DisableFlyWeightPatching' is 0
MSI (c) (A4:18) [14:11:53:245]: Turning off patch optimization. {1721243D-5A87-4972-9226-E87EE0B87A08} patch is not authored to support it.
MSI (c) (A4:18) [14:11:53:245]: Looking for patch transform: 101enuTo112enu
... More stuff ...
MSI (c) (A4:18) [14:11:53:265]: Disallowing uninstallation of patch {1721243D-5A87-4972-9226-E87EE0B87A08} because it adds new entries to table CreateFolder
MSI (c) (A4:18) [14:11:53:265]: Note: 1: 2205 2: 3: PatchPackage
MSI (c) (A4:18) [14:11:53:265]: TRANSFORM: 'PatchPackage' table is missing or empty. No pre-transform fixup necessary.
MSI (c) (A4:18) [14:11:53:265]: TRANSFORM: Applying regular transform to database.
... More stuff ...
MSI (c) (A4:18) [14:11:53:265]: Looking for patch transform: 10enuTo112enu
DEBUG: Error 2748: Transform 10enuTo112enu invalid for package C:\WINDOWS\Installer\882d.msi. Expected product version <= 2.6.0.0, found product version 2.6.4.0.
1: 2748 2: 10enuTo112enu 3: C:\WINDOWS\Installer\882d.msi 4: 2.6.0.0 5: 2.6.4.0
MSI (c) (A4:18) [14:11:53:265]: Skipping validation for patch transform #10enuTo112enu. Will not apply because previous transform was invalid
MSI (c) (A4:18) [14:11:53:265]: Looking for patch transform: 111enuTo112enu
DEBUG: Error 2748: Transform 111enuTo112enu invalid for package C:\WINDOWS\Installer\882d.msi. Expected product version <= 2.6.3.0, found product version 2.6.4.0.
1: 2748 2: 111enuTo112enu 3: C:\WINDOWS\Installer\882d.msi 4: 2.6.3.0 5: 2.6.4.0
MSI (c) (A4:18) [14:11:53:265]: Skipping validation for patch transform #111enuTo112enu. Will not apply because previous transform was invalid
So why does it choose to apply the wrong transform first? I’m guessing it applies it anyway because when it gets to the correct transform, it knows the product version has been updated to 2.6.4.0.
I noticed that in the patch designer under the previous setups folder, the order is indeed 1.0.1, 1.0, 1.1.1. Surely this isn’t determining the order that Windows Installer runs the patch transforms?!
If anyone knows about this behaviour, or can point me in the right direction I’d very much appreciate it! 🙂
Thanks!
Update
I think it’s become a problem! 🙁 I think that the incorrect ordering of the transforms is causing issues when the File table is updated. Since it thinks it’s transforming from 1.0.1 -> 1.1.2, it assumes a row in the File table is there and just needs modifying, when really we’re transforming from 1.0 -> 1.1.2 and the row isn’t present in the table and needs adding!
Anyone got any thoughts?
The patch transform order was causing the issue I was experiencing!
It seems that by default, InstallShield will allow patch transforms to be installed on any version earlier than the version being patched to. In other words, all three of my transforms we’re valid in the eyes of Windows Installer to be used on my 1.0 installation on the target machine!
Why this is I have no idea! Who would want to apply a 1.0.1 -> 1.1.2 transform to a 1.0 installation?!?!?! Really??!?!?!
Anyway, the setting that should be used if you want to apply a transform to the version that the transform was built for (yeah, weird senario!), is to change the Version Relationship property when you select your previous setup and the advanced tab.
It needs to be changed to Previous Setup Version = Latest Setup Version. Oh, and don’t bother looking at the InstallShield description an explanation of this property as it’s completely wrong and misleading!
This change will now mean that Windows Installer will look for the correct transform for the given installed version (i.e. it’ll select the 1.0 -> 1.1.2 transform for the 1.0 install).
I honestly still can’t believe that this behaviour isn’t the default, and I’m shock and appalled at the completely misleading description Install Shield gives.
And breath….