3 ms·

An “everything” software listing and uninstaller front end for the various install methods (nuget, steam, msi, …) to see everything in one place is an excellent

An “everything” software listing and uninstaller front end for the various install methods (nuget, steam, msi, …) to see everything in one place is an excellent idea. Even better if it allowed plugins so you could add methods (e.g a developer might want a node env listing). It should stick to being a front end though and not try to be too clever when it comes to deleting things. A misconception is that it’s possible to accurately determine whether something can or should be removed, when it’s usually impossible. The only thing that can uninstall windows software in general is the installer that installed it (if it’s correct), or a program that at least observed and recorded the installation of it. Any software that claims otherwise is lying, and at best it will fail and at worst it will make a mess of your system. 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. The worst offenders in my experience when it comes to traditional windows installers are those that are not using Windows Installer but instead simply act as scripts dumping files and reg entries without concern for transactionality, sharing etc. For example some flavors of installshield and similar. The Windows installer system for all its flaws IS a pretty robust - but quite complicated - system for managing installs. The problem is that it’s either unused or misused, which is a consequence of it being too complex I guess.

viraptor 3y ago
I'm amazed how much MS is failing with the MSI. You'd expect that in Visual Studio (the proper one, not code) there would be a simple way to say: this project - compile it and stick into MSI with just bare defaults. But no, you essentially have to get a third party thing to manage creating that for you, and even those involve custom scripting that requires another custom generator on top to get the list of files to install (looking at you, Vix). And no, the publish to Azure or ClickOnce are not reasonable options. VB5 came with a built in installer generator - how did we regress from there?
- dextersgenius 3y ago
  MSIs are so bloated and horribly designed, it isn't even funny. Why does it insist on storing a copy of the entire .msi - and any patches - in C:\Windows\Installer? From what I've observed, the original MSI is required to perform repairs and reconfiguration, or setting up new-user defaults for that app. This seems horribly inefficient to me, and on heavily used system this can easily waste space on the C: drive. And occasionally you run into issues with the MSI database corrupting, where you can't install/upgrade/uninstall something (we see this commonly with Adobe apps) , so you'd need to resort to third-party tools like MSI Zapper to get rid of all the references from the database. What a messy system. I miss the days when programs used to use NSIS (Nullsoft) installers - they were tiny, and super easy to make and automate.
  - alkonaut 3y ago
    To make an uninstall of course you need the msi db parts (but you wouldn’t need the entire binary content). To make a reinstall (aka repair) you DO need both the db and the content. I haven’t heard msis being bloated. I assume they contain exactly what they need to contain (though unsure about compression methods). In the past when storage was scarce it seems like a strange design but these days I can’t say it feels so wrong.
dextersgenius 3y ago
> 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 3y ago
  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.

viraptor 3y ago

I'm amazed how much MS is failing with the MSI. You'd expect that in Visual Studio (the proper one, not code) there would be a simple way to say: this project - compile it and stick into MSI with just bare defaults. But no, you essentially have to get a third party thing to manage creating that for you, and even those involve custom scripting that requires another custom generator on top to get the list of files to install (looking at you, Vix). And no, the publish to Azure or ClickOnce are not reasonable options. VB5 came with a built in installer generator - how did we regress from there?

dextersgenius 3y ago
MSIs are so bloated and horribly designed, it isn't even funny. Why does it insist on storing a copy of the entire .msi - and any patches - in C:\Windows\Installer? From what I've observed, the original MSI is required to perform repairs and reconfiguration, or setting up new-user defaults for that app. This seems horribly inefficient to me, and on heavily used system this can easily waste space on the C: drive. And occasionally you run into issues with the MSI database corrupting, where you can't install/upgrade/uninstall something (we see this commonly with Adobe apps) , so you'd need to resort to third-party tools like MSI Zapper to get rid of all the references from the database. What a messy system. I miss the days when programs used to use NSIS (Nullsoft) installers - they were tiny, and super easy to make and automate.
- alkonaut 3y ago
  To make an uninstall of course you need the msi db parts (but you wouldn’t need the entire binary content). To make a reinstall (aka repair) you DO need both the db and the content. I haven’t heard msis being bloated. I assume they contain exactly what they need to contain (though unsure about compression methods). In the past when storage was scarce it seems like a strange design but these days I can’t say it feels so wrong.

dextersgenius 3y ago

> 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 3y ago
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.