What are the advantages of installing programs in AppData like Google Chrome?

I just noticed that Chromium was installed in AppData in both Vista and XP. If Google does that and if other applications does this, than is that becuase there is some form of protection? Should we write installers that does the same thing as Google?


Windows still lacks a convention for per-user installation.

  • When an installer asks whether to install for the current user or all users, it really only refers to shortcut placement (Start Menu; Desktop). The actual application files still go in the system-wide %PROGRAMFILES%.
  • Microsoft's own ClickOnce works around this by creating a completely non-standard %USERPROFILE%\Local Settings\Apps (%USERPROFILE%\AppData\Roaming on Vista / Server 2008) directory, with both program files and configuration data in there.

(I'm at a loss why Microsoft couldn't add a per-user Program Files directory in Vista. For example, in OS X, you can create a ~/Applications, and the Finder will give it an appropriate icon. Apps like CrossOver and Adobe AIR automatically use that, defaulting to per-user apps. Thus, no permissions issues.)

What you probably should do: if the user is not an admin, install in the user directory; if they do, give them both options.

One advantage nobody mentioned are silent auto-updates. Chrome has an updater process that runs all the time and immediately updates your chrome installation.

I think their use-case is non-standard. They need a way to fix vulnerability issues (since it's a browser) as soon as possible. Waiting for admins approving every single update company-wide, is simply not good enough.

As far as I can tell, the only reason why Chrome installs into the Application Data folder is so that non-admin users can install it.

The Chrome installer currently does not allow the user to pick where the application is to be installed. Don't do that – instead, give the user a choice between a per-user (somewhere like App Data) and computer-wide (Program Files) installation.

Windows 7 and Windows Installer 5.0 provide real per-user installation capabilities now.


You can sort of fudge it in Vista and XP by using ~/AppData/Local or the equivalent like Chrome does. Microsoft themselves use this for the ClickOnce installers.

So at least on Windows 7 and beyond the solution is simple.

Frankly, I have yet to see the first installer that really allows both per-user and per-machine installations. Many installers offer this option in their GUI, but the setting only affects where the shortcuts etc. go -- the binaries always fo to %ProgramFiles%.

In fact, it is pretty hard to create Windows Installer packages that allow both kinds of installs, to say the least. With the advent of UAC, I'd say its is impossible: Per user installations must not require elevation, per machine installations have to. But whether an MSI package requires elevation is controlled via a bit in the summary information stream -- there is no way to have user input have impact on that.

Whether per-user or per-machine is the better choice greatly deoends on the application. For small packages, however, I tend to prefer per-user installations. Besides being slightly more user-friendly by not requiring an UAC prompt or runas, they also signalize the user that the setup will not do much harm to the computer (assuming he is a non-admin).

The Chrome installer really ought to allow global installation (with elevation) in addition to per-user. I don't want to have to maintain an installation for every user; I want to be able to centrally manage upgrades and so on. Chrome doesn't allow that.

That said, the option to install per-user is quite nice, as it means no permissions issues.

Just so you people know, Google has created an MSI installer for global system installation and management. It's located here:


I do not see anything in %PROGRAMFILES% on Win7. Looks like Chrome must be installed for each user on the machine.

Perhaps the true reason of doing this is faking number of Chrome installations by few times ! Thus making it first browser in the world !

Need Your Help

"Cannot call methods on DateTime", and other limitations

.net sql linq linq-to-sql

Does anyone know of a definitive list of LINQ to SQL query limitations that are not trapped at compile time, along with (where possible) workarounds for the limitations?