2

I have an installer that I'm converting from being an admin-only installation into a Single Package Authoring installer capable of being installed for the current user or for all users. Two of my features require writing to a registry key that would not be available to a regular user. They deal with integration to another application, so I can't write the registry values somewhere else in user space... They have to go in this location.

I'm not concerned with users not being able to install these 2 specific features if they aren't administrators and the installer functions without issue if they aren't selected, but I want to not show them in the feature tree at all and ensure they aren't included in a "Complete" install.

The solutions I've seen let me put conditions around components so the components wouldn't be installed... or to put a condition inside the feature that would set it's level to some high value. How can I disable and/or hide the feature entirely if ALLUSERS=2 or MSIINSTALLPERUSER=1.

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
Dewey Vozel
  • 2,257
  • 1
  • 19
  • 22
  • Some updates below. No more time to look at this today I am afraid. – Stein Åsmul Oct 10 '18 at 19:52
  • I am not convinced it is good to change the values of `ALLUSERS` and `MSIINSTALLPERUSER` and the feature level values at runtime. The main problem you run into is that `per-user setups` are supposed to run `non-elevated`, whereas `per-machine` setups need `elevation`. I am not sure how the WiX guys do this elevation from within the WiX dialogs. – Stein Åsmul Oct 10 '18 at 20:30
  • FYI, I did have to manually update MsiRunningElevated based on the selection of "all users" or "just me" in the UI in order to get the "admin shield" to not display on the install button of the default verify dialog. Other than that, I haven't had any problems with elevation. In a silent install, running it under an admin command prompt provides the necessary elevation. Doing a GUI installation, the elevation prompt comes up when I hit install. – Dewey Vozel Oct 11 '18 at 01:45

1 Answers1

0

Per-User Setups: I won't lie to you, I actively avoid this sort of setup. I find MSI's per-user installation constructs "not ideal". It relates to poor serviceability (upgrades, patching, etc...) and a number of other details. Some details mid-page here.

Some links for others who read this answer (I think you have read these):

Feature Conditions: With that said you can use feature conditions to unselect features based on whether a certain condition is true or false. You can even set the Level of a feature to 0 which will hide it from the GUI entirely during installation. You could try this. Please also read the linked answer below (bolded). It contains a better explanation of feature conditions.

I don't have time to test this, but here is a WiX mock-up that you can try:

<Feature Id="MyFeature" Level="1"> <!--Default to install feature-->

    <Condition Level="0"> <!--Do not install feature if condition is true-->
       ALLUSERS=2 OR MSIINSTALLPERUSER=1
    </Condition>

</Feature>

These answers might help you get an overview of this:

Hide Feature Testing: I will add a little snippet you can use to verify the operation of the feature hiding. It forces the condition in question to be true by setting it to 1 - as opposed to using a "real condition" that can be false unexpectedly.

<Feature Id="SupportingFiles" Title="SupportingFiles" Level="1">
   <Condition Level="0">1</Condition>
</Feature>

This should hide the SupportingFiles feature from view in the setup GUI, and it should also not install it. Please let me know if you see a different behavior.

Custom Actions: To interactively hide a feature based on changes done in the GUI, you can try to use custom actions to control the feature levels.

I am not sure this will work. I will test when I get the chance. Just adding that link for now.

UPDATE: I am unable to investigate this right now. I want to alert you to the possibility of adding temporary rows to the database during installation. Perhaps this is the way to go to hide the feature "interactively". I just don't know since I have never tried. Here is the first link I found on temporary records. And towards the bottom here are links. No guarantees.

Other than that I suppose you could use an external GUI launcher. I might comment on this later. I recently wrote about this issue (external GUI).

Some Further Links For Reference:

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • That's a really thorough answer, but unfortunately it doesn't work. If I set the level to 0, the user can still do a custom install and see the feature in the tree and choose to install it. I've mitigated that by also putting the condition inside of the component that gets installed by that feature but it seems like a bad user-experience. – Dewey Vozel Oct 09 '18 at 11:25
  • The feature should be hidden entirely from the setup if the feature level is set to 0. I am not sure why you see different behavior. Note that the condition has to evaluate to true in the sample above for the feature to be hidden. You can test the feature hiding by setting the condition to `1` to force it to be true. The feature should then be invisible in the setup GUI. I believe this would be: **`1`**. – Stein Åsmul Oct 09 '18 at 11:32
  • According to the docs, and inline with what I'm seeing happen, setting the Level to 0 only "disables" the feature... effectively marking it to not be deployed. The user can change that setting in the feature tree during a custom installation. I need a way to set the Display attribute of the feature element to hidden... I think. – Dewey Vozel Oct 09 '18 at 14:22
  • I just ran a quick test. Setting a feature's Level attribute to `0` hides it from the GUI and does not install it - as far as I can see. You should not set it to 0 by default, since this will make it not extract during an admin install, but you should use a condition to set the feature level to 0 when true. Let me add a concrete example above. – Stein Åsmul Oct 09 '18 at 22:55
  • It doesn't work for me. I wonder when feature conditions get evaluated. My UI flow goes Welcome > EULA > Install Scope (this is where ALLUSERS can be changed to 2 but it defaults to 1) > Setup Type > Customize (where the feature tree is shown). If the feature conditions get evaluated before the UI is initialized then that would explain why it doesn't hide for me since I'm setting it in a dialog. – Dewey Vozel Oct 10 '18 at 12:57
  • OK, hold on. You will have to try a custom action to set the feature level. I have a few answers written on this kind of stuff. Will update the answer above shortly. – Stein Åsmul Oct 10 '18 at 13:09