[dextersgenius]

> 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.

[hypercube33]

I see two main camps of modern application installers, if you want to call them modern. one is Squirrel which is userland based (Microsoft Teams, Spotify, Slack irrc use this) and it's all but impossible to deal with as an admin.

the other camp is Omaha which chrome uses (along with Edge) and runs as a service to handle updates and install.

Neither of these handle the actual problem but push it down the road a bit - you'll find .exe and .MSI installers for both flavors of these applications (usually a boot strap to install the updater and then have that install the application)

I think one push for userland installers was that "you don't need admin" and to some developers it feels like the right place to install an app (user profiles) however I absolutely agree, this makes it a nightmare to deal with as an admin for windows devices.

I really do not like how squirrel handles updates since it feels like any app that uses it you have an in-your-face update experience vs. Omaha where it does background updates and you typically have no idea as a user anything even happened.

As far as code signing I went on a tangent one day trying to figure out why most code isn't signed and I think it's just too expensive and or complicated for developers not forced to be in a position to actually need it - enterprise or an app store requiring it.

[alkonaut]

Squirrel doesn’t have any installation gui or specific process. It downloads and installs version N+1 in the background. Next start will run that version. Any decision to show even a notification that this happened is entirely up to the developer. I think it’s even near impossible to show an “installer” in the traditional sense for the initial install. You can show a splash at initial install that’s it. As far as userland installers go they are all (almost by definition) the same in the end

[alkonaut]

I can see the concern but from the user perspective what’s the solution assuming I want the one week release cycle of dozens of apps?

In the end I think the idea that apps install elevated but run under lower user privs is now completely outdated. One can’t and shouldn’t separate the idea of the user and the application maintainer.

> Also, using AppData to store entire apps is just plan wrong - that's NOT what it was meant for.

It doesn’t seem conceptually wrong to use program files for system wide (not per user) executables and localappdata for per user program files, regardless of whether they are program binaries or program data. Since they aren’t roaming and typically not backed up, what’s the harm in having teams.exe in there?

If chrome dumps large volumes of program binaries into app data\roaming (does it really?) then that sounds really bad. Similarly for any system that would roam anything outside of appdata\roaming.