Major Upgrade troubles
Lets start with a history, as the situation is a little non-standard. All of the versions I refer to here are Vendor MSIs transformed for unattended install. All versions are for the same app, vendor doesn't know MSI versioning so we add versioning & upgrade info in the transforms.
Version 1 deployed, no problems.
Version 2 deployed as major upgrade to Version 1 (removes v1 during install), no deployment problems.
Version 2 had a problem in the vendor MSI, the Crystal Reports runtime included by the vendor was not compatible with their app. It got past testing because it was tested with v1 also installed, which had a compatible version. As an emergency fix, v1 was redeployed (this was before the problem was pinned down to crystal reports).
Now I have v3, the transformed install works on its own but I can't get it to remove v1 & v2. Tried adding v1 & v2 to the upgrade table, they're still there. I do this often so I'm pretty sure I'm doing it the right way. Tried nesting an MSI install w/ REMOVE=ALL in Execute Immediate just after CostFinalize, this fails with Error 2335 (Path: [InstallDir] is not a parent of C:\Windows\Installer). No luck there.
Any ideas why I can't get v3 to remove v1 & v2? 1 & 2 install to different directories, so there's no overlap other than possibly System32 stuff... I just dunno why it dunt work. Uninstalling via MSIEXEC /x [Product Code] works, but I'd rather not use a .cmd script as it doesn't fit well into our distribution system. No good confirmation of success/failure.
Version 1 deployed, no problems.
Version 2 deployed as major upgrade to Version 1 (removes v1 during install), no deployment problems.
Version 2 had a problem in the vendor MSI, the Crystal Reports runtime included by the vendor was not compatible with their app. It got past testing because it was tested with v1 also installed, which had a compatible version. As an emergency fix, v1 was redeployed (this was before the problem was pinned down to crystal reports).
Now I have v3, the transformed install works on its own but I can't get it to remove v1 & v2. Tried adding v1 & v2 to the upgrade table, they're still there. I do this often so I'm pretty sure I'm doing it the right way. Tried nesting an MSI install w/ REMOVE=ALL in Execute Immediate just after CostFinalize, this fails with Error 2335 (Path: [InstallDir] is not a parent of C:\Windows\Installer). No luck there.
Any ideas why I can't get v3 to remove v1 & v2? 1 & 2 install to different directories, so there's no overlap other than possibly System32 stuff... I just dunno why it dunt work. Uninstalling via MSIEXEC /x [Product Code] works, but I'd rather not use a .cmd script as it doesn't fit well into our distribution system. No good confirmation of success/failure.
0 Comments
[ + ] Show comments
Answers (10)
Please log in to answer
Posted by:
kkaminsk
18 years ago
I know this is going to sound lame but did you turn on the MSI logging to get some insight as to why the upgrade codes are not doing anything?
Posted by:
brenthunter2005
18 years ago
I was going to suggest the same thing.
After checking the logs, you may want to doublecheck the Upgrade table again for languages etc...
Also, doublecheck that the RemoveExistingProducts action exists in your MSI and that its placed after InstallValidate around the top in the InstallExecute sequence.
Let us know how you get on with this, as I have also experienced 'issues' like these before and they really pi$$ me off!
After checking the logs, you may want to doublecheck the Upgrade table again for languages etc...
Also, doublecheck that the RemoveExistingProducts action exists in your MSI and that its placed after InstallValidate around the top in the InstallExecute sequence.
Let us know how you get on with this, as I have also experienced 'issues' like these before and they really pi$$ me off!
Posted by:
VikingLoki
18 years ago
Yeah, I took a verbose log. Can't find any check occurring at all.
RemoveExistingProducts is there and in the right location. (Had a glimmer of hope on that one, didn't check it)
Checking the Upgrade table, all were set to migrate feature states but I'm sure I didn't have that selected in the editor. Fixing that didn't solve anything.
Wise also set the Action Property to Upgrade_1 and Upgrade_2. The only other reference to that is in the Property Table, SecureCustomProperties = Upgrade_1;Upgrade_2. Is that right? Seems a little sparse.
RemoveExistingProducts is there and in the right location. (Had a glimmer of hope on that one, didn't check it)
Checking the Upgrade table, all were set to migrate feature states but I'm sure I didn't have that selected in the editor. Fixing that didn't solve anything.
Wise also set the Action Property to Upgrade_1 and Upgrade_2. The only other reference to that is in the Property Table, SecureCustomProperties = Upgrade_1;Upgrade_2. Is that right? Seems a little sparse.
Posted by:
VikingLoki
18 years ago
This is all I get in the log.
(UNKNOWN) Action start 12:05:57: RemoveExistingProducts.
(SERVER) MSI (s) (D0:B4) [12:05:58:334]: Doing action: AddProgressTime2.A95D0BB4_0582_442D_B456_D295EAEB7628
(UNKNOWN) Action ended 12:05:58: RemoveExistingProducts. Return value 1.
(UNKNOWN) Action start 12:05:57: RemoveExistingProducts.
(SERVER) MSI (s) (D0:B4) [12:05:58:334]: Doing action: AddProgressTime2.A95D0BB4_0582_442D_B456_D295EAEB7628
(UNKNOWN) Action ended 12:05:58: RemoveExistingProducts. Return value 1.
Posted by:
aogilmor
18 years ago
Viking, what I've had work (YMMV) is when you add the upgrade, don't even specify a minimum version and enter a maximum version that's very high (say 100). Check both boxes that say include maximum and min. versions. This takes care of the "unversioned" problem.
Also, sequence can be important.
Try moving the standard action RemoveExistingProducts higher up in the Execute Immediate sequence, before the current version starts installing.
Hope this helps.
Also, sequence can be important.
Try moving the standard action RemoveExistingProducts higher up in the Execute Immediate sequence, before the current version starts installing.
Hope this helps.
Posted by:
AngelD
18 years ago
Well you can't be sure if the vendor MSI has all sequences and Standard CA. Create a dummi MSI with any resource and add the v1 & 2 as upgrades to the dummy MSI. If that works you'll need to find the required CA and it's sequence order to fix this in the vendor MSi.
Posted by:
VikingLoki
18 years ago
No luck with those tricks either. I know this vendor isn't doing anything fancy, they're just happy they have an MSI install at all, really. I do know it's an InstallShield created MSI and it does seem to have a bunch of CAs inserted by InstallShield. (The vendor definitely didn't do it.)
Posted by:
MSIPackager
18 years ago
How about you try repackaging App3 instead of using the vendor msi... see if the upgrade works then. Nothing to lose if it's not a tricky app [;)]
Posted by:
Ilikebananas
18 years ago
Hi Vikingloki,
The action doesn't take very long to complete. Can you see what happens to the FindRelatedProducts action and the properties is sets? Perhaps that provides more info... [&:]
Ilikebananas
ORIGINAL: VikingLoki
This is all I get in the log.
(UNKNOWN) Action start 12:05:57: RemoveExistingProducts.
(SERVER) MSI (s) (D0:B4) [12:05:58:334]: Doing action: AddProgressTime2.A95D0BB4_0582_442D_B456_D295EAEB7628
(UNKNOWN) Action ended 12:05:58: RemoveExistingProducts. Return value 1.
The action doesn't take very long to complete. Can you see what happens to the FindRelatedProducts action and the properties is sets? Perhaps that provides more info... [&:]
Ilikebananas
Posted by:
VikingLoki
18 years ago
Perhaps it will...
(SERVER) MSI (s) (E4:F4) [16:04:19:313]: FindRelatedProducts: current install is per-machine. Related install for product '{A0F97EA3-9BAE-49D4-A5D0-E5C266CB5BB0}' is per-user. Skipping...
[:@] Son of a $%$#@!!!! [:@]
The kicker is that our distribution system asserts per-machine installs... and I wasn't using it!
How did that package get to production defaulting to Per-User anyway?!?!
...excuse me whilst I raid QA Team's cubicles like they're a European coastal monestary.
(SERVER) MSI (s) (E4:F4) [16:04:19:313]: FindRelatedProducts: current install is per-machine. Related install for product '{A0F97EA3-9BAE-49D4-A5D0-E5C266CB5BB0}' is per-user. Skipping...
[:@] Son of a $%$#@!!!! [:@]
The kicker is that our distribution system asserts per-machine installs... and I wasn't using it!
How did that package get to production defaulting to Per-User anyway?!?!
...excuse me whilst I raid QA Team's cubicles like they're a European coastal monestary.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.