On Windows, which standard locations can I install to without needing admin permissions?

Question

My application currently writes files to its installation directory which means Program Files isn't a valid option (I know this isn't ideal). But I would also prefer my installer (Inno) not to require admin rights i.e. no UAC; I think Google Chrome does this.

Which common location would make sense to default to with both these restrictions in mind?

Answer 1

If you really want to make a per-user installer that does not require admin permissions, the correct settings to use are:

[Setup]
PrivilegesRequired=lowest
DefaultDirName={userpf}\YourAppName

Note that (addressing Glytzhkof's concerns) this is a local folder, not a roaming folder. If you want settings to roam then you will still need your application to keep them in (your language's equivalent of) the {userappdata}\YourAppName folder. Regardless, the user will have to separately install the software on each machine that they intend to use it on (but this is typically the best option anyway).

Some of the downsides of making a per-user application are:

1. You cannot use admin permissions when installing. In particular this means that you cannot install many other components (runtimes, libraries, etc) that you might have wanted to use in your application. You also can't use features like regserver and restartreplace. (This doesn't necessarily mean that you cannot still use these components, just that it's a larger hassle if the user does not already have them installed.)

2. If a single machine has multiple users (common for families and in some workplaces) then they will have duplicate independent copies of your application, which have to be individually upgraded by each user. This particularly annoys IT departments as they prefer doing central upgrades, and if your app is large it may waste disk space.

If the reason you don't want to make a normal {pf} based application is simply that you want to be lazy and store settings files in the program's folder, then it's probably better overall to rethink this decision. It's not hard to do it "right".

Answer 2

There are basically 3 types of files: 1: user data, 2: application settings, and 3: binaries. Plus a few exceptions. I assume Harry is suggesting to write to a user's application data folder with configuration and settings files, and not the whole application. Don't ever put binaries or data here, but do save settings files here.

The whole concept of "roaming files" is a bad idea in my opinion. It clogs your userprofile and increases logon time on each computer and causes all kinds of synchronization issues when people leave multiple machines logged on simultaneously for weeks at a time. The whole roaming concept works only in theory in my opinion - but it depends on user discipline and application quality in its data management. Rarely edited and mergeable files can work, if the application is good. I have seen it work well for spell checker custom dictionaries and similar. The real solution is client/server applications with back-end databases for the purpose of persisting settings. Everything else will eventually fail - if it's a light weight app that might not matter.

User data should be saved to the "My Documents" location only. and only a few configuration settings should roam. If a network is set up to allow "My Documents" to roam, the system administrator should be shot immediately :-). It must be a server share accessible regardless of the computer the user is logged on to.

I've flown off the handle here and answered too many questions you didn't ask. Just hate seeing people head for problems they might not know about. If you have a super small application that is basically "portable" as we call it in deployment. That means an application where you can run off a single folder on a USB stick, then save everything in User data, and keep the application small and lightweight with a single settings file and a binary. No UAC or admin rights should be needed.