The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Application Installer NSIS vs WiX

I'm currently looking at integrating an installer into our development process. We primarily use MS based technologies.

The two tools I have narrowed down to are: WiX and NSIS
Does anyone have any strong reasons to use one over the other?

There seem to be pro's and con's to each; but I would like to hear some thoughts from folks who have tried both.

I'm not really interested in looking at some of the other offerings right now; but that may change.


Thanks
BigJimSlade Send private email
Friday, April 18, 2008
 
 
NSIS had a really nice community the last time I used it and I think this is one of the most important things in open-source projects. I've never used WiX so I can't comment on it.

The only downside I can comment on is that the simplicity of the scripting language made certain operations more difficult to code than they would be in richer languages. For example detecting the version of the user's JRE was a pain but there are plenty of user-contributed modules in the official wiki so you could always grab one of those ;)
Gili Send private email
Friday, April 18, 2008
 
 
Choose WiX.

It's open-sourced and produces installers in MSI format which is Microsoft's deployment standard on Windows machines. Many other commercial install packagers are also based on MSI and some even use WiX in their back-end because it's really easy to use and you have things under control.

NSIS lives isolated in its own world and is a bit out of date. The reason is that they need to work much harder than WiX to implement new features because WiX is just a simple tool to generate MSI files and Microsoft Installer is implemented and maintained by Microsoft while NSIS maintains full-stack on its own.
lubos
Friday, April 18, 2008
 
 
What lubos said .

+ some of the WIX core team are also developers in the Microsoft Windows Installer team. - From what I have heard WIX is used internally by Microsoft for it's own products.

If you use NSIS you'll end up with system admins griping because they need to repackage your sw so that they can install it on their networks.
Jon
Friday, April 18, 2008
 
 
I would be inclined to look first at WIX. This is more by a process of eliminiation, I must admit, because I thought NSIS's non-declarative approach unsound and the stack-based scripting language truly awful.

(People use it, though, so don't just take my word for it.)

This isn't to say that WIX isn't good, just that my use of it involved making installers for Maya and 3D Studio MAX plugins. It worked, but it wasn't as easy as I was hoping! I very much got the impression that this simply because this isn't really what it was designed for, though. Whilst I don't have any proof that it would be much more straightforward for creating installers for a standalone application, it certainly looked like it would be.

(If you do look at others, one to avoid is probably InstallShield. I have never heard anybody say a single good thing about this program. We used it on a couple of recent projects, and the people who had to make the installers absolutely despised it.)
Tom_
Friday, April 18, 2008
 
 
I haven't used NSIS, but I have used WiX.

The documentation is mostly missing, but there's a great tutorial site hosted by a guy in Hungary (any book authors out there -- this is a great opportunity for you!)

Note that if you want to do any custom install actions, you'll probably need to drop into C++.  Luckily, the API for this appears to be pretty well thought out -- you link with msi.lib to do things like access variables from your script.

While you can hand-design custom UI panels for your installer, you might want to think about dropping a few hundred dollars on one of the visual designers that are for sale out there.  Huge time saver.
xampl Send private email
Friday, April 18, 2008
 
 
I concur on the thoughts regarding InstallShield.  We use it on a few older products, and the developers have fine-tuned their abilities to say "Not me - I'll be on vacation that day/week/month" when asked to use it.

Another strike against it is that it's SCM unfriendly.
xampl Send private email
Friday, April 18, 2008
 
 
Use MSI if you are aiming at corportate market - no question.
It is complicated to do anything more than the very basics.
The documentation for MSI is non-existant.
I had an issue with things like refusing to uninstall or upgrade if the original package wa sno longer in the same place (could be my fault - see lack of docs)

In the end for simple app deployment I switched to innosetup.
Martin Send private email
Friday, April 18, 2008
 
 
The thing to remember about WiX is that it's a fairly thin layer over MSI. As a result, to do anything slightly complicated you need to understand the underlying MSI technology.

WiX is orders of magnitude easier than building MSIs yourself, but that really isn't saying much. ;-)

It's still better than InstallShield.
Chris Tavares Send private email
Friday, April 18, 2008
 
 
When people complain about how difficult it is writing installers, yes the SDKs and tools have their weak spots, but mostly people tend to underestimate the development scope involved.  You have to be a real jack of all trades, skilled in both administration and development and highly specialized in the gotchas of MSI and the selected authoring tool.  I've been writing installs full time for 12 years now and I still have to learn new tricks as the platform changes and becomes more complicated.

Also beware of when someone bashes InstallShield without first demonstrating a strong understanding of the Setup space.  For example, in this thread I read a comment saying InstallShield didn't have good SCM support.  I'd really love to know why they think that because InstallShield saves it's project file in a text based XML file, has an automation API, has a silent command line builder,  supports MSBuild / TFS TeamBuild and has IDE integration for Eclipse and Visual Studio.  The same is mostly true for WiX except that it's VSIP is basically a text editor to show you the XML rather then any meaningful graphical designers to author said XML.

If anyone reading this thread has serious questions and wants serious answers from someone who is specialized in this space, feel free to visit my blog and contact me.
Christopher Painter Send private email
Sunday, April 20, 2008
 
 
>> I'd really love to know why they think that because InstallShield saves it's project file in a text based XML file, has an automation API, has a silent command line builder,  supports MSBuild / TFS TeamBuild and has IDE integration for Eclipse and Visual Studio. <<

That was I.  What I learned over 18 months using it was:

The project file wasn't just one XML file, but a set of related files.  You had to check them out in order to compile your project (they had to be writeable for it to build in their IDE) but when you were done, you did an undo-checkout on them.  They had to be in your SCM tool, even if the changes never got saved...

We didn't use the automation API, as we ran it from a build script.

The command-line builder worked OK.  A little cryptic, and not 100% reliable, but worked most of the time.

We are a Clearcase & NAnt shop, so support for TFS and MSBuild wasn't important to us.

Because of licensing issues (the thing is EXPENSIVE!) we were only able to afford a few copies -- one each for the designated deployment developers, and one for the build machine.  So we weren't able to use it's full VS.NET IDE integration abilities.  Also because of it's Macrovision licensing code, I never liked installing it on the build machine, because I was never certain what else that stuff was doing.  I think I would have been happier with a hardware dongle.  From my standpoint, the licensing code was a waste of their time -- like a Yugo, no one is going to want to steal this turkey.

And lastly, whenever we had problems, InstallShield tech support's answer was always to upgrade to the latest version, which oddly seemed to always be a major release upgrade (which increased our learning curve & delayed our product release).  Thank goodness we were paying a few thousand a year in maintenance!
xampl Send private email
Monday, April 21, 2008
 
 
+1 for NSIS.

I've tried MSI/WiX but I got fed up with it. I was spending too much time figuring out what the heck the msi was apparently doing, or why it wouldn't build etc, rather than getting the installation procedure right.

I had several other gripes about MSI/WiX: At the time I looked at WiX you needed to list every file in your installer package in some xml file. There were scripts to help you autogenerate those files from your source tree, which you could tweak (if I remember correctly) to exclude source files that you didn't want to include. Documentation was lacking. I found it a total mess.

Neither do I appreciate the declarative approach of MSI's. As I understood, an MSI consists of a set of tables that collectively describe the state that the installation machine should be set to. In a sense the windows installer is a state changing machine that modifies the installation machine to the state described in the MSI. Assumedly this allows for all sorts of clever repair mechanisms because you can determine the difference between the current state of the system and the desired state.
It's all nice and dandy but it requires you to actually understand how the MSI is processed by Windows Installer if you're going to do anything complicated.
Before you know it building a simple installer expands into a 3-months study into the internals of MSI. Not very value adding that is.

Now come NSIS. Its syntax is horrid but consistent. The use of the stack to pass command parameters is fickle but doable. Documentation is excellent and easily accessible. There is a free IDE. The website contains extensive samples and forums with information. Best of all, an NSIS installation script consists of a procedural description of the installation proces (do this, now do that, then do this, if that failed, do this, etc). You can actually envision, in your mind, what the installer is doing. An installer written in NSIS is easily understandable and  doesn't require 3 months study to learn some convoluted table based thingy.

In short, with NSIS you can get a smart installer up and running within a week and move on to doing something actually worthwhile.
Mathieu Send private email
Tuesday, April 22, 2008
 
 
>>The project file wasn't just one XML file, but a set of related files.  You had to check them out in order to compile your project (they had to be writeable for it to build in their IDE) but when you were done, you did an undo-checkout on them.  They had to be in your SCM tool, even if the changes never got saved...<<

What version and project type were you using?  ( What you describe sounds like old InstallShield 5-8. ) With a recent version of InstallShield, everything should have been in a single .ISM file with the exception of .rul (similar to .cpp) and .h files for InstallScript custom actions. Unless you were checking in compiled outputs, you shouldn't be in a situation of having to make files writable unless you want your build automation to do some kind of tweaking of the source as a prebuild step.

>>The command-line builder worked OK.  A little cryptic, and not 100% reliable, but worked most of the time.<<

Provided the build environment is correct, I've not seen any major issues here.  Trying to consume mere modules with very large filenames can be a problem because windows only supports paths up to a certain link.  I had a build step that called WMI to get the next free drive letter and then do a subst.  That solved all of my problems there.


>>We are a Clearcase & NAnt shop, so support for TFS and MSBuild wasn't important to us.<<
I've used BuildForge/Clearcase/NAnt with InstallShield in a multivob multisite product line development environment.  It integrated very clean.

>>Because of licensing issues (the thing is EXPENSIVE!) we were only able to afford a few copies -- one each for the designated deployment developers, and one for the build machine.<<

I'll agree InstallShield isn't cheap, but you shouldn't need to ( or want to ) install it on your build machine.  You install the Stand Alone Build Engine instead. 

>>From my standpoint, the licensing code was a waste of their time -- like a Yugo, no one is going to want to steal this turkey.<<

I agree that DRM sucks, but resulting to personal attacks isn't why.

>>And lastly, whenever we had problems, InstallShield tech support's answer was always to upgrade to the latest version, which oddly seemed to always be a major release upgrade (which increased our learning curve & delayed our product release).  Thank goodness we were paying a few thousand a year in maintenance!<<

And that maintenance policy included software assurance upgrades.  Also other then the change from InstallShield 11.5 to InstallShield 12 ( which had a much needed InstallScript refactoring ),  I haven't found the changes from one release to another to be that disruptive.  Just new features that allow you to go back and refactor old projects *if* you want to take advantage of the newer/cleaner/builtin way of doing things.
Christopher Painter Send private email
Tuesday, April 22, 2008
 
 
>>I've tried MSI/WiX but I got fed up with it. I was spending too much time figuring out what the heck the msi was apparently doing, or why it wouldn't build etc, rather than getting the installation procedure right.<<

Fair enough, the learning curve is steep, but it is development.

>>I had several other gripes about MSI/WiX: At the time I looked at WiX you needed to list every file in your installer package in some xml file. There were scripts to help you autogenerate those files from your source tree, which you could tweak (if I remember correctly) to exclude source files that you didn't want to include. Documentation was lacking. I found it a total mess.<<

Tools like InstallShield and WiXAware have visual designers (wizards) for mass authoring of this data.  It's a lot easier then trying to use a tool like tallow, heat or other homegrowned code to do it by hand.

>>Neither do I appreciate the declarative approach of MSI's. As I understood, an MSI consists of a set of tables that collectively describe the state that the installation machine should be set to. In a sense the windows installer is a state changing machine that modifies the installation machine to the state described in the MSI. Assumedly this allows for all sorts of clever repair mechanisms because you can determine the difference between the current state of the system and the desired state. It's all nice and dandy but it requires you to actually understand how the MSI is processed by Windows Installer if you're going to do anything complicated.  Before you know it building a simple installer expands into a 3-months study into the internals of MSI. Not very value adding that is.<<

I hear your pain, but the value added is for your customer who will have a better experience.  MSI wasn't created with ISV Setup Developers in mind.  It was created because we had written so many horrible script based installers in years gone by that Enterprise customers were screaming in integration pain.  It is hard work to learn, especially for occasional one-off installer work.    I do installs full time year after year so the initial investment was worth it to me.

>>Now come NSIS. Its syntax is horrid but consistent. The use of the stack to pass command parameters is fickle but doable. Documentation is excellent and easily accessible. There is a free IDE. The website contains extensive samples and forums with information. Best of all, an NSIS installation script consists of a procedural description of the installation proces (do this, now do that, then do this, if that failed, do this, etc). You can actually envision, in your mind, what the installer is doing. An installer written in NSIS is easily understandable and  doesn't require 3 months study to learn some convoluted table based thingy.<<

Fair enough, if you want to stay with procedural instead of declarative, NSIS is probably a fine tool.  The problem is I've seen to many of them hit the enterprise with no meaningful support silent install/uninstall and transformation customization. If you target the home market, that's probably fine.  But if you target enterprise environments, don't be suprised if they throw your install away and just repackage it into MSI instead.
Christopher Painter Send private email
Tuesday, April 22, 2008
 
 
What about InnoSetup?
Are NSIS and WiX that much better?
moronica
Monday, April 28, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz