Upgrade installation results in duplicate entry for installed software (FindRelatedProducts not executed)

I try to perform a major upgrade with my MSI installer with a quiet installation. The installer already works well when using a normal installation with a full user interface. In this case the old product is uninstalled because FindRelatedProducts 开发者_开发知识库action (from the UI sequence in FolderForm) detects my previously installed version.

When the /qr switch for msiexec is used to suppress the dialogs and need for user interaction (essentially reusing the settings from the last version), then it fails:

MSI (s)  : Doing action: FindRelatedProducts
Action  FindRelatedProducts. Searching for related applications
Action start  FindRelatedProducts.
MSI (s)  : Skipping FindRelatedProducts action: already done on client side
Action ended  FindRelatedProducts. Return value 0.

As a result, there are two entries that show up in the the installed software dialog of Windows - one for the old and new version, so in that case the old version was not uninstalled/removed.

Is there any other msiexec command switch that I could use that would still execute the FindRelatedProducts action? Could it be integrated elsewhere so that it would be executed in such a quiet installation?

---

I found a way to solve the problem and the upgrade is performed as expected.

When launched with /qb switch for msiexec, FindRelatedProducts is exectuted and the upgrade works as expected.

I havent found a better specification or explanation on the different UI levels and implications on the execution, but it might be enough information to debug and resolve similar issues.

Switch /qr seemed to trigger the skipping: "Skipping FindRelatedProducts action: already done on client side".

Thanks for your support!

---

You seem to have focused on a symptom instead of the actual problem. FindRelatedProducts only needs to execute once as long as the following two things are true: the action property of each Upgrade entry is a public (ALL_CAPS) property, and this property's name is listed in the property SecureCustomProperties. When both of these are true, the first the UI sequence should set the action property, its value should make it intact to the execute sequence, and RemoveExistingProducts should process and remove the associated product codes listed in that property. (Of course, running /qb will skip the UI sequence and fall back to running just the execute sequence entry like you describe in your answer).