Version number in registry key makes it detection difficult

[wixbot]

When you are building tools that use WiX, it can be difficult to detect if the WiX toolset is installed or not because WiX uses a version number in the Registry tree as a key. For example, I just added support for building Orchestrator Integration Packs from workflows to a tool I was working on, and it leverages the WiX toolkit. The code I already wrote checks to see if WiX is installed by looking for HKLM:\Software\Wow6432Node\Microsoft\Windows Installer XML\3.5 and then it gets the InstallerRoot registry value to access the tools. Then when upgrading to 3.6 RC I broke that logic because it is dependent on a version number.

Please update WiX so that it writes the Registry values to a key that isn't a version number. This will make it much easier for anyone who is taking a dependency on WiX, allowing them to test for WiX reliably and across versions without having to know which version is installed first.

Originally opened by poshoholic from http://sourceforge.net/p/wix/bugs/3033/

[wixbot]

We aren't currently doing backwards compatible type changes so we'll have to think about what it means to have a single key that says "WiX is here".

[wixbot]

Thanks Rob. I thought it might be helpful to provide additional details about what I am doing so that you can think about that when you're considering backwards compatibility as a factor.

I have worked on two projects that leverage WiX programmatically. One creates Orchestrator Integration Pack files, which first requires the generation of an msi file using WiX. This doesn't involve using WiX via a SDK. It simply involves generating the appropriate wxs script file from code and then invoking candle and light to create the msi file.

The second project is a PowerShell module that includes a command to build WiX installers for PowerShell modules. Again for this I generate the wxs file(s) that are required, and then I start a candle and then a light process for each module to create separate msi files. Once the msi files are generated I again start a candle and a light process to create a bundle.

In the first project I only need WiX 3.5 or later, and in the second one I need WiX 3.6 so that I can use the burn feature to create bundles (fantastic feature by the way). Creating installers via a single command line for one or more PowerShell modules rocks!

Anyhow I wanted to share what I was doing because I don't think this is a question of backwards compatibility, at least not for me, because I'm not invoking anything via an SDK. I'm just using the candle and light executables. All I need to know for my products is that I have either 3.5 or 3.6 or later installed (depending on the project I'm referring to) and where the bin folder is, preferably in such a way that the conditions I'm testing will continue to work in 3.7, 3.8, 4.0, and so on.

I hope this helps.

[wixbot]

Originally changed by barnson
Area changed from wixsetup to installer
AssignedTo set to bobarnson
Release changed from future to v3.8
Resolution set to fixed
Status changed from Untriaged to Resolved