On Installers

Posted:  Updated: | Tags: wix

Like many, I tend to try to shy away from tasks that aren’t directly related to writing code. Recently, I wrote my first installer for an application, and it made me think: “Why have I been avoiding doing this from the get-go for every project?”

The “Simple” way

Consider the simplest possible way to install software: copying directly from the build output directory. It sure seems like it should be the least time consuming overall. But thinking about it, it really only saves time if:

  1. Your application’s install procedure is trivial. This means adding services, making tasks, creating event logs, etc. are out of the question. Despite being “easy”, there’s more than two steps involved in that
  2. Your application’s prerequisites are almost certainly installed on your target system. For instance, .Net 4.0+ on a Windows machine
  3. You’re only installing something once: the likelihood of updates is non-existant
  4. You’re the only one performing the installation. You’re going to have to communicate some steps anyway

As soon as you start making your way away from the most uncomplicated situation, you have to start writing some degree of a checklist enumerating important steps or required preinstalled software or something. And working your way through that checklist more than once is likely to be time-consuming and, thus, costly.

The Automated Checklist

Ultimately, we just want this checklist to be automated. An installer is simply a checklist (albeit somewhat slightly more complex) that the computer executes for you. Since you’re already going to be documenting what needs to be installed on a target system and how to property set it up, why not make your installer code your “documentation”?

This opens up the potential for workflows where you test an installer on a clean virtual machine. Since it’s so fast and easy, perhaps you could have your installer tested on every build/commit?

Instead of putting off writing an installer, just get to the point that you can write a quick and simple installer for every package you intend to deliver. That way if you need to push an update (and what useful piece of software doesn’t have updates?) you can make sure that the time taken to update is very small, even if it’s not you who ends up performing the deployment. With mindful practice and self-optimization, the overhead of writing a simple installer reduces to only little more than the checklist you would have had to write anyway.