Installing Outside of "Program Files"

[StupendousManX]

I've searched Up and Down the internet and can't seem to find a straight answer, so forgive me if this is answered already. I've used Wix on and off for ~17 years and I swear there used to be a way to do this.

Every time I search for this all I get is the same references to "StandardDirectory" with the Id being set to "ProgramFiles6432Folder" or something similar and references to a "Directory" with an Id of "INSTALLFOLDER". I understand how to configure the Application folder, but it always wants to go into "C:\Program Files" or "C:\Program Files(x86)"

My questions are simple:

1. Can the wixtoolset be configured to override the installation starting point of "Program Files" for the base install directory?
2. If it can, does this cause any known issues with Install/Uninstall processes?
3. and Finally, if it is possible, can someone provide an explicit example of how to implement the override?

Also Note: I would prefer to use WixUI_FeatureTree, but I'm not opposed to one of the other UI options as long as I can control features

Background

• I'm trying to use WixToolset to create a package of tools for distribution.
• I have no need for it to collect or include anything from a visual studio project.
• I have written my own custom harvesting process to create my ComponentGroups
• The "Installed" tools have strict requirements for Path, specifically NOT having Spaces in the path.
• To accomplish this it would be best to be able to install to a specific location, i.e. "C:{APPS}\MyApp", where {APPS} can be whatever I would like.

While I understand the wonderful integration with windows applications "Liking" to be in "Program Files" I don't have a need for Windows to like where I put this, I have a requirement for our custom Tool Chain/Development process to be happy.

[chrpai]

1. Yes
2. Yes and no. ProgramFiles has a specific permission set. Installing somewhere else will be different. That could be a security concern.
3. My preferred way of doing it is author the directory tree for ProgramFiles but then have a set property custom action override my primary directory property (usually INSTALLLOCATION) if it does not already have a value. This gets it to install where I want without causing any ICE validation errors.

As far as your comment about "Liking" .... I like the old adage it's ok to break the rules as long as you know you are breaking them ... and you know why the rules are what they are. Make sure you don't get bit by the old you don't know what you don't know.

The primary scenario for this type of thing is internal applications for systems rather then products. Products are best to play by the windows logo requirements. Even if they barely exist anymore. So many people were bad at playing nice that they just said to containerize everything instead.

[StupendousManX]

Chris,

Your explanation was somewhat understood, It was a bit generic, but I already had modified the INSTALLFOLDER Format in my "Folders.wxs"

<Fragment>
    <StandardDirectory Id="ProgramFiles6432Folder">
      <Directory Id="INSTALLFOLDER" Name="!(bind.Property.Manufacturer)_!(bind.Property.ProductName)" />
    </StandardDirectory>

Per your response I Ended up adding the "SetProperty" action below it inside the fragment.

    <SetProperty Id="ProgramFiles6432Folder" Value="C:\APP" Before="CostFinalize" />
  </Fragment>

I think this is what you were saying to do, and it does seem to work. I fumbled around with Property Id's "INSTALLLOCATION", and "InstallLocation" and couldn't get anything to work. I'd like to make this more flexible in the future not sure if this method will allow the Advanced UI to modify the location properly, but for a fixed result this is doing what I wanted.

Thanks,
~Dustin

[chrpai]

There is no industry standard name for the primary installation folder id. Some use TARGETDIR some use INSTALLDIR some use INSTALLLOCATION You don't want to set PF632F you want to set INSTALLFOLDER and you only want to set it if it doesn't have a value. (Imagine if someone passed INSTALLFOLDER=D:\APPS at the command line. I'd also schedule it sooner like before AppSearch and I'd make sure it's scheduled for both sequences in case of a silent installation.

I'm a consultant so much more detailed explanations and samples are available upon engagement. Otherwise I suggest you check out my open source tool called IsWiX. It has project templates that will greatly easy creating projects and learning WiX. You'll find IsWiX and IsWiX-Tutorials on Github.

[StupendousManX]

Thanks for the Tip, I bumped it to before AppSearch. I'll check out IsWix for some additional insight if needed.

I don't have much of a need for like 90% of MSI capabilities :-) and it's not for commercial product distribution, so this will be good

[StupendousManX]

After some back and forth, I found there are multiple ways to skin a cat. I think in the end essentially the answer to my questions is the SetProperty Action. Using this to modify the "base" Directory you use when setting up your paths.

Ultimately I ended up modifying my directory structure and rather than overriding a StandardDirectory I implemented the Base using INSTALLDIR then set it with the action before the AppSearch Action

  <Fragment>
    <Directory Id="INSTALLDIR">
      <Directory Id="INSTALLFOLDER" Name="!(bind.Property.Manufacturer)_!(bind.Property.ProductName)" />
    </Directory>

    <SetProperty Id="INSTALLDIR" Value="C:\APP" Before="AppSearch" />
  </Fragment>

Feel free to take note of some of Chris's other tips, but overall this is the simple answer.

[chrpai]

Dude, your funny. You ask for help and you get it from an expert with 30 years of installation experience, 22 of which is using WiX/MSI and you decide that you already know better then me and accept your own answer. Stuff like this is why people are getting worn out and not bothering to provide support unless they get paid for it.

[StupendousManX]

Lol.. you can't win this day and age, damned if you do, damned if you don't. I never claimed to be an expert, nor do I remotely think that "I know better than you" however, in my almost 20+ years as a Software developer and 30+ years as an avid computer Tinkerer I've taken one thing along with me all these years, and that is it's easy to punch down on someone you think is inferior to you or not worth your time, but it's just as easy to share your knowledge and educate. While I don't want to suggest you should just teach for free, but if you choose to engage in an environment such as a discussion on GitHub which is designed for learning and sharing then you only get to do the latter.

Closing the ticket was a bit awkward admittedly, but I was trying to avoid exactly what you chose to waste even more of your time to complain about. When other people try to search stuff, they like to find answers, so to solve 2 problems (Since your advice worked):

1. I decided to stop "Wasting" your time with a back and forth that could go on for days discussing various reasons for why one way should or shouldn't be used over the others
2. I shared what I did that answered my specific question

I then marked the culmination of our discussion as "Solved" and credited you for your knowledge so that anyone searching could find a quick answer rather than dissecting our conversation.

I could have just abandoned the discussion all together since I got what I needed, only to return 3 months later for some reason and see a complaint that I took off without so much as a thank you, so to that end.

Thank You for your help.