WiX: Obtaining version for already installed 3rd party program

Question

I'm trying to configure an installer to conditionally install certain components only when certain versions of a 3rd party application are installed.

<EDIT>
It should be noted there is a 1:1 correspondence between the 3rd party software version and ours.. are there are dozens of such releases of the 3rd party software (plus up to three additional releases each month), so we do not want to be performing hand editing. Our programs are automatically built against all releases of the 3rd party software, but which files get installed needs to occur conditionally.
<\\EDIT>

I'm only deploying this as a single .MSI, so no Bootstrapper etc. From my readings and googlings, I believe that I need to have an UPGRADE section, to identify what PRODUCTCODE the application will currently have (multiple versions.. so there are multiple PRODUCTCODEs possible). This PRODUCTCODE can then be used to read the DisplayVersion out of the registry.

So I have:

<Upgrade Id="{6D991503-3102-437E-B21D-471599D491AB}">
    <UpgradeVersion Minimum="0.0.0.0" OnlyDetect="yes" Property="CLEARSCADADETECTED" />
</Upgrade>

for the UPGRADE section, and then..

<Property Id="CLEARSCADA_VER" Secure="yes" Hidden="no" Value="6.78.6626.1">
    <RegistrySearch Id="ClearSCADAVersionSearch"
                    Root="HKLM"
                    Key="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\[CLEARSCADADETECTED]"
                    Name="DisplayVersion"
                    Type="raw"
                    Win64="yes" />
</Property>

For the REGISTRYSEARCH.

It seems that the PRODUCTCODE lookup is working, however the Registrysearch isn't.. (I'm expecting a PROPERTY CHANGE entry after the AppSearch)

FindRelatedProducts: Found application: {2ACE38B2-F142-4EFE-9AC7-B25514E4930E}
MSI (c) (F0:90) [23:17:39:598]: PROPERTY CHANGE: Adding CLEARSCADADETECTED property. Its value is '{2ACE38B2-F142-4EFE-9AC7-B25514E4930E}'.
Action ended 23:17:39: FindRelatedProducts. Return value 1.
...
AppSearch: Property: CLEARSCADA_VER, Signature: ClearSCADAVersionSearch
MSI (c) (F0:90) [23:17:39:629]: Note: 1: 2262 2: Signature 3: -2147287038 
Action ended 23:17:39: AppSearch. Return value 1.

I've tried hardcoding the registry lookup (ie replacing the [CLEARSCADADETECTED] by static text of {2ACE38B2-F142-4EFE-9AC7-B25514E4930E}), without any change. Any other suggestions for what to check would be greatly appreciated.

<EDIT 2>
Ok, confusingly, if I reference the Version DWORD value (instead of the DisplayVersion String value) then it does read it correctly as #105781730. Is it possible that the RegistrySearch wouldn't work for String values?
<EDIT 2>

<EDIT 3>
Yay... it's working. And I guess it's been working for a while now also. When I put the Value='6.78.6626.1', I should have realised that if the version that I was testing it on was already '6.78.6626.1' then it wouldn't have indicated a PROPERTY CHANGE.
<EDIT 3>

Bevan

Answer 1

I didn't test with the actual major upgrade detection, but maybe try to remove the Hidden attribute which would seem to remove the set property operation from the log. I initially also removed the Value attribute, but put it back and now set it equal to 0:

<Property Id="CLEARSCADA_VER" Secure="yes" Value="0">
 <RegistrySearch Id="ClearSCADAVersionSearch"
                 Root="HKLM"
                 Key="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\[CLEARSCADADETECTED]"
                 Name="DisplayVersion"
                 Type="raw"
                 Win64="yes" />
</Property>

I ran a quick test and this works for me. And you are correctly searching the 64-bit section of the registry (provided this is indeed the section you want to search) with the settings in your WiX file. Perhaps you have updated your question since PhilDW answered?

---

I also verified that the registry search is not case sensitive . I couldn't remember if it was or not.

To inspect searches and property values , you can use a script custom action for debugging (then there is no compilation and hassle).

• A VBScript will do fine for debugging, but shouldn't be used for production code.
• I can dump in the required WiX custom action elements for a VBScript custom action that shows property values for you, but I don't want to make this answer any more verbose than it already is if you don't want it.

---

Are you sure there will be only one version of the 3rd party application installed at a time? Maybe a check with the vendor and some assurances of how they will do their deployment going forward could save you a sudden problem later on? Dependencies on the behavior of other packages can be a time bomb - it is very tight coupling out of your control . Not to sound too dramatic, it is probably fine. Just mentioning it. And checking this is a manager task if you ask me.

It is sort of neat what you are doing , but sadly I often experience that logic gets more complicated over time and I eventually have to resort to a custom action to deal with all kinds of edge cases. Let's hope you don't have to go down that road, since you are doing the right thing trying to avoid custom actions .

Answer 2

It's not clear that you need the registry search because you can have more than one UpgradeVersion element, each with the version you want. So multiple ProductCode values are not something you need to worry about in the search. This documentation here:

https://www.firegiant.com/wix/tutorial/upgrades-and-modularization/checking-for-oldies/

shows examples of multiple UpgradeVersion element.

Having said that, the easiest thing would be to have one UpgradeVersion that refers to the exact range of versions that you care about, and this will set your property if anything in that range is found. You just need to set the minimum and maximum to the values.

Your registry search screen shot seems to show what is probably the native registry on a 64-bit system. Your search does not explicitly set Win64 and might be searching the 32-bit registry.