/build/static/layout/Breadcrumb_cap_w.png

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.

0 Comments   [ + ] Show comments

Answers (10)

Posted by: kkaminsk 19 years ago
9th Degree Black Belt
0
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 19 years ago
Fifth Degree Brown Belt
0
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!
Posted by: VikingLoki 19 years ago
Second Degree Brown Belt
0
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.
Posted by: VikingLoki 19 years ago
Second Degree Brown Belt
0
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.
Posted by: aogilmor 19 years ago
9th Degree Black Belt
0
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.
Posted by: AngelD 19 years ago
Red Belt
0
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 19 years ago
Second Degree Brown Belt
0
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 19 years ago
3rd Degree Black Belt
0
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 19 years ago
Purple Belt
0
Hi Vikingloki,

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 19 years ago
Second Degree Brown Belt
0
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.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login

Share

 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ