Live data from Hacker News

Twenty years maintaining the WiX Toolset

robmensching.com

41–50 of 70 posts

Re: Twenty years maintaining the WiX Toolset

#41
post #5

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 a…

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.

Re: Twenty years maintaining the WiX Toolset

#42
post #41
post #5

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 a…

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…

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.

Re: Twenty years maintaining the WiX Toolset

#44
post #41
post #5

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 a…

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…

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)

Re: Twenty years maintaining the WiX Toolset

#46
post #32

Twenty years maintaining, but the quality of the documentation doesn’t show that. Making an installer in WiX 4 with only one or two fancy things required 3-4 days’ worth of trial-and-error, and searching the WiX sources to figure things out. The docs barely tell you anything.

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 Micros…

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.

Re: Twenty years maintaining the WiX Toolset

#47
post #34

Needs a name change. Absolute no-go in Germany, because the name means "wank".

No matter which term you use, its gonna mean something "bad" in some language. And besides, another company, also called wix (a graphical website builder), used that exact fact in Germany/Austria/Switzerland to make a big marketing campaign.

Yes, but if something has a bad (even mildly so) meaning in American English the name gets changed. This happened to the computer language known as Nimrod, for example - now Nim because Americans do not get sarcasm nor read the Bible. Then there are all the terms like "master" and "blacklist"

Why not treat other languages and cultures equally?

Re: Twenty years maintaining the WiX Toolset

#48
To those who complain about the poor documentation: that's the whole point. The maintainer offers consulting services ($5,000/yr.). It is in his interest that users should need his help.

It's worth it for commercial customers. It's a fair business model for an Open Source project.

Re: Twenty years maintaining the WiX Toolset

#49
post #5

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 a…

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.

Re: Twenty years maintaining the WiX Toolset

#50

Twenty years maintaining, but the quality of the documentation doesn’t show that. Making an installer in WiX 4 with only one or two fancy things required 3-4 days’ worth of trial-and-error, and searching the WiX sources to figure things out. The docs barely tell you anything.

I can recommend Wixsharp ( https://github.com/oleg-shilo/wixsharp ), you no longer have to learn the insane wix xml syntax to create an installer.

I second this recommendation.

In addition to using more sensible and consistent syntax, WixSharp also provides sensible defaults that just work, such as always using "major upgrades" so that you don't have to worry about MSI trying to be clever and sometimes (but sometimes not!) only partially upgrading the app.

Post reply on HN