CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Jeffrey Palermo (.com)

Blog moved to www.jeffreypalermo.com

Visual Studio setup projects (installer) experience report - level 200

Recently, my team needed to produce an installer for our software package.  We wanted a neat setup package that installed prerequisites as well (.Net 2.0, and SQL Express 2005).  We decided to try out the Visual Studio 2005 setup project.  Here's my experience report:

  • Creation of the project was easy, but added files to include wasn't so easy.  The setup project was default output of other projects as deployment artifacts.  This assumes a developer is building the GA release on a workstation.  My team uses a clean build server for all builds.
  • Adding custom steps was nontrivial.  There were no hook points where I could pass in a command line to run.  I ended up creating a C# class derived from "Installer" just to Process.Start() a shell command.  Once I had that, I ran the shell commands necessary to set up the software.
  • Creating a start menu shortcut was very difficult.  It appeared that it could create one for default project output, but again, I already had my GA release candidate.  I just needed to package it up for install.  I ended up creating another C# custom action to run Windows Script Object to create a .lnk shortcut file.
  • Prerequisite installs worked like a breeze.  The installer detected the need for .Net 2.0, and Sql express and installed both seamlessly without unnecessary questions to the user.  Very pleased with this.
  • The uninstall is good.  I have opposite steps for my custom actions, and the uninstall performs well.  Users get the standard experience of uninstalling from Control Panel.
  • I have the option of including file a raw, loose file or bundled into a single .msi file. I opted for loose files to keep the install package flexible.
  • PAIN POINT: I wasn't able to automate the creation of the setup package.  The .vdproj file is not an MSBuild project file, and it requires Visual Studio just to build that project.  This means that I have to create the installer from a developer's machine, not my build server.  This might be a deal-breaker for me, I haven't decided yet.  It's very important that everything be automated, and the only alternative is to install visual studio on the build machine (I'm not going to do that).

Overall, with a few caveats, the setup project is doing it's job, and we're shipping.  We'll use it for the time being, but I'll keep my eye on Nullsoft, Wise, and InstallShield.



Comments

Tomas Restrepo said:

You might also want to keep an eye out for Wix. I used it in one of my last projects, and while the learning curve is a bit steep, it's definitely worth it. It's of course fully scriptable and you do get access to most of what MSI offers in the first place. The only stuff I ran into a bit of trouble was running .net custom actions, though it's perfectly possible but documentation wasn't as clear on how to do it.

One issue I definitely have with the VS deployment projects is that they're very slow to build (incredibly so, in fact) and keeping them in source control is an exercise in frustration, as just opening the solution will cause changes in your deployment project file, making trying to track meaningful changes to it very annoying.

# February 13, 2007 9:34 AM

ben reichelt said:

I have to agree with Tomas about Wix. Its an xml file similar to nant, so you can add it as part of your CI build process. Along with building your code you also get an installer to nicely package the build, if need be. It also becomes part of your tests as well, because you can test the installer with each build.

The added benefit is that you don't have another VS project in your solution to bog down VS, instead you can just add the build file as a solution item, which is much easier to manage.

# February 13, 2007 10:15 AM

Nick Parker said:

Not to sound like a broken record, but WiX is definiately the way to go, you can even decompile your .msi using dark.exe to generate the WiX source files.  That will help get you going if you have an initial .msi setup.

# February 13, 2007 10:27 AM

Carlton said:

Why not InnoSetup?

# February 13, 2007 10:40 AM

Frans Bouma said:

Actually, we'll be moving from vs.net installer project to NSIS soon. The VS.NET installer project is a big pain. Especially when your installer is pretty big and has a lot of dlls which have dependencies for example, the installer takes AGES when you remove or add an element. Not at first, but after a couple of load/saves, it's hell.

Build is also INCREDIBLY slow, so we'll move away from it. NSIS is easy to understand, and extensible so we'll go with that.

You can also go with WiX. Though how to get started? ->

First create an installer project with the vs.net installer crappy, then DEcompile it with the decompile tool of WiX into a wix project. Viola :)

# February 13, 2007 10:48 AM

Anonymous said:

+1 for WiX, and I actually worked on the Visual Studio Installer project at Microsoft!

(Ok, it's not THAT bad a codebase - it's actually pretty good, but it _is_ an integral part of Visual Studio and thus for the purposes of a build server, it doesn't really fit.  It *does* have a COM API, however, so it can indeed be scripted/automated.)

# February 13, 2007 2:40 PM

paul.laudeman said:

WiX has worked out really well for our team in our automated build environment. I'd definitely recommend checking it out to see if will meet your needs.

# February 13, 2007 4:42 PM

Joey Beninghove said:

Yep, my fellow co-worker Paul, is right.  We've been able to nicely integrated Wix installers into our automated build environments (using CCNet for continuous as well as daily and weekly builds).  

Wix does however have a learning curve.  But you can get something simple up and running pretty quickly.  Also, SharpDevelop has some great support for creating Wix installers, including a forms designer!

# February 13, 2007 7:12 PM

Ardie said:

My company experimented with wix and we're slowly moving away from it. Its overly complex, requires many moving parts and lacks documentation. I'm actually testing NSIS right now and i'm very happy with it so far.

Its not perfect and there's some features i wish they included (such as built in rollbacks, easier custom functions) but it has a ton of other features that make it worth while. That and they have great documentation, an active community behind it and its straight forward scripting so the learning curve is not bad.

# February 13, 2007 7:56 PM

Joey Beninghove said:

There is quite a bit of WiX documentation here: http://www.tramontana.co.hu/wix/index.php

That, along with SharpDevelop, is what helped me get ramped up on WiX.  I was pretty easily able to write some templated WiX scripts (for Dev/Test/QA environments) which includes installers for windows clients and windows services.

Although now I'm using ClickOnce for all of our windows client deployments for its ease of updates.  I was able to completely automate the generation of the manifests and integrate those into our build process as well.

Also, I have my eye on the ClickThrough project for WiX, which will use RSS feeds to push out application updates, which I think is pretty ingenious.

http://wix.sourceforge.net/clickthrough.html

# February 13, 2007 9:39 PM

John Rayner said:

Another vote for WiX.  The version 3 file format is fully MSBuild-compatible, which is means it's easy to include in any automated build process.

# February 14, 2007 7:18 AM

Jacob said:

Another vote against WIX and in favor of NSIS. WIX sounded like a great idea at first, but we found that it's like a lot of things from Microsoft: easy to do the 80% that most people need, but you better pray you're not in the camp that needs the other 20% because extending it adds mind-numbing complexity to your WIX and build scripts. NSIS on the other hand takes a little more work to get started because it uses its own scripting language, but it really isn't that complicated, and it's easier to extend than WIX will ever be.

It took 2 developers and several months of full-time development to create (what should have been) some relatively simple custom UI pages and logic for our WIX installers. Bringing new team members up to speed on the whole WIX structure and build process for the installers was an enormous hassle. By contrast, 1 developer developed the same custom logic and UIs (plus some additional) in about 2-3 weeks, and the resulting installer scripts are so much simpler that it just makes you want to cry.

Chalk one up for creating a real scripting language instead of trying to beat XML into some kind of sick, pseudo-declarative scripting language. (XML should not be for human consumption!)

Some additional points:

* NSIS is a very mature installer platform that has been around for years.

* It’s used by countless projects, including some very big names, and has a massive community around it.

* The installer UI is easily customized (much more so than WIX), and there is even a UI designer plugin for Eclipse.

# March 20, 2007 1:44 PM

Nitin said:

I too have swtiched from VS setup to Wix, I am trying to package an excel addin.

VS is easily able to package all the requirements and invoke C# custom actions, but it is not flexible in terms of the UI it shows.

Wix is gr8, I have customized the UI as I need, however I has been pain in my a$$ trying to get my C# custom actions running - I used the same C# dll i used for VS setup and I am able to run the Install custom action but not the uninstall custom action.

It seems uninstall is invoked during installation itself. I am invoking uninstall Custom action after MsiUnpublishAssemblies.

I am trying to reverse enginner the VS setup MSI using dark.exe from wix.

Any help with my problem will be appreciated.

# March 22, 2007 4:49 AM

beep said:

Wow, most of the NSI people here have I think, missed the point.

WIX allows you to create an MSI that IS INSTALLABLE AND UPGRADEABLE BY GROUP POLICY.

I manage lots and lots of machines. I don't do manual installs

# April 23, 2007 10:56 PM

Christopher Painter said:

Jefffrey-

I was checking out your blog since I'll be seeing you at ADNUG Code Camp 2007 tommorrow.  My vote is 100% in the InstallShield camp and if we get a chance to talk about it, I can tell you why in great detail.

# May 4, 2007 10:48 PM

Rubberduck said:

to Beep: NSIS is capable of silent installation. Just as with WIX/installshield, you can go the extra mile with NSIS to create an installer that will support silent install by pull parameters off the command line, or reading them from a config file.

Products as varied as the ATI Display Driver, OpenOffice, Firefox, Google Picasa, VLC Media Player, Flash Player, Yahoo Toolbar, etc use NSIS. nsis.sourceforge.net/Users goes into more detail.

# September 6, 2007 7:47 PM

JDee said:

I like to have my installer project inside my solution in VS IDE. It's easier to manage my code in one place and keep it controlled with version control system.

I have used Setup Projects and have tried also Votive which is WiX toolset integration for Visual Studio. But I had some troubles with installing my apps on Vista with MSI installers. So I'm looking for good alternative now.

I'm currently participating in beta-testing program for Lexpa - http://www.lexpa.com. That is Visual Studio add-in for Inno Setup. Looks very promising.

Is there something similar for NSIS, other non-MSI installers?

# September 25, 2007 7:11 PM

About Jeffrey Palermo

Jeffrey Palermo is a software management consultant and the CTO of Headspring Systems in Austin, TX. Jeffrey specializes in Agile coaching and helps companies double the productivity of software teams. Jeffrey is an MCSD.Net , Microsoft MVP, Certified Scrummaster, Austin .Net User Group leader, AgileAustin board member, INETA speaker, INETA Membership Mentor, Christian, husband, father, motorcyclist, Eagle Scout, U.S. Army Veteran, and Texas A&M University graduate. Check out Devlicio.us!

This Blog

Syndication

News

Headspring Systems

View Jeffrey Palermo's profile on LinkedIn

See my new blog at .jeffreypalermo.com