Twenty years maintaining the WiX Toolset(robmensching.com)
robmensching.com
Twenty years maintaining the WiX Toolset
https://robmensching.com/blog/posts/2024/04/05/twenty-years-maintaining-the-wix-toolset/
69 comments
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.
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)
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'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.
But my point was that large commercial installer kits were always required to produce MSIs, in the absence of something like the WiX Toolset.
Using SCCM doesn't preclude MSIs at all. MSIs via group policy are probably used 1000x more often than SCCM.
OR Ansible.
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.
It's worth it for commercial customers. It's a fair business model for an Open Source project.
To have customers for their consulting business, they first need to convince people WiX is the way to go, and if there are no docs and developers struggle with building the most basic installer, they would probably try looking elsewhere before burning $5000. Speaking of $5000, that’s $500 more than a 3-year InstallShield subscription.
Really the dig should be on Microsoft -- I had to hand write an xml for WiX to push out a small single exe project and if I had hair left I'd have ripped it clear out -- how is making an MSI file harder than say NSIS or innosetup? I get their toolage is for visual studio projects but I wrote this outside of that so I'm on my own.
If you only need the basics, you can also use GNOME's msitools[0], which use the same XML format as WiX but don't require Windows to build the MSI package.
[0] https://wiki.gnome.org/msitools
[0] https://wiki.gnome.org/msitools
Isn’t WiX 4 now cross-platform, the SDK at least?
Is it? All I see about platforms in the release notes is in the context of different processor architectures.
To run WiX you would presumably also need the Windows Installer libraries that are part of Windows, which I suspect are not cross-platform. Msitools uses Wine's implementation instead.
To run WiX you would presumably also need the Windows Installer libraries that are part of Windows, which I suspect are not cross-platform. Msitools uses Wine's implementation instead.
I have to agree with others here. It's better to use Wix as a thin layer on top of Windows Installer but the documentation is very, very poor.
I spent a week of trial and error to create an installer just to find out that I had several installations of my app because of some misconfigured xml document from testing. A nightmare to uninstall to say the least.
I highly recommend to test your installers inside a VM or you'll screw up your system.
Also good luck if you want custom behaviour from the installer. The documentation for that is far worse than it is for the standard msi installer.
I spent a week of trial and error to create an installer just to find out that I had several installations of my app because of some misconfigured xml document from testing. A nightmare to uninstall to say the least.
I highly recommend to test your installers inside a VM or you'll screw up your system.
Also good luck if you want custom behaviour from the installer. The documentation for that is far worse than it is for the standard msi installer.
I recently learned about the "Windows Sandbox"
https://learn.microsoft.com/en-us/windows/security/applicati...
Perfect for testing things that might screw up a Windows system in a 'clean' environment.
https://learn.microsoft.com/en-us/windows/security/applicati...
Perfect for testing things that might screw up a Windows system in a 'clean' environment.
Sandbox is great in general, but it might not work for working with something deeply integrated into Windows (I remember some installer failing because a Microsoft thing wouldn’t install).
> Pristine: Every time Windows Sandbox runs, it's as clean as a brand-new installation of Windows.
I can see my custom fonts in the Sandbox. Which makes me wonder, what else is not actually pristine about it?
> Pristine: Every time Windows Sandbox runs, it's as clean as a brand-new installation of Windows.
I can see my custom fonts in the Sandbox. Which makes me wonder, what else is not actually pristine about it?
This is very handy! Especially for installers. Thanks, I'll write it to my list of handy tools.
For those like me (I never used Windows) who do not know WiX; https://wixtoolset.org/.
lol, from the title i was absolutely convinced that he was talking about https://www.wix.com/
I indeed clicked it because I thought that as well.
Same. I was confused that anyone would be proud of Wix. It builds the most terrible websites I've ever encountered. They literally require sequential loading of javascripts from something like 5 different domains.
Here's my experience loading a wix site: First load: nothing, so I enable javascript execution for base domain. This requests scripts from a second domain which when allowed manually requires scripts from a third domain which when loaded requires scripts to execute from a fourth domain. By this time I've closed the tab.
Here's my experience loading a wix site: First load: nothing, so I enable javascript execution for base domain. This requests scripts from a second domain which when allowed manually requires scripts from a third domain which when loaded requires scripts to execute from a fourth domain. By this time I've closed the tab.
The capitalization gave it away for me
[deleted]
Looks like https://www.firegiant.com/blog/2024/4/5/looking-back-at-twen... is the better link?
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 wasn't able to figure it out. The docs [1] have absolutely no information or overview on how the tool works, or how you should get started with creating a simple installer. Besides setup instructions, it only has details on individual sub components, beginning with with "Burn bundles". All linked tutorials are for previous versions of WiX. Is the expected workflow that I read a v3 tutorial and then read the "v4 for v3 users" article (which immediately leaves me discouraged with "A lot about WiX has changed between v3 and v4"), or that I immediately purchase enterprise support?
[1]: https://wixtoolset.org/docs/
[1]: https://wixtoolset.org/docs/
My favourite page is "Specifying source files" [0], which seems like an important thing for an installer, but all this page contains is:
> To be written. To volunteer, leave a comment at the related issue on GitHub.
If you start with Visual Studio, create a project with their (free) plugin, and configure Heat [1], you might get a working installer.
[0]: https://wixtoolset.org/docs/tools/payloads/
[1]: https://wixtoolset.org/docs/tools/heat/
> To be written. To volunteer, leave a comment at the related issue on GitHub.
If you start with Visual Studio, create a project with their (free) plugin, and configure Heat [1], you might get a working installer.
[0]: https://wixtoolset.org/docs/tools/payloads/
[1]: https://wixtoolset.org/docs/tools/heat/
I used to use WiX for simple app deployments (create Programs File folder, dump assets) and Windows Services. The v3 documentation is decent for this.
https://wixtoolset.org/docs/v3/
I’m not sure what development in the MSI world necessitates a radical change in how WiX functions, but apparently that is the case.
orca.exe from one of the older Win SDKs can really help with your understanding of the MSI format, which helps when building for WiX.
orca.exe from one of the older Win SDKs can really help with your understanding of the MSI format, which helps when building for WiX.
Same, but I just gave up after 2 days. I really wish there was a one-click option in VS.net to create an installer that checks/pulls the required version of runtime, installs the target exe, all its DLL dependencies, and all custom files marked for release.
It's what 99.9% of apps need, so why is there no "do the defaults" path? You even need to pass things through the Heat generator to get multiple resulting files listed automatically. This is not an exclusive Wix issue though - no project offers that as far as I can tell and it really sucks.
It's what 99.9% of apps need, so why is there no "do the defaults" path? You even need to pass things through the Heat generator to get multiple resulting files listed automatically. This is not an exclusive Wix issue though - no project offers that as far as I can tell and it really sucks.
I'm not a developer for Windows apps but had to use WiX to generate an installer for a Python open source project I am collaborating with. Installing one binary in a specific location? Easy. Couple hundred files distributed among multiple nested directories? That was a miserable experience and but I could manage to pull it off. I didn't use heat. The XML was hand-coded and the file listing was generated with a Python script that walked the directory tree and generated the Directory, Component and ComponentGroup entries.
Apparently with Wix4, heat is deprecated, unneeded in Wix5. I couldn't even get it to install and have the executable. So confusing!
Apparently with Wix4, heat is deprecated, unneeded in Wix5. I couldn't even get it to install and have the executable. So confusing!
heh, I recently "ported" a Linux app to Windows and wrote a simple installer using wix 5 (it was horrible)
to even obtain wix v5: first, using scoop, I installed "dotnet-sdk"; second, using the "dotnet" command, I got the wix.exe executable via
> dotnet tool install --prerelease --global wix
to even obtain wix v5: first, using scoop, I installed "dotnet-sdk"; second, using the "dotnet" command, I got the wix.exe executable via
> dotnet tool install --prerelease --global wix
Agreed. Even basic things like detecting if the installer is making a fresh install or upgrading existing installation require arcane condition checks: https://stackoverflow.com/questions/320921/how-to-add-a-wix-... And worst of all, all sources I've ever found (including the linked answers) contain at least a few mistakes or unhandled cases, so I'm not confident enough to make any improvements. Documentation could really use battle-tested examples from people who understand MSI installers very well.
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.
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.
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.
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.
I switched from wix to NSIS. It's not perfect but it's certainly a lot easier, and whatever problem you may have, the solution is usually only a Google search away.
I’ve been keeping a pulse on Tauri for a long time. They’re thinking the same, I believe, because they are trying to move over.
And Wix is just installation on one out of 5-6 platforms. Native development is so convoluted and riddled with complexity. Linux though is no exception, since this it’s a distro issue. MacOS is generally much better, with fewer moving pieces – most of the overhead is from notarizing and signing…
And Wix is just installation on one out of 5-6 platforms. Native development is so convoluted and riddled with complexity. Linux though is no exception, since this it’s a distro issue. MacOS is generally much better, with fewer moving pieces – most of the overhead is from notarizing and signing…
Maybe we should try LLMs to generate documentation.
Why not cut out the middleman and have it generate the XML? Or let the LLM generate the MSI database directly, without WiX. (Good luck debugging!)
LOL! I was asking Gemini Wix questions. The answers were wrong! When I pointed that out I got apologies and more code that didn't work. As with most newbies, I finally trial and error'ed my way out. I want to know how the "experts" have figured out how to use Wix. What is it that I should know but don't about learning Wix?
I actually got a working WiX MSI only because of GPT helping make 90% of the installer. the rest were random stack exchange posts because the docs or guides I found to write the XML were way off, old, too new for wix3 or something else was absolutely missing.
[deleted]
I remember having to use it at an employer many many years ago. The documentation was horrible and nothing was intuitive about the XML.
Yeah it's a thin layer over MSI tables, so if you don't already know how Windows Installer works then it's not at all clear how to do many seemingly-basic installer tasks. And few people really know how Windows Installer works because that is itself obscure, poorly designed and documented.
But a thin layer over MSI is actually what you want; the commercial tools that preceded WiX and tried to abstract away what Windows Installer was actually doing were much worse. Because Windows Installer is such a mess of counterintuitive design and bugs that you are going to need to debug it.
WiX is to be saluted for greatly reducing the level of misery involved in making installers for Windows. But the level of misery is still very high indeed.
But a thin layer over MSI is actually what you want; the commercial tools that preceded WiX and tried to abstract away what Windows Installer was actually doing were much worse. Because Windows Installer is such a mess of counterintuitive design and bugs that you are going to need to debug it.
WiX is to be saluted for greatly reducing the level of misery involved in making installers for Windows. But the level of misery is still very high indeed.
Agree. Learning windows installer is bananas because it is super unintuitive.
Intentionally so in parts, because they do not want you to interact with it outside the API.
Example: https://learn.microsoft.com/en-us/windows/win32/msi/msifileh...
You could be forgiven for not catching on that this table is just using slightly obfuscated MD5 hashes.
Intentionally so in parts, because they do not want you to interact with it outside the API.
Example: https://learn.microsoft.com/en-us/windows/win32/msi/msifileh...
You could be forgiven for not catching on that this table is just using slightly obfuscated MD5 hashes.
[deleted]
Needs a name change. Absolute no-go in Germany, because the name means "wank".
It doesn't need a name change. You would write wank in a completely different way only the spelling sounds the same.
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?
Why not treat other languages and cultures equally?
But a different spelling
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.