How to select installation directory from command line

Hey, I'm using Chocolatey package manager to install all of my software. I normally pass additional command line arguments like /D, /DIR or /TARGETDIR (depending on what a given installer expects) to select installation directory. How to do it with Fences 3?

 

The installer looks like it's an MSI installer embedded in .exe file, so TARGETDIR="D:\My\Installation\Path" should work but it gets installed to the default Program Files (x86) location.

 

Regards

Maciej

33,917 views 25 replies
Reply #1 Top

Hello,

Sorry to hear you are having issues.

Fences like all other Stardock apps needs to be installed in it's

Default directory C: 

 


AzDude
Stardock Community Assistant

Reply #2 Top

Umm, I don't  think so, GUI installer (graphical installer, where you click) does offer a choice of installation directory. I'm asking the same for CLI (command line installer, where you only type commands).

Reply #3 Top

Yes you can install on another drive but if you want ALL to work

properly including updates , bug fixes commands and all

support help Default C: drive and directory needs to be the location.

Reply #4 Top

Ok, that's concerning.

  1. Where is it documented?
  2. Why do you give your users an option to select installation path via GUI, if it doesn't work correctly? There is no warning in the installer.
  3. Why won't everything work with changed installation path? I find it hard to believe for such an advanced software. Most of programs just store installation path under some registry key and use it from there instead of hardcoding Program Files (x86) location.
  4. Let's say I want to sacrifice "properly including updates , bug fixes commands and all" and still change the path via CLI. Can I create a feature request for it?
Reply #6 Top

Sorry, but I would rather hear an explicit "Not a feature, not gonna do it", than receive nonsense arguments about non-default installation path not being supported and then get ghosted.

Reply #7 Top

Hello,

I have forwarded your report to the Stardock support team for their review and recommendations.

Please keep an eye on this thread for any updates.

We really do appreciate your feedback, thanks.

Reply #8 Top

Hello,

Sorry to hear you are having trouble.

In the next update, the GUI will cease to offer a different path for install.  ProgramFiles has the permissions required and hence its use.

No other options will be available for alternate install locations.

Sean Drohan
Stardock Support Manager

Reply #10 Top

As a developer myself, I really do not understand why more software vendors are starting to eliminate the option for a custom installation location. The option to do that has been around since Windows was still in its 3.x versions. Many people like myself prefer to reserve C: drive for the system (OS) only, and install all other apps on a different volume. Taking away this option and forcing users to install a piece of software where the vendor thinks it needs to go feels like a great big middle finger to the customer.

Reply #11 Top

Quoting dragonzfang, reply 10

Taking away this option and forcing users to install a piece of software where the vendor thinks it needs to go feels like a great big middle finger to the customer.
End of dragonzfang's quote

It's not that, and as a developer, you are aware that ProgFiles has special permissions, is part of the environment path, etc, and why it is the natural choice for developers.

Sean Drohan
Stardock Support Manager

Reply #12 Top

I do understand - but by and large, Sean, the vast majority of software vendors provide the option for a custom installation location and just via environment variables and the Registry alone, Windows provides great flexibility in supporting this. I don't mean to be offensive, but when I see a vendor do this, it comes across as laziness - something done more for the benefit of the developer vs the customer. That being said, Fences is a great product (as attested by my upgrade purchase of v4 earlier this morning, which is how I came to discover the removal of this option) - and if I didn't like it as much as I do (and had not already been using it for several years), I would not use it for that reason alone (as I have other software products).

Reply #13 Top

Quoting dragonzfang, reply 12

but when I see a vendor do this, it comes across as laziness - something done more for the benefit of the developer vs the customer.
End of dragonzfang's quote

'Lazy'..?  I really don't see how you could reach that conclusion.

While you surely have notable skills when it comes to knowing how, what, when, and where on a PC, the average person does not.  This practice is mostly about 'saving them from themselves'.  I can't count how many odd issues we have encountered with installs only to find, several steps down the road, that it was the result of it not being in a place (ProgFiles) where the app could do all it needed to or to have Windows treat is properly.  As it is a trend amongst developers to have the same practice (as you have noted), we are not alone with this mindset.

I guess the TLDR on this is we are preventing clients from burning themselves instead of treating every burn after it happens. 

We do appreciate the feedback, dragonfang.

Sean Drohan
Stardock Support Manager

Reply #14 Top

I've never used the quoting functionality here, so I apologize if I goof it up.

Quoting sdRohan, reply 13

This practice is mostly about 'saving them from themselves'. 
End of sdRohan's quote

Famous words many times over from those assuming that people need it.


....the result of it not being in a place (ProgFiles) where the app could do all it needed to or to have Windows treat is properly.

End of quote

That kinda my point. If an application has that much of an issue with the path of a program's installation location, it stands to reason the issue is with the application design - not the user. From my experience, a large part of an application's codebase is functionality to address all the <insert word of choice here> things that a user can -and probably at some point will- do that they shouldn't do - which should not include restricting them on where they want to install the program.


As it is a trend amongst developers to have the same practice (as you have noted), we are not alone with this mindset.

End of quote

Birds of a feather flock together, I guess - but that doesn't make it right. I may very well be in the minority with my opinion, but I feel like if I don't express it to the person/entity I'm paying money to for a project or service, then the assumption will continue to be that what is being done is in the interest of "saving people from themselves".

Again, no offense meant - I appreciate your respectful responses and not ignoring them as in many a case with other forums. I take pride in the development work I do, so I speak from a professional standpoint the frustrations I have regarding the decision to remove that option.

 
Reply #15 Top

Quoting dragonzfang, reply 14

Again, no offense meant - I appreciate your respectful responses and not ignoring them as in many a case with other forums. I take pride in the development work I do, so I speak from a professional standpoint the frustrations I have regarding the decision to remove that option.
End of dragonzfang's quote

None taken - your points are sound and well-received - thank you for them.

Sean Drohan
Stardock Support Manager

Reply #16 Top

Well, this is massively disappointing. So, it is essentially impossible to buy the software for just one user without it potentially breaking other software for my other users. Good Lord am I glad that you had a thirty-day trial before I pulled the plug. 

Reply #17 Top

Quoting Alexei_Drekker, reply 16

o, it is essentially impossible to buy the software for just one user without it potentially breaking other software for my other users.
End of Alexei_Drekker's quote

I am not sure I follow or you have a misunderstanding of how to disable the service on a per-user basis.

Sean Drohan
Stardock Support Manager

Reply #18 Top

Oh? So, it is possible to confine installations to specific user accounts? Great. Apologies. Could you lead me to a support site or document which details these steps?

Reply #19 Top

Quoting Alexei_Drekker, reply 18

Oh? So, it is possible to confine installations to specific user accounts? Great. Apologies. Could you lead me to a support site or document which details these steps?
End of Alexei_Drekker's quote

Not 'installation' but enabled\disabled, yes.

For Fences, it would be whatever GPO you have set for what is started with for each user:

For Start10\11, there are GPO templates:
https://forums.stardock.com/486022/start10-support-faq#grouppolicy

And for most other corp use products (Gropy, Multiplicity, etc), there are services that can be disabled on a per user basis:
https://forums.stardock.com/486022/start10-support-faq#disablestart10

Sean Drohan
Stardock Support Manager

 

Reply #20 Top

I, too, am a software developer, and it is not a good thing to require Fences to be installed in a certain location, particularly the C drive.  All apps should be able to be installed on any drive and programmers should code so that they work fine from anywhere.  I agree that this is taking the easy way out at the expense of the user.  I install all my tools to other drives and reserve the C drive for the OS.  

Reply #21 Top

Quoting BigDH, reply 20

I, too, am a software developer, and it is not a good thing to require Fences to be installed in a certain location, particularly the C drive.  All apps should be able to be installed on any drive and programmers should code so that they work fine from anywhere.  I agree that this is taking the easy way out at the expense of the user.  I install all my tools to other drives and reserve the C drive for the OS.  
End of BigDH's quote

Fences is an OS Shell enhancement and as such is best served being with the OS, not elsewhere.  It's not the same as general 'software' you might develop....;)

Reply #22 Top

Regardless of how you'd prefer to classify it or where you think it should be installed, that doesn't justify removing the ability to select a custom installation location - an ability that has existed in Windows software for decades. Fast forward, now we have a very select few of vendors that think users need to be saved from their own selves because they're deemed too stupid to choose their own installation location.

Reply #23 Top

Quoting dragonzfang, reply 22

now we have a very select few of vendors that think users need to be saved from their own selves because they're deemed too stupid to choose their own installation location.
End of dragonzfang's quote

Actually, it isn't the tech/computer savvy folks that have the "HALP!" emergencies. It's the folks who don't have a high level of computer literacy, and worse, when it's the folks whose native language isn't English have communications problems added to the tech ones. The number of folks who aren't devs far outnumber the tech savvy folks (at least from Support's POV).

Also, no one at Stardock thinks their customers are 'stupid' as you put it. 

Reply #24 Top

Quoting dragonzfang, reply 22

Regardless of how you'd prefer to classify it or where you think it should be installed, that doesn't justify removing the ability to select a custom installation location - an ability that has existed in Windows software for decades. Fast forward, now we have a very select few of vendors that think users need to be saved from their own selves because they're deemed too stupid to choose their own installation location.
End of dragonzfang's quote

The decision was not made lightly but we have no regrets after making it.

The amount of support required (time) to resolve issues resulting from clients installing to locations that did not have the proper permissions to run or run consistently \ fully was considerable - so much so that it distracted from the development of the core product(s) itself. 

And in no universe do we see any client as 'stupid'.

Thanks for the feedback.

Sean Drohan
Stardock Product Lifecycle Manager