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.
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.