Why doesn't Chocolatey install packages into `C:\Program Files\`?

Question

According to the Windows installation rules, programs should be installed to C:\Program Files (64-bit program / x86-64) or C:\Program Files (x86) (32-bit program / x86). The program is copied into a sub-sub-folder containing the vendor name and the program name.

But why doesn't Chocolatey install packages into C:\Program Files\<Vendor>\<Program>\?

10. Apps must install to the correct folders by default
Users should have a consistent and secure experience with the default installation location of files, while maintaining the option to install an app in the location of their choice. It is also necessary to store app data in the correct location to allow several people to use the same computer without corrupting or overwriting each other's data and settings. Windows provides specific locations in the file system to store programs and software components, shared app data, and app data specific to a user

10.1 Your app must be installed in the Program Files folder by default
For native 32-bit and 64-bit apps in %ProgramFiles%, and %ProgramFiles(x86)% for 32-bit apps running on x64. User data or app data must never be stored in this location because of the security permissions configured for this folder.

Source: Certification requirements for Windows desktop apps
Version: 10 (July 29, 2015)

Ectomere

There is no rule etched in stone for the <vendor>-part. There isn't even really a rule where to install at all (although later versions of windows do seem to enforce some crazy stuff). The only 'rule' is that the suggestion for the default installation directory uses the environment programfiles variable (especially if one doesn't let the user choose where to install). SOME programs (like LearnKey stuff (ironically) and Asus Probe) break this rule and hardcode the path. Personally I'd be very angry if for example I couldn't install my games in E:/Games/ next to my E:/Programs/ .. – Bogard

@Bogard Actually, there are certification requirements written by Microsoft, which state for example where to install applications by default. That does not mean, you can change the directory in the installer GUI or by parameter to choose for example another hard disk. Sorry I can't find a document version for pre Windows 8.x "desktop apps". I'm sure there was a rule for <Vendor>\<ApplicationName>. – Ectomere

Great addition to your question! (You might want to add the directory-structure that Chocolatey packages use for whoever doesn't know that program). But I do stick with my comment (not answer): about 90% of the (over 500) programs installed on my pc(s) are without the vendor-part (and I usually don't mess with that part; I just verify it's not a naive hardcoded non-spec-compliant installer (actually rare)). The key-words in the quotes regarding certification requirements you added to your question are 'default' and %ProgramFiles%, and %ProgramFiles(x86)% (which is what I was commenting). – Bogard

But I wouldn't be surprised if just a written 'requirement' of <Vendor> is indeed in the certification requirements (thereby excluding the vast majority of (legacy) applications by just a simple line of text).. But it seems you are more interested in what happens after the programfiles environment variable in the case of Chocolatey. Might I also ask if (and if yes, then why) this matters to you? – Bogard

Distinction of "packages" versus "applications" - I think it was highlighted already but packages are not necessarily the natively installed applications, they just direct those. The natively installed applications are likely to do the right thing and end up in Program Files. – Alded

Answer 1

It depends on your version of Chocolatey, it's settings and the packages themselves.

To start, see Tools vs Applications and Chocolatey's distinction ( https://github.com/chocolatey/chocolatey/wiki/ChocolateyFAQs at the bottom).

If the package does not use a native installer (a tool), it depends on if the package author has used the bin_root concept that is up and coming in a future version.

For example, SysInternals will go to c:/sysinternals right now unless you have a defined $env:chocolatey_bin_root variable. The concept in the code will change as well as right now this requires it to be a subfolder of the system drive and I don't see us developing the final feature with that limitation.

If the package doesn't have that concept yet, one can always ask the package author to incorporate it.

If the package uses a native installer (an application), one can use installArgs to pass arguments to the native installer (https://github.com/chocolatey/chocolatey/wiki/CommandsInstall) and tell it the directory to install the application to. This does require you to know what you need to pass to the native installer. If you want your applications in a custom directory, there is an assumption that you are already an advanced user so it is expected that you would know what to pass the installer if you were doing a silent install.

^{Slightly paraphrased from: https://groups.google.com/forum/#!msg/chocolatey/uucAz8GxebA/HEPAKp69d90J}

Also,

NOTICE: As of 0.9.8.24, Chocolatey's default install location is C:\ProgramData\Chocolatey

This reduces the attack surface on a local installation of chocolatey and limits who can make changes to the directory.

^{Source: https://github.com/chocolatey/chocolatey/wiki/DefaultChocolateyInstallReasoning}

And from personal experience I can attest that that concept is an excellent line of defense (when properly configured, used and understood).

PS:
As you already added to your answer, technically the requirement is %ProgramFiles% and %ProgramFiles(x86)% environment variable(s where applicable).
For example, %ProgramFiles(x86)% could as well point to P:\Software\Programs\x86\ (instead of C:\Program Files (x86)\).
There is obviously a lot of legacy software (now (re-)packaged) that never used a <vendor> section in the path-name.

Hope this helps!

Bogard

I think I found my fault. I thought that NuGet/Chocolatey packages are packages like *.deb packages, but it's just a wrapper for automated downloading and silent installing. So the installation directory is still set by the embedded or downloaded MSI installer. Whcih of cause can use a default or a user defined directory. – Ectomere

Yep, exactly (that was what I was trying to outline in my answer (using the word re-packaged and the quotes and distinction)). Glad I could help! – Bogard

Some of them are. We usually carry the distinction that if the underlying software shows up in Programs and Features, it goes to Program Files. If the software is a tool that comes in as a zip file, it is not actually installed on the machine so there is no integration with Microsoft locations. – Alded