Upgrade not recognized

[befish]

Hello,

I have recently upgraded from IS2008 to IS2010. I have a product that had been created as an InstallScipt MSI project in IS2008 and was re-created as a BASIC MSI project in IS2010. (we changed project types as we would like to have multiple instance support in the future, something we have not implemented as yet) The package code, product version, and product codes are different between the two projects, and the upgrade code is the same.

In the 2010 version I have the Major Upgrade set to completely uninstall prior to installation, however, the uninstall is not happening.

What do I need to do to get the 2010 version to recognize a previous version and uninstall?

Thanks,

[RobertDickau]

If you create a log file while installing the newer version, and then search around FindRelatedProducts and ISSetAllUsers, is there any more information?

[befish]

Thanks for the reply. I didn't find what you mentioned. Here is what seems to be the relevant portion of the log.

8-7-2009[08:33:21 PM]: InstallShield setup.exe (Unicode) started, cmdline: /debuglog
8-7-2009[08:33:21 PM]: Extracting setup.ini...
8-7-2009[08:33:21 PM]: Extracting 'Setup.INI' to C:\Users\develop\AppData\Local\Temp\{F--}\Setup.INI
8-7-2009[08:33:21 PM]: Extracting '0x0409.ini' to C:\Users\develop\AppData\Local\Temp\{F--}\0x0409.ini
8-7-2009[08:33:21 PM]: Reading setup.ini from C:\Users\develop\AppData\Local\Temp\{F--}\Setup.INI
8-7-2009[08:33:21 PM]: Upgrade check: checking product code {074--}
8-7-2009[08:33:21 PM]: Extracting...

The product code is the product code of the 2010 project. I would have thought it would look for the upgrade code, since that is what stays the same, right?

We did change the Product Name- is that what's throwing us off?

[RobertDickau]

Perhaps try setup /V"/L*v C:\everything.log" and then search for those action names? A major upgrade looks like a first-time installation, but later the RemoveExistingProducts action normally removes any products detected by the FindRelatedProducts action; so the initialization info from setup.exe wouldn't show the major-upgrade detection.

[befish]

Ok, thanks. I'll try that on Monday.

[KathyMorey]

Also keep in mind that the RemoveExistingProducts uninstall from new project will run only the MSI portion of the old one, as it won't have access to the script engine. So if you had any actions performed by the script in the old one, like removing registry keys or shortcuts, they won't get performed. Also, if your uninstall depends on any properties set by the script, it could have an issue.

We have had scenarios where we had to run the uninstall of an InstallScript MSI by accessing and running the uninstall command line from the registry to get the older version to properly uninstall. This brings up its own additional issues because it cannot be done from within the execute sequence of the new product. I can give you more details from our experiences if this turns out to be applicable for you.

[befish]

Ok, I did it again with the verbose logging. Nothing for the ISSetAllUsers. for FindRelatedProducts I get:

MSI (c) (88:68) [09:56:03:195]: Doing action: FindRelatedProducts
Action 9:56:03: FindRelatedProducts. Searching for related applications
Action start 9:56:03: FindRelatedProducts.
Action ended 9:56:03: FindRelatedProducts. Return value 1.
MSI (c) (88:68) [09:56:03:196]: Skipping action: ISPreventDowngrade (condition is false)
MSI (c) (88:68) [09:56:03:196]: Skipping action: CCPSearch (condition is false)
MSI (c) (88:68) [09:56:03:196]: Skipping action: RMCCPSearch (condition is false)


and then later on I see:

MSI (s) (BC:30) [09:56:19:198]: Doing action: FindRelatedProducts
Action 9:56:19: FindRelatedProducts. Searching for related applications
Action start 9:56:19: FindRelatedProducts.
MSI (s) (BC:30) [09:56:19:200]: Skipping FindRelatedProducts action: already done on client side
Action ended 9:56:19: FindRelatedProducts. Return value 0.
MSI (s) (BC:30) [09:56:19:200]: Skipping action: ISPreventDowngrade (condition is false)
MSI (s) (BC:30) [09:56:19:200]: Skipping action: CCPSearch (condition is false)
MSI (s) (BC:30) [09:56:19:200]: Skipping action: RMCCPSearch (condition is false)
MSI (s) (BC:30) [09:56:19:200]: Doing action: ValidateProductID

[befish]

So I added another upgrade item and now it knows it is a related product, but it still doesn't remove the previous version.

Action 14:08:21: RemoveExistingProducts. Removing applications
Action start 14:08:21: RemoveExistingProducts.
MSI (s) (98:28) [14:08:21:158]: Skipping RemoveExistingProducts action: current configuration is maintenance mode or an uninstall
Action ended 14:08:21: RemoveExistingProducts. Return value 0.

Any thoughts on why it would think it is a maintenance or uninstall?

[befish]

Previously we had a min version specified of 000.000.000, when I added that it behaves the same, but then manual install from add/remove programs breaks.

[befish]

Latest test. I made a fake version 3, changed name, package code, version, product code. version 2->3 upgrades fine, removes v2 from add/remove programs. v1->v3 fails to remove add/remove programs entry.

I think there is a bug updating an Installscript MSI install generated in IS2008 to a Basic MSI generated in IS2010. It repeatedly considers itself to be in maintenance mode, but only when upgrading from the v1, not from v2->v3.

[StYerk]

Hi,

do you have any new informations on this issue or any workarounds?

I am currently experiencing a similar problem, I think caused by the same defect:

We have two variations of our software (different UpgradeCodes) that may not coexist on the same computer. So I use the Upgrade table to recognize the other variant, respectively, and set a property;
Based on this property the installation stops, if the installer of one variant finds an instance of the other.

Our last product version had been created with Installshield 2008, and it worked just fine.
Now I am packaging our current version with Installshield 2010, having upgraded the Installshield projects with the IDE.
With the installer created by Installshield 2010, the same mechanism does not work any more, the installer does not detect the UpgradeCode specified in the Upgrade table, although it is there.

Seems a defect to me, too.

Do you have any news on this ?

Thanks in advance for any information,

Regards,
Jörg

[befish]

Unfortunately we never found a resolution and were forced to direct all our customers to uninstall the previous version manually. Didn't look good, and doesn't make management happy about Installshield.

[StYerk]

Thank you for your feedback...

Too bad, this.
I have contacted their support and entered an issue about that.
I will have to switch back to IS 2008 for our old release, that's really annoying.

Thanks again,

Regards,
Jörg

[joshstechnij]

If a major upgrade of an existing InstallScript MSI project is done using a Basic MSI project, the existing product will not be completely uninstalled due to how InstallScript MSI projects are implemented. As such, the steps provided in the following KB article are recommended for performing an upgrade after changing project types from InstallScript MSI to Basic MSI:
Q112578: HOWTO: Perform Major Upgrade of InstallScript MSI Project with Basic MSI

Also note that if a project is converted from InstallScript MSI to Basic MSI, the only upgrade path that can be used is a major upgrade. Small updates, minor upgrades, or any type of patches cannot be used until after a major upgrade from the old project to the new one has been performed.