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) and we're now testing the patch installers for 1.1.2.
The odd thing that 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:
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Patch transforms are being applied in an odd order
Started by
andrewcardy
, Jun 20 2012 16:57
1 reply to this topic
andrewcardy
-
- Full Members
- 2 posts
Posted 20 June 2012 - 16:57
| CODE |
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?!
I think that the incorrect ordering of the transforms is causing issues for us also. Since it thinks its incorrectly using the transform 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! Consequently, later on we get a line like this:
| CODE |
| Note: 1: 2715 2: myfile.dll |
Which I think indicates that the File key could not be found in the file table (because the 1.0.1 transform assumes it's there but just needs modifying (the 1.0 transform correctly adds it to the table, but of course, Windows Installer chooses not to use this transform!))
If anyone knows about this behaviour, or can point me in the right direction I'd very much appreciate it!
Thanks!
andrewcardy
-
- Full Members
- 2 posts
Posted 21 June 2012 - 14:22
I've answered my own question, you can find it here: http://stackoverflow...the-wrong-order (Sorry for the cross post)