I want to do a quick comparison of NSIS and WiX. Of course, NSIS creates and executable and WiX creates an MSI, so there will have to be some discussion about whether there really are any benefits to an MSI over an EXE installer.
As many of you know, I work for LANDesk. In 2008/2009 I developed a plugin for my company’s software. I built the plugin in C#. I used Visual Studio to create the plugin.
I wanted an installer that created the install package whenever ran a build in Visual Studio.
I succeeded in doing this using NSIS (Nullsoft Scriptable Install System).
Ok, so since I have a nice working solution, I am not going to change my plugin to use a different installer, even if my NSIS and WiX evaluation shows WiX to be better. However, on future projects where a solution isn’t yet in place, or when recommending a solution to others, I may decide to use the better one of the two.
P.S. If there is a third installer tool that is free that you think is better, feel free to comment about it.
Also, I obviously bit off more than I can chew with this post, so it is unfinished. Of course, there is no reason that new experiences can’t lead me to update this or that comments cannot help me finish this.
NSIS is script-based.
See the list of features here:
It also has a lot of users.
For my plugin, I actually created the .nsi script by hand the first time and thought it decently complex. However, shortly thereafter an Eclipse plugin was created, and I created a sample with the Eclipse plugin and modified it and it is rock solid.
Anyway, now I have a project that included my .nsi file, I was able to use the command line tool, makensis.exe, to run with two parameters: the .nsi file and the output file name.
"C:\Program Files\NSIS\makensis.exe" "$(ProjectDir)Installer\LANDesk Support Tools.nsi" "$(ProjectDir)Installer\LANDesk Support Tools_Beta_6.exe"
I am extremely happy with NSIS.
I like it for the following features:
- It was easy to use (especially with the Eclipse plugin)
- It created a small installer.
- It runs silently when passed the -S parameter.
- There was lots of documentation.
- There were plenty of add-on features.
- I had the option to include all files in a folder in my installer or specify the files individually (same with the uninstaller). This is nice because if I create a new file in a folder that is already picked up by the installer, I don’t have to change the installer or uninstaller at all.
- Support for other languages was rather easy to add into my installer.
- It was simple to integrate with Visual Studio (add a single command in the post-build section).
- Notepad++ has colored syntax for it (though unfortunately Visual Studio does not but I was able to change the default tool to open it with to be Notepad++)
- It has an intuitive method for creating Install Sections.
- I can provide my installer script open source and anyone who wants to can edit and rebuild the installers
- The NSIS community is huge.
- You don’t need to be a developer to learn to use NSIS (I gave it to two non-developers and they had solutions in little time (less than two days of work).
- I couldn’t quickly find a way to automate the installer with a progress bar, only completely silent.
Ok. So I’ll be honest. I am not on the MSI bandwagon. What features does an MSI really give me. I find that most people say the prefer an MSI when when pinned down, they are using basic features that NSIS provides ten times easier and when they need a more complex feature, they are writing a custom action and adding it to the MSI which is not any better than adding a custom action to an NSIS installer.
I hear arguments about it being easier to push and MSI with Active Directory, but if you can’t push a .exe with a /S parameter just as easily with Active Directory, you are probably not a very versatile AD administrator. Not to mention AD is not a very good software distribution tool to begin with. Most Desktop Management tools, such as LANDesk, are much better for the job. Besides, LANDesk and the competitors all push EXEs just fine and just as easily as they push MSIs, so the whole MSI vs. EXE is just not really a big deal like some may have you believe.
The one big deal is that MSI is a standard and so every MSI will have some default features. These are quite good:
- Mostly the same command line parameters for all MSI files everywhere (though you can add more and man properties can be changed with command line too)
- The ability to change a property in the command line.
- The ability to change a lot of properties in a transform file and call the MSI with the transform file.
But are those features really an improvement on NSIS. For example, NSIS uses the /S switch to silence and install, which is just as easy as use the /q switch for an MSI and actually a lot of installers use /S so it is very common.
Is it really easier to create a property in an MSI than to just add a supported command line parameter in an NSIS installer. Maybe not. However, if a public property exists, a user can change it even it the developers didn’t really know a customer would want to do that. With NSIS, there is no such ability.
- Documentation is scarce and when it is there is scattered.
- Most large installers cannot be completed with an MSI and end up wrapped up in a .EXE anyway and then it is harder to pass parameters to the MSI because you have to use the /v switch and quoting becomes and issue.
- Development is difficult and has a high learning curve (yet again, the scattered and scarce documentation compounds this problem)
- You pretty much have to be a developer to make MSIs and this doesn’t change just because you use WiX (I couldn’t hand WiX to someone and expect a working installer in as little as two days as I did with NSIS)
Building an Installer
Ok, so lets choose some key general features and decide a winner.
Ease of use
I have to say that the well documented and large community base NSIS has, added to the fact that you don’t have to be a developer to use it, makes it a clear winner of the ease of use category.
To be determined…
To be determined…
To be determined…
Using the Installer
Lets pick out some key features for an end user. Which installer is better for them?
End User Ease of use
To be determined…
Speed of Installer
To be determined…
Lets talk about enterprise features and pick a winner for those features too.
There are two key features that an Enterprise needs an installer to support:
- Automated installation
- Silent installations
No, these are not the same. Technically a silent installation is an Automated installation, but an Automated installation is not necessarily silent. There may be times when you want to show a progress bar.
Automating the Installation
Both NSIS and WiX can create installers that can be automated. Both support automation by default. With both, care must be taken with custom actions to make them also automated.
There are times when an install should be automated but show a progress bar and/or a success or failure when finished. This is common with install on demand or install on first use functions such as LANDesk’s Launch Pad and similar solutions. The idea is that the icon or shortcut is there, but the software isn’t installed until first use.
MSI files and there for WiX have the following supported functions for automating and Silencing an MSI.
Display Options /quiet Quiet mode, no user interaction /passive Unattended mode - progress bar only /q[n|b|r|f] Sets user interface level n - No UI b - Basic UI r - Reduced UI f - Full UI (default) /help Help information
So I had a hard time finding whether NSIS could do this level of different UI states. Basically, I found the silent switch, but not a switch for an automated install with progress showing.
Silencing the Installation
Both NSIS and WiX can create installers that can be silent. Both support Silent installs by default. However, with both, care must be taken with custom actions to make them also silent.
Silencing the install is very common. When a corporation pushes out software, the last thing they want to do is have the user see it and create a call storm to the help desk just to ask what is going on, and then of course ever subsequent computer problem is related to the newly deployed software in the end user’s mind (even when there is no possible way the new software could have caused them to be missing some emails 🙂
Overall Winner: Tie