> These days it’s more and more common to completely ignore the windows installer system and install per-user to app data, which has the benefit of allowing a better self-updating experience without elevated permissions, and lower risk of pollution of system files.

On the flip side, this is a nightmare to manage as sysadmins, who try to maintain a tight ship using AppLocker polices. So many apps these days have a standard installer, but then they download an update and try to run the newer version from AppData, and of course, it gets blocked and we get calls from angry users saying that their app no longer works. Of course, we could whitelist the digitally-signed executable, but some apps aren't even digitally signed (or only partially signed), sometimes the digital signature changes completely... it's a mess.

Then there's the problem of dumping large binaries and entire applications into the AppData folders, which bloats up user profiles. This can be a bit of an issue with certain roaming profile systems like Citrix User Profile Manager, which by default works in a blacklist mode (ie, you have to explicitly blacklist paths that you don't want to roam). If you don't stay on top of this and add new AppData subfolders to the exclusion list, then you'll find all your large Chrome updates or whatever (with several versioned folders) all syncing back up to the profile server, wasting space, bandwidth, and increasing logon, backup, and AV Scan times. In a large organization with several thousands of users, this is a disaster waiting to happen.

Also, using AppData to store entire apps is just plan wrong - that's NOT what it was meant for. AppData was meant for storing app data, and the apps themselves are supposed to be stored in Program Files.

These self-updating apps are the worst thing that could ever happen in a corporate environment.