Still used in Windows IT environments as it's portable, even if it is a bit slow and there is no console version for generating tree-maps for remote viewing.
I'm wondering how much of the frustration in the comments here is due as much to the arcane design of the Windows Installer format as to shortfalls in WiX and its documentation. I would say that you need a good understanding of MSI databases before trying to use WiX, which implies thinking about the installer while developing the app, which was the goal of the toolkit.
Packaging can be hard on any platform but Microsoft really outdid itsself with MSI. If you already have a finished product and just need to package it then NSIS or Inno were much simpler to pick up.
Many products are released as MSI files because that's what enterprise deployment tooling supported, but inside is a setup executable, which defeats the entire transactional rollback design of the thing.
The Windows Installer format is very poor indeed, but WiX adds too little to improve the situation much. Most people I know have created Python scripts to add more layers of abstraction to make installers easier to manage. I wish WiX shipped with those abstractions. At the moment, WiX feels like a box of parts for a kit car when I only need to adjust mirrors and change radio channel. Documentation adds to the frustration, because while it tells you details about specific parts, it doesn't offer a broader view: how parts connect to each other to form a drivable car. So you're left guessing and improvising, and you introduce bugs every time your intuition doesn't match how things really work.
If you’re building something simple (dump files into Program FIles + create a shortcut), WiX is not that hard, and it does not require much understanding of the MSI internals. But the docs just aren’t there to help you and to tell you the five things about MSI you need to understand, and there are no complete and self-contained example WiX projects.
When Microsoft launched the (let's face it, baroque) complexity that is Windows Installer (MSI), we didn't get the WiX Toolset, instead we got an expensive proprietary profiling tool for capturing before/after snapshots, and an entry-level version bundled on the Windows 2000 CD which didn't really solve anybody's problem. No suprises then that the MSI format didn't immediately take over, and Microsoft would presume all the way to Intune that their customers were deploying MSI packages when mostly we weren't.
I always wondered what would have happened if the WiX Toolset had been available from the start, and I like to compare the more organic success of the Microsoft Deployment Toolkit (MDT) being more open and hackable as an example. I guess the time just wasn't right.
This is a bit tangential, but I consider all this complexity to be a code smell. The real answer to the problem MSI, WiX, and on Linux package managers and nix are trying to solve is the wrong problem.
The entire concept of installing application software “on” the system in a way that modifies the OS is deeply flawed. It’s a security nightmare and it doesn’t scale. As you try to scale it you inevitably have to build a massive baroque state management system that is brittle and terrible for developers to use.
Mobile has the right idea here. Apps are containers. If it seems like an app needs to reach outside of its container this in fact is revealing a shortcoming of the OS APIs that should be addressed there.
Installing an app should be a matter of dropping it on the system. Uninstalling it should be a matter of deleting it.
There might still be a niche for installers in this world but they would be for drivers and OS level third party enhancements. There would not be many of these. 99% of apps do not need this level of access.
Going back to the first paragraph: if you find yourself trudging through a tangled swamp of complexity with no end in sight, I personally believe that this a sign that you are either solving the wrong problem or solving it in a fundamentally wrong way.
When confronted with this a good developer will solve it. A great developer will question it. A genius will make it unnecessary.
The question to always be asking is: is this incidental complexity or essential complexity? Essential complexity is present in the real world problems being solved. Incidental complexity is self inflicted. I personally believe that most software complexity is incidental. It’s at least more than half.
I feel like this comment awkwardly intermixes the problems of global shared-state package management (which Nix does not suffer from), and runtime isolation (which Flatpak/Portals are for).
EDIT: I do think there's a lot of interesting space to explore, for bringing isolation concepts into NixOS (or one of the other nix-based distro-likes)
In what way do you feel Nix doesn't achieve this? Because software can still ultimately rely on system state?
I'd contend Nix is the best package management system yet, and while its certainly complex, much of that complexity only exists to hack around decades of bodges.
I really tried to use msi back when it appeared but it wouldn't work in certain versions of Windows without installing something else before. I can't remember the details but it was self defeating.
Now the same thing happens with msix. Looks nice, but want to manage services through it? Only allowed on consumer editions, not on fairly recent server systems. Totally makes sense /s
I'm not sure what your experience is, but in the vast majority of enterprise AD forests, most apps are deployed by MSI and have been for quite a while. MSI actually took off really quickly, and most installer kits shrank a lot, many disappearing. These days most of the remaining large commercial installer kits generate MSIs as well as EXEs.
In my experience large Microsoft customers deployed applications with SCCM, now perhaps moving to Intune. Distributing MSIs via group policy is fairly primitive compared to what endpoint management platforms can offer.
But my point was that large commercial installer kits were always required to produce MSIs, in the absence of something like the WiX Toolset.
Isn't the licensing an issue? As far as I can tell you can't use Obsidian at your workplace without an annual commercial license, which is fair enough but maybe too heavy a lift for many.
You'll care about it if you can't pay for you coffee at Starbucks or whatever. I'm not if there is overlap between Oracle's public cloud and their own hosted services, but a lot of hospitality runs on Oracle (formerly Micros Fidelio) Simphony, and they are moving their customers from on-prem to Oracle Cloud.
The JRE security horrorshow might have started before the Oracle aquisition, and we wanted rid of java on the desktop for the same reason we wanted rid of flash. Apple used to advertise that only Windows suffered from viruses until their own unpatched JRE was exploited widely. Oracle contributed by making updates burdensome to download, and now unavailable without a support agreement, but what stopped java GUI apps from succeeding is at least partly the truly endless stream of remote code execution vulns if the JRE was available to the browser.
I think you might be onto something. MS' C#, which is a near 1:1 copy of Java and what it aims to accomplish, has never suffered the same issues as Java's JRE. You have to wonder if that's because MS gets away with baking CLR updates quietly into Windows whereas JRE updates are more difficult to deploy.
The incentives were always misaligned for a third party framework like Java, even from someone as big as Sun, and now Oracle.
Java was never going to be able to keep up a reasonable native UI binding, because OS vendors were at best ambivalent and at worst actively hostile, because there was nothing in making it work that benefited them.
Security without centralized platform control (e.g. Windows Update, AppStore, Play) was likewise an excercise in futility.
Most of the high profile security issues have been either sandbox escapes or serialization issues.
The sandbox escapes were made worse by having applets in the browser.
Now that applets are not a consideration any more the sandbox (SecurityManager) isn't used very much anymore and the Java devs are looking at deprecating and removing it, so most of the sandboxing features will go away.
