Is AppData now the 'correct' place to install user-specific apps (which modify their own data)?

Question

I'm probably just being very thick here, but it's not clear to me where I'm supposed to install 'new' user-specific programs on Windows 7 (and presumably Vista too, though I've not specifically looked at that scenario yet).

Under Windows XP (rightly or wrongly) we always installed our programs into folders under 'Program Files' and accepted that they'd be kind-of available to everyone. From what I can gather under Windows 7 I'm supposed to install my software under the user's AppData folder (possibly AppData\Local\MyApp). That makes a degree of sense, but the fact that this folder is 'hidden' by default means that we're going to have 'fun' talking our users through support stuff.

I want to install our software so that it's user specific (the Users bit in Windows 7 makes perfect sense) but I do want the user to be able to access it if required. Our program also includes a 'data' subdirectory which it needs to write into while it's running (embedded database), but as the program is intended to be single-user/standalone, the data folder being inside a user-specific folder isn't going to be a problem.

My problem is just that whole 'hidden folder' aspect of AppData. As much as I've trawled the MSDN, I can't work out where else I'm supposed to install user-specific programs. Taken one way it would seem to be something like AppData\Local\MyApp, and another way it would seem to be just as valid under the user's My Documents\MyApp equivalent.

Has anyone got a clear guide for where all this stuff goes? I found the MSDN docs confusing. :-)

Solution 1

Not really.

The directory that serves as a common repository for application-specific data for the current roaming user.

AppData is, surprisingly, for application data, not for installation (Click Once/Silverlight applications aside). You can, and should still install into Program Files, just don't expect to write into that folder.

You can install software into AppData if you want it to follow a user about in an Active Directory environment, which happens if you put it in AppData\Roaming (the SpecialFolder.ApplicationData location).

You can also install into AppData if you want the software to be available to just the user that installs it. This can be useful if, for example, you have multiple users on the same machine, who all want to run different versions of the software in complete isolation.

If you want settings to only apply on the local machine then you use AppData\Local, which is SpecialFolders.LocalApplicationData - this will make AD administrators very happy as the roaming profile size won't suddenly jump up 50Mb or whatever the size of your software is.

If you wanted to create settings which apply to all users then you're looking at SpecialFolders.CommonApplicationData

You should remember never to rely on the actual name of the directory - localisation issues mean this can change and the location does change with OS versions two. You should be using the special folder enumeration in your software, or the equivalent in your installer.

Could you not install into Program Files, but use AppData as it's supposed to be used, and store your database in there?

Solution 2

Windows 7 added the FOLDERID_UserProgramFiles known folder and by default this maps to %LOCALAPPDATA%\Programs. This is used by MSI when ALLUSERS=2 & MSIINSTALLPERUSER=1.

On Vista and earlier there is no canonical per-user application folder but just using %LOCALAPPDATA% is pretty common. Sadly MSI will just use %ProgramFiles% on these systems.

Solution 3

It's 2019, and I just installed Visual Studio Code (a Microsoft product) in the default folder of

%userprofile%\AppData\Local\Programs\Microsoft VS Code

This is probably for getting around the requirement to have an administrator or UAC prompt authorise the installation

Solution 4

Windows 7 folder structure is deeply inspired on Unix structure:

/usr/ -> C:\Program Files\ -> binaries: executables and dynamically linked
/etc/ -> C:\ProgramData\ -> global settings
/home/ -> C:\Users\ -> a folder for each user
~/.* -> C:\Users\Hikari\AppData\Roaming\ -> settings for each user

Windows has more folder, like My Documents for files with content produced by user, AppData Local and Roaming (which Unix usually handles with NFS).

It's about time for us developers to start using these structures. We must separate at least binary files that don't need to be replicated, global and user settings.

When a setup is installing an app, this setup should expect to have permission to write on Program Files. Once the setup is finished, Program Files should be writable only for other setups aiming to update binaries to other versions.

View more solutions

Comments

[yellahd]

Thanks, that does make sense although it will require some changes to the app code itself which is a pain. The program also has an INI file, which I guess now needs to go with the database into AppData\Local too. The only problem with installing into Program Files is (I guess) that the user would need admin privileges during install, whereas when we were installing into AppData\Local during our experiments, (I'm pretty sure) we 'got away with it'. I do think Microsoft have screwed this up a bit - a per-user, fully-accessible Program Files would have made more sense.

[yellahd]

Ooh, plus I suppose now we'd also have to think about what would happen if another user tried to run the program (via Program Files) under their own account - the app would need to spot it had nothing under that user's AppData\Local folder for itself, and generate a new per-user copy of the database and default settings, etc. sigh It all seems a bit of a mess to me!

[blowdart]

An INI file? How old school are you :) And yes, Program Files does need Admin rights to install, which isn't a bad thing, network admins won't like users having the ability to install willy nilly :) Under windows there's no offical "Per User" install, unless you're using Click Once, which does that, and uses App Data. As for checking for missing databases, you should be doing that anyway ;)

[yellahd]

Heh - I'm very old school! Well, I started this exercise wanting to do things 'properly', and so I shall. I'll get the installer to warn & check for admin rights, I'll put a reference 'blank' database and settings file in with the install and then at app runtime if I detect that they're not present in AppData\Local, I'll copy them across. God knows what this will all look like under XP (it'll be interesting to go and find out what AppData\Local aliases to on the older platform etc). Thanks for your advice, blowdart. Really appreciated it.

[yellahd]

Forgot to say - obviously the settings file needs to become a set of registry keys, too. :-)

[blowdart]

Remember don't use the actual path names, use the SpecialFolders enumeration. Then you don't have to care about what it looks like under each OS

[syplex]

This doesn't address installing the application per-user, which means only that user can access and run the program. If you install to program files, any user on the operating system can run the program. In addition, installing to the local user program files folder doesn't require administrator permissions. Mind you, I am talking about %LocalAppData%\Programs which was designed specifically for installing program files. The app/data separation concept still applies.

[Alex Jansen]

To be fair, the filesystem hierarchy in Unix is completely obtuse as well. Should user data be placed in /usr/local/share because it's architecture independent but only installed on one machine? Or how about /var/opt/ because it's variable data for an optional program? Or maybe just /etc since the data pertains to configuration anyway? At the end of the day it still doesn't make sense and it's easier to "create your own space" in a sub-directory next to the binary and then solve any permissions issues with scripts. This ends up being true on both platforms. /rant

[Hikari]

Yes, unix has its issues. IDK how it's done lately, but years ago it was used to install all apps together in /usr or /usr/bin or /usr/local/bin etc. It's good to have all binaries provided on the same folder and a simple $PATH, but it makes almost impossible to manually uninstall an app because it's not easy to find all its files. Unix was used to be a server OS with little changes on apps over time. In this regard, current Windows structure is simpler.

[Semmel]

It was actually really helpful that you explained all the differences between the folders. Now it suddenly made sense.

[Semmel]

Please never ever put data in %ProgramFiles% whatsoever! Even before UAC, putting configuration files and application data into the application folder was bad practice! (Although it was extremely common.)