Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Version number in registry key makes it detection difficult #3714

Closed
wixbot opened this Issue Jul 18, 2012 · 3 comments

Comments

Projects
None yet
2 participants
Collaborator

wixbot commented Jul 18, 2012

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/

Collaborator

wixbot commented Sep 21, 2012

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".

Collaborator

wixbot commented Sep 21, 2012

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.

Collaborator

wixbot commented Oct 24, 2013

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

@wixbot wixbot added this to the v3.8 milestone Dec 20, 2015

@wixbot wixbot closed this Dec 20, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment