ActivePerl .msi don't have the RemoveExistingProduct row in the InstallExecuteSequence. I add it and insert the previous version information in the Upgrade table but the previous version won't uninstall

Log :
MSI (s) (20:10) [09:36:45:720]: Doing action: RemoveExistingProducts
Action start 9:36:45: RemoveExistingProducts.
Action ended 9:36:45: RemoveExistingProducts. Return value 1.

Yes, I can do a script (vbs) to uninstall previous version and install new version but i would like to have all in one script (.msi).
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
Did you remember to add the ActionProperty from the upgrade table to the SecureCustomProperties?
Answered 09/24/2009 by: pjgeutjens
Red Belt

Please log in to comment
0
ORIGINAL: darkfang

ActivePerl  .msi don't have the RemoveExistingProduct row in the InstallExecuteSequence. I add it and insert the previous version information in the Upgrade table but the previous version won't uninstall

Log :
MSI (s) (20:10) [09:36:45:720]: Doing action: RemoveExistingProducts
Action start 9:36:45: RemoveExistingProducts.
Action ended 9:36:45: RemoveExistingProducts. Return value 1.

Yes, I can do a script (vbs) to uninstall previous version and install new version but i would like to have all in one script (.msi).


Hello darkfang!

In a few instances I've experienced problems with packages not being upgraded even though everything appears to be configured correctly. I've not uncovered the reason why despite considerable testing. This is something I'll probably try to go indepth on in the future.

However, I have found a nice workaround.

In my cases the reason the Upgrade has not worked is because the action responsible for finding the Product Code for the previous version, FindRelatedProducts, fails to do so.

If I were you I would first check that FindRelatedProducts under InstallExecuteSequence does not have a condition that prevents it from running. If it does not proceed with my workaround.

I assume you know the product code of the version you're trying to uninstall, in this case you can create a Custom Action and trick Windows Installer.

I did it like this:

Create a new custom action called FindRelatedProductsCustom (or whatever):


VBScript:
On Error Resume Next
Set Installer = CreateObject("WindowsInstaller.Installer")

ProductOldVersion = Installer.ProductState(OldVersionProductCode)

If ProductOldVersion = 5 then
Session.Property("UPGRADE_1") = OldVersionProductCode
End If


UPGRADE_1 is the upgrade ActionProperty that stores the product code for RemoveExistingProducts. You can change this to whatever you want to use.

PS: Remember to check that RemoveExistingProducts is sequenced after FindRelatedProductsCustom.

Add the custom action to the InstallExecuteSequence table:



I use the PrintProp action on my first test installs to just make sure the product code is right in case something else goes wrong. This action is set to condition 0 afterwards.

Also remember that the Upgrade table still has to be configured and the ActionProperty has to be listed under SecureCustomAction property.



Hope this helps,
dreyer
Answered 09/24/2009 by: dreyer
Purple Belt

Please log in to comment
0
Wow! Thanks pjgeutens and dreyer!

I did forget the SecureCustomProperties in the Property Table and I didn't know about FindRelatedProducts.

FindRelatedProducts under InstallExecuteSequence was missing and once I add it, the uninstallation kick in.

On a side note, even if the SecureCustomProperties is missing, the previous version got uninstalled anyway.
Answered 09/24/2009 by: darkfang
Blue Belt

Please log in to comment
0
ORIGINAL: darkfang
On a side note, even if the SecureCustomProperties is missing, the previous version got uninstalled anyway.


I think the only purpose of SecureCustomProperties is to lock down the PUBLIC property so that no Custom Action or a user launching the installation without elevated privileged can set it to something else via the command line that could mess things. I would take my explanation with a grain of salt, however.
Answered 09/24/2009 by: dreyer
Purple Belt

Please log in to comment
Answer this question or Comment on this question for clarity