cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
DLee65
Level 13

FindRelatedProduct problems

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'.
Labels (1)
0 Kudos
(6) Replies
MichaelU
Level 12 Flexeran
Level 12 Flexeran

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.
0 Kudos
DLee65
Level 13

Michael, thanks for the reply.

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.
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

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.
0 Kudos
DLee65
Level 13

I just did a search through the registry for the UpgradeCode value. Should the upgrade code appear in the registry?
0 Kudos
DLee65
Level 13

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 😄
0 Kudos
DLee65
Level 13

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 😮
0 Kudos