Hacker News Reader

Comment by daigoba66 | Hacker News Reader

For installers, use http://wixtoolset.org/.

Yeah, because I really want to spend hours upon hours studying obscure incantations that someone decided to be making sense.

WiX (and MSI, for that matter) is a disaster.

It’s really not that bad. WiX is actually pretty decent, definitely not a “disaster”. It might look more frightening than InstallShield because you don’t get a nice UI that allows you to set up an installer with a few clicks, but I mean, we’re programmers here, surely editing textual configuration files is not an issue? It took me somethong like 30 minutes to replace our old InstallShield installer with WiX.

I gave it a shot for a day recently but found it way harder to use than InstallShield or NSIS. Part of it was probably the broken documentation where half the links just ended in nirvana. But I gave up when I learned you really have to add each single file one-by-one and the documentation even defended this as a feature.

You can use this Wix tool or command called Heat, which will automate the adding (and creating GUIDs) for a bunch of files. Really it's the underlying MSI target that's so painful, especially when you get into versioning. The OS wants to have detailed information on every file that is part of your installation. I think this is primarily for uninstallation purposes, but also for upgrades and who know what else. If I could get away with it, I'd just use NullSoft. It's like writing assembly, but it's so much simpler.

With Wix/MSI, there were certain executables that I could never get it to run as part of the install process. The XML would look the same as other execute commands that worked, but I could never figure out why they didn't run.

Amen.

This can "kinda" be worked around with "heat.exe" (don't get me started on naming of tools in the toolchain), but even then you'll need to explicitly specify half a dozen command-line arguments (-ag -dr -cg -srd -scom -sreg -svb6 -sfrag) to make the thing work.

So how would one deal with projects that contain 1000s of files?

Run a script to enumerate the files and populate a wix file? Zip up the different parts and have the installation process unzip them?

Don't mean to sound like an ass, but oh really?

WiX is a thin wrapper around MSI (which sucks beyond belief) and as such it suffers full blast from all the "design" decisions of the latter, not even trying to remedy the situation.

I really could pour out a full-blown rant on MSI in general and WiX in particular, but that would be wildly offtopic and of no interest to fellow HNers.

If you think MSI is bad, and I'll have to take your word for it, what MS had prior to it was probably worse. Writing installers for Windows using MS tools has always been a nightmare.

He's not wrong: WiX is a horrorshow. It's unintuitive, difficult to read and parse, and is saddled with much of the cruft of years of Windows; when you compare it (or NSIS, or InstallShield) to building an .app (or even a .pkg) under OS X, it fares very poorly.

The same can be said of programming in general.

It's true that msi is different from other installer builders, but it's for a reason. And if you have a concrete project you can build while following along with the wix tutorials and book, it's not difficult, it just takes some time.

Yeah, the "reason" being that Windows Installer was designed to support corporate deployment of applications to shared machines with install-on-demand and roaming profiles, and to support Windows 95 and up. This, and Microsoft's manic affection to backwards compatibility plus "architecture astronautery" (on-demand installs of COM objects, anyone) makes MSI a disaster.

The fault of WiX is that it's too thin of a wrapper.

Wait, weren't you complaining about all the "wizard clickety clicky" things in another thread?

If you hate wizards, and you hate "obscure incantations", which I'm assuming means code, then what do you like? Do you program in natural language with voice recognition?

Where's the conflict?

By "obscure incantations" I mean having _three_ different syntaxes for string interpolation/variable substitution, providing _six_ command line arguments for the tool so that it does the one reasonable thing, having illogical rules in comparison operators, having to use a frickin' _bootstrapper_ to install prerequisites and not being able to chain MSIs, not being able to have a single installer for x86 and x64, not having a _simple_ way to define logic for "Back" button, yet having to write heavily nested XML to do simplest thing.

I've always liked InnoSetup (http://www.jrsoftware.org/isinfo.php). You describe your installation in a short file created via its syntax-highlighting IDE. A big con is that its scripting is done in Pascal, but you can likely find existing scripts to do many common operations.

While that's obviously a solution, it's not quite the same y'know? There's a lot more skill overhead in learning that tool vs the comparative ease of the installer project.

Considering how thoroughly MS screwed the pooch on ClickOnce, I was genuinely surprised when they completely abandoned their working installer system.

What's wrong with ClickOnce? I've not used it from a developer's perspective, but Chrome's installation (which uses it) always seems smooth as butter.

There's a lot of things wrong with ClickOnce. IIRC chrome's installer only uses clickonce as a bootstrapping mechanism for the _actual_ installer.

Problems:

* Can't choose installation path * No offline installation * Hard (impossible?) to use with a CDN.

Here's an example of how to turn a directory of precompiled binaries into a click once package using powershell:

https://gist.github.com/jonnii/2628150

My powershell isn't _great_, so forgive any powershell oddities, but notice how much you have to massage the output of the mage tools to actually get it to do what you want.

For small things ClickOnce is fine, but it's a pain in the ass to automate. For example, there's no way to synchronize the 'version' of the installer with the version of the EXE it's installing. I had to hack[1] it so I could pull the version metadata off the EXE assembly and then force it into the XML of the project file where the ClickOnce settings are stored.

There's also no ability to publish the built installer outside of the UI- my build scripts had to build the /app.publish directory and then just copy the whole shebang to a network location for deployment. I'm not as upset about this being a separate step, but if they indeed allow you to configure and deploy the installer from within the UI why not expose an API to do it as well?

Overall I think ClickOnce is fine for internal, self-updating tools. It's worth noting, however, that I was inspired to create my workflow based on looking at what Github was doing with their windows client.

[1]: http://whazzing.com/blog/2013/04/11/automated-clickonce-buil...

Or Advanced Installer's free edition if you're xml-challenged.

Reply on news.ycombinator.com