RemoveExistingProducts after Upgrade not executing

[anom217]

I'm doing a major upgrade for a Basic MSI project. I have separate InstallShield projects for 32-bit and 64-bit versions. When I do the upgrade with the 32-bit MSI the existing version is correctly uninstalled at the end of the upgrade. However, in my 64-bit MSI the uninstall never occurs. Here is output from the log, where the RemoveExistingProducts phase occurs

Action ended 14:06:05: InstallExecute. Return value 1.
Action 14:06:05: RemoveExistingProducts. Removing applications
Action start 14:06:05: RemoveExistingProducts.
Action ended 14:06:05: RemoveExistingProducts. Return value 1.
Action 14:06:05: InstallFinalize. 
Action start 14:06:05: InstallFinalize.

So it's not performing the uninstall of the existing product, but earlier in the log it clearly detects a related product present on the system, which is why an upgrade occurs and not a new install.

Action start 14:02:10: ISSetAllUsers.
InstallShield 14:02:11: Begin SetAllUsers()
InstallShield 14:02:11: Getting records from Upgrade table
InstallShield 14:02:11: UpgradeCode: {063EB66F-DD06-4FB0-BAAA-693CD20AECD2}	MinVersion: 	MaxVersion: 1.0.1.2	Language: 1033	Attributes: 256
InstallShield 14:02:11: Checking related product {8552BF35-20B8-45D5-8660-B1051B45C9D1}
InstallShield 14:02:11: 	MyProduct 	   {8552BF35-20B8-45D5-8660-B1051B45C9D1}	1033	1.0.1.1	 ***Related***
InstallShield 14:02:11: ALLUSERS of related product {8552BF35-20B8-45D5-8660-B1051B45C9D1} is = 1
InstallShield 14:02:11: End SetAllUsers()
Action ended 14:02:11: ISSetAllUsers. Return value 1

I'm not sure why RemoveExistingProducts isn't being executed. Can someone please help me out?

[anom217]

Has anyone had this happen to them? I recreated my project, and it seemed to be working. Then it started happening again, I'm not sure. Is this another possible corruption issue with the InstallShield project?

[joshstechnij]

The FindRelatedProducts action will determine what will be uninstalled by the RemoveExistingProducts action. The ISSetAllUsers action is present to attempt to mitigate an issue in Windows Installer major upgrades that results when existing products and the new product use differing ALLUSERS settings. It does not, however, indicate what will actually occur during a potential upgrade.

It would be best in this scenario to verify what FindRelatedProducts is doing from a log, and troubleshoot from there. If ALLUSERS has changed between the existing installations this can cause an issue that ISSetAllUsers may not always resolve. The criteria to determine what products are related based on Upgrade table entries can also cause existing products to not be detected. Changing these settings until the existing products are detected can isolate the cause of the behavior.

[anom217]

Thanks for the response. This is what the log says

Action 14:02:11: FindRelatedProducts. Searching for related applications
Action start 14:02:11: FindRelatedProducts.
FindRelatedProducts: Found application: {8552BF35-20B8-45D5-8660-B1051B45C9D1}
Action ended 14:02:11: FindRelatedProducts. Return value 1.

So again, it seems it's detecting the related product, but then RemoveExistingProducts is not executing?

I've attached the entire log.

[joshstechnij]

The attached log does not appear to be a verbose log (it is missing a bit of information, including property value changes; it wasn't logged with /l*v).

One other possibility that comes to mind that could cause this behavior is the package code for the installation is not changing (the option to change it at each build is turned off or a hard-coded package code is set in the building product configuration) from the existing installation but the product code and product versions are. This will cause some odd behavior but will prevent major upgrades from working correctly. (Again this is somewhat hard to tell if this might be the case from the attached log since it is missing information on what package is being run from.)

Besides the possible causes listed already, a sample project that reproduces the behavior would be the next troubleshooting step. In regards to major upgrades, Windows Installer controls all the behavior based on the Upgrade table, so assuming the Upgrade table is populated correctly, any issues could be coming from MSI itself (though this is unlikely since major upgrade support hasn't changed for nearly ten years).

[anom217]

I've attached the verbose log this time.

In the Releases view, the Generate Package Code property is set to Yes, and I don't have a hard-coded Package Code specified there. It should be generating a new one every time I do a new build.

I'm not sure what's causing this issue.

[joshstechnij]

The issue here may be the product versions:

InstallShield 17:43:02: UpgradeCode: {063EB66F-DD06-4FB0-BAAA-693CD20AECD2} MinVersion: MaxVersion: 1.0.1.2 Language: 1033 Attributes: 256
InstallShield 17:43:02: Checking related product {8552BF35-20B8-45D5-8660-B1051B45C9D1}
InstallShield 17:43:02: DOEHRS-IH-T {8552BF35-20B8-45D5-8660-B1051B45C9D1} 1033 1.0.1.1 ***Related***

The existing installed product version is 1.0.1.1, and the new version is 1.0.1.2. However, Windows Installer only uses the first three parts of a version number for product versions. Therefore, the product version for both of these products is effectively 1.0.1. In addition to this, the max version specified for the Upgrade table entry becomes 1.0.1. Since the attributes value for the entry does not specify "maximum version inclusive", the product version comparison becomes:
1.0.1 < 1.0.1

This comparison will be false, and the existing product should not be uninstalled.

One way to verify if this is the cause of the behavior would be to temporarily remove the maximum product version from the major upgrade item, then run the upgrade again. If the product is uninstalled, this was the cause of the behavior.

In general, at least the build number part of a product version (Major.Minor.Build) should be changed for major upgrade products.

[anom217]

I removed the specified max version and that seemed to fix the issue with the product versions. Thanks a lot.