ActivePerl - RemoveExistingProduct missing
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).
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
Answers (4)
Please log in to answer
Posted by:
pjgeutjens
13 years ago
Posted by:
dreyer
13 years ago
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
Posted by:
darkfang
13 years ago
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.
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.
Posted by:
dreyer
13 years ago
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.

so that the conversation will remain readable.