I am trying to prevent downgrades of my installation. However the FindRelatedProducts action does not find any related products.
In the Upgrade table I have authored: {DCB050B9-9EDE-43D0-BDB6-4FBEA69EC056},9.00.0000,"",""1024,"",ISFOUNDNEWERPRODUCTVERSION
In my test I install a copy of the setup that has a different ProductCode and ProductVersion. {DCB050B9-9EDE-43D0-BDB6-4FBEA69EC056},10.00.0000,"","",1024,"",ISFOUNDNEWERPRODUCTVERSION
I install 10.00.0000 first. I then try running 9.00.0000. FindRelatedProducts does not find the product with the related Updgrade code. If I keep the ProductCode the same, then the prevent downgrade option works correctly, but as I understand it, this is only a minor upgrade. I want to prevent a major 'downgrade'.
How are you verifying whether it finds the other version? The attributes column entry 1024 doesn't correspond to detecting the product without removing it, but instead to excluding the (empty) list of languages specified. If that doesn't clear it up, double-check the UpgradeCode GUID and per-user vs per-machine context issues, but I'm pretty sure it's the attributes.
The attributes were original 2, I had changed the attributes in my testing due to a post I had read from Robert about using 1024 to make sure you compare all languages. I thought it was worth a try. I will be changing the attribute value back to 2 because that did not solve my problem and like you, I agree that having an empty language column should prevent that anyway.
I have verified that the upgrade code is identical in both packages. I have physically inspected the cached msi database for the 10.00.0000 package and then the 9.00.0000 using Orca and the UpgradeCode agrees in both cases.
EDIT: I verified that FindRelatedProducts fails because the property ISFOUNDNEWERPRODUCTVERSION is never populated. This is a per-machine installation and even so, my testing is all done under the same user profile.
Does changing the attributes to Detect-Only (2) not fix it then? If you still want your 1024 bit, you should be able to or (add) them together, resulting in 1026; I've just never personally worked with the 1024 bit so am not familiar with its repercussions.
What I was expecting is that without the Detect-Only bit it would be doing exactly what you wanted to avoid - kicking off a major upgrade's uninstall of the newer version. But if it doesn't find it at all, even after changing to just Detect-Only, I'm not sure what to check next.
Actually the value is in the registry, it is just micro scrambled ... 9B050BCDEDE9OD34DB6BF4EB6AE90C65
I just created a new test install and tried to reproduce this. With a new install this process works correctly, so I am confused I guess. Obviously I have something wacked in my current setup and at this time there is no going back - not with only 3 code days left in development 😄
Well, I am not sure how I missed this before but the Upgrade property did not match the value in the Upgrade Table. I was so focused on the Upgrade table that I never checked the value against the upgrade property.
Sometimes it is the simple things that send us spinning 😮
