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.
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.
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.
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…
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.
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.
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.
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 l…
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…
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
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 yo…
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.
This is very handy! Especially for installers. Thanks, I'll write it to my list of handy tools.
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.
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.
Or maybe he is just telling how it is. Have you contributed to it or tried?
Yup I have been using it for over a decade, and had nothing but pleasant interactions with the maintainer. I am heartily sick of this culture of entitled people that think it is OK to free load on someone else's hard work and then take a public dump on them, that too while hiding behind an alias! And then there are people like you that enable such behavior instead of calling it out. Mensching, the maintainer here, ha…
When you try to contribute to a project and the maintainer just says something isn’t a bug and won’t tell you why and blows you off. They are hostile. So while he’s built an awesome tool. He’s obviously a difficult person.
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.
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 yo…
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.
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?