Added feature selection for application and internet shortcuts to allow ... #4420

wants to merge 1 commit into

4 participants


...users having issues with internet shortcuts to disable the feature for successful installation

I'm not able to reproduce the issues some users are having with installation because of Internet Shortcuts, but providing a feature for application and internet shortcuts seems to be a quick hack so these users can install node.js successfully. For more information on those issues, see nodejs/node-v0.x-archive#3620 and the links within that issue.

This pull includes a <EnableProjectHarvesting>True</EnableProjectHarvesting> property set in the wix project to work properly with WiX 3.6 (this creates the Product.Generated component group).

This also changes the Minimal UI flow of the installer to the FeatureTree flow. For the feature selection to make sense, the node.js engine feature is shown as an option but set to be a required feature with the Absent="disallow" attribute. Otherwise, the only features shown would be two features for shortcuts.

node js-installer-shortcutfeature

@jimschubert jimschubert Added feature selection for application and internet shortcuts to all…
…ow users having issues with internet shortcuts to disable the feature for successful installation
Node.js Foundation member

also /cc @sblom


@jimschubert, I've been playing with this locally, and it seems to work as advertised.

What's your level of expertise on WiX and MSI? If you feel qualified, I'd like to understand a little more about the changes that you made.


  1. Do you understand what Project Harvesting is? I saw some mumbling about the WiX folks turning that off by default in WiX 3.6 because it was causing some sort of non-deterministic-sounding problems. Can you vouch that we're safe?
  2. I'm having a little trouble understanding all of the changes to the install dialog flow. Playing with it, things seem to work, but I suspect I should be testing reinstall and feature change scenarios, but I haven't managed to decipher what to care about.

Thanks for the patch, and for helping me understand it. :)


It seems a little anti-parallel here to not start this Id with nodejs. Is feature.application.shortcuts a standard MSI thing?

My gut tells me this should be named more like nodejs.shortcuts.application.

Naming of Id values is pretty loose in WiX. Personally, I like to begin features with feature., Files with file., etc. For example, this would allow you to define a component with multiple files clearly relating to maintainers that files are referenced. It is similar to a few of the tips and tricks suggested on stackoverflow.

Namespacing features with the product name is completely valid.




@sblom Sorry for the delayed response to your questions. I was traveling across the US last week to start a new position this week and internet access in the heartland is terrible.

Project Harvesting

It's my understanding that project harvesting was disabled in v3.6 and above because it wasn't properly harvesting references. While working on this patch, it was difficult to determine which version of WiX was being used to generate the installers. I had v3.6 installed for another project. One of node's existing WiX properties or components required harvesting to be enabled, so I left it enabled (which requires the added property in WiX 3.6).

As far as whether or not project harvesting is safe, I'm not sure because I don't believe the WiX authors have yet determined what causes issues for some users. I'd have to play around with this a bit and set the harvest property to false to see what it was that required harvesting. My feelings on the matter are that if developers on the node project have been using WiX v3.4 or v3.5 with harvesting enabled and having no issues, leaving it enabled to build with WiX v3.6 would be safe.

UI Sequences

The changes to the UI install sequence are copied straight from the WiX source for the feature tree UI template. The changes to this section of the commit wire up the new dialogs for feature selection and update the constraints for showing dialogs.

The other changes completely wire up the back buttons according to the default UI flow of the feature tree sequence.


This moves from WelcomeDlg to LicenseAgreementDlg when node is not installed, rather than always showing the agreement.


This would move from WelcomeDlg to VerifyReadyDlg if node is installed and PATCH public property is defined. This functionality can be maintained with ARP* properties (see MSDN) to block modify/repair.


CustomizeDlg workflow was taken directly from WiX sources for FeatureTree. Customization is allowed when the license is accepted. The rest of the additions are wired up for the default conditions (which can be maintained via the ARP* properties previously mentioned)


Landed in e418df7

@sblom sblom closed this Feb 8, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment