FictionSoft Blog

In my last post, I mentioned the fact that NSIS doesn’t use XML as a reason why I preferred it over WIX.

I think maybe I should explain that a little better.

There seems to be a popular thought in many circles that XML is a great way to represent Domain Specific Languages. It’s possible that Ant and NAnt have been largely responsible for this, although who really knows for sure. I’m certainly not against using XML when it makes sense. XML can be a great way to represent many kinds of data, and it makes storing and parsing data a relatively simple from a programming perspective. But the same structure that makes it easy for a computer to parse adds visual noise for humans trying to read it, not to mention type it.

If you want to use XML as a way to create a DSL without all the hassle of creating grammars and parsers, then go right ahead. Just be conscious of the fact that you’re trading ease of use for easier DSL development. But if you’re creating a DSL that will be used by many people over a long period of time, like WIX or NSIS, your users will be much better off if you take the time to come up with a suitable abstraction. Of course, if your target abstraction is a visual one, then it might make a lot of sense to go with XML.

I have to admit I wasn’t really sold on WIX right from the start. But the developers who were in charge of creating our installers thought it sounded like the bees knees. What they found out a little too late is that, like a lot of things from Microsoft, it’s easy to do the 80% that most people need, but you better pray you don’t need the other 20% because trying to extend WIX adds crazy levels of complexity to your installer and build scripts.

What, you want to write a custom action in C#?

It took 2 developers and months of full-time development to create a set of installers with what should have been relatively simple UI and logic customizations. Nobody was happy with the outcome. The WIX builds simply had too many moving parts, causing frequent breakage, and bringing new team members up to speed on the complex build process was a hassle. After about a year of using the old installers, the pain got to be too much and we decided to look for a new solution. Another developer implemented the same custom logic and UIs as in the old installers (plus some additional stuff) by himself in 2-3 weeks using NSIS. And the resulting installer scripts were much simpler.

So what does NSIS have going for it, over WIX, in my opinion?

• Well, to start with, it doesn’t use XML for its syntax. On the surface, NSIS might appear to have a steeper learning curve because it uses its own scripting language. But it really isn’t very complicated(*), and you can get a basic installer working in minutes.
• It’s a very mature installer platform that has been around for years.
• NSIS is used by countless projects, including some very big names, and has a massive community built around it.
• The installer UI is very easy to customize (much more so than WIX, and without the weird compiler errors if a UI element is one pixel off), and there is even a UI designer plugin for Eclipse. 

So if you’re looking for a robust installer framework for your project that won’t break the bank, check out NSIS.

 (*) This isn’t to say NSIS syntax isn’t without its quirks. The lack of variable scoping and the need to push and pop function parameters using the stack, for example, might scare some people away. However both issues are fairly simple to deal with using macros and a little creative naming.

 (EDIT: Closing comments due to heavy spamming)

Yeah, I’m what you’d call a geek. So here goes the obligatory introduction in my current native tongue:

public static void main()
{
Console.WriteLine(”Hello World!”);
}