The Battle of the Installers

Okay, someone straighten me out on this issue.  Every installer I've had to build, I built within Visual Studio. Through some politics I've blogged about but don't need to go into here, I got stuck on an InstallShield project.  I hate it. Further, now I'm coming under attack for defending Microsoft's product against IS.

I know the VS installer does everything I need, but I feel I may need some more fuel if this issue escalates.  What's your favorite installer factory/package/system, and why?

SlackmasterK wrote:

Okay, someone straighten me out on this issue.  Every installer I've had to build, I built within Visual Studio. Through some politics I've blogged about but don't need to go into here, I got stuck on an InstallShield project.  I hate it. Further, now I'm coming under attack for defending Microsoft's product against IS.

I know the VS installer does everything I need, but I feel I may need some more fuel if this issue escalates.  What's your favorite installer factory/package/system, and why?

I'm now using WiX because is more customizable than normal windows installer projects. IS is easier but after having problems with buggy IS runtimes I stopped using it.

Can't you make a "pure" windows installer package with InstallShield?

Visual Studio deployment projects, well, suck.   That's not just my opinion, that's the general consensus:

http://blogs.msdn.com/robmen/archive/2006/09/18/761580.aspx

http://community.macrovision.com/archive/index.php?t-172111.html

VDPROJ problems are vast.   ( This is only a few of them )

1) .vdproj isn't an MSBUILD file and isn't XML.  It's ugly to shove and diff in source code ( it randomly sorts things when you make code changes making diff's impossible )  and it can't be built by a pure MSBUILD / TFS TeamBuild environment.  You have to <exec> out of process and call DevEnv which adds fragility to the build process.

2) .vdproj  generally exposes very little of the underlying MSI patterns.  For examples: 

3) There is hides components which results in every single file being a keyfile.  This often causes resilency problems and when an MSI package scales the performance goes to (I need to watch my language) because the costing process is being given so many more components to evaluate.

4) VDPROJ doesn't allow you to author service install/control entries.  This results in .NET developers resorting to ServiceInstaller class custom actions which is a complete antipattern to MSI best practices.  Instead of leveraging the well tested, built in declarative patterns, you go out of process to managed code ( with no ability to communicate with the MSI handle ) where you introduce fragility.   I've seen developers write Uninstall CA's that remove a service with no error handling, then delete the service manually with SC and be stuck in a rollback loop while trying to uninstall.    They blame the install but it's really their fault.

5) VDPROJ gives you very little control over authoring the UI experience and no ability to wire up business logic custom actions to the dialog control events. 

6) VDPROJ only supports deferred execution CA's because VDPROJ only supports custom action targets of files installed on the system.   There is no support of controlling the sequencing or conditioning of the CA's and it gets really messy fast when you merge merge modules containing custom actions.  There is no way to control the merge order.

7) Developers are forced to write Winforms Installer Class CA's implemented as deferred CA's to pretend that the UI experience is extensible.   This violates the ability to do silent installs as UI elements are now being presented from the execute sequence.

8) Merge module projects implement the directory table incorrectly.  This was a regression bug in VS2005 and it's not been fixed in VS2008 either.

9) You can't turn autodetection of dependencies off.   You can only disable a dependency after it's been detected.   If something is detected on the build box that wasnt on the developer box, expect your build to fail.

10) All shortcuts are advertised.  You can't turn it off.

11) There is no support for 90% of what MSI can do.   This leads to extensive build automation plumbing to use the MSI API to tweak ( postbuild ) the resultant MSI's into something somewhat usable.

12) VDPROJ fails to mark deferred CA's with the noImpersonate bit. VDPROJ also lacks to ability to digitally sign or manifest MSI's.   This means your installs containing deferred CA's will fail on Vista with UAC enabled.   

13) The COM extraction is badly broken which results in SelfReg antipatterns.

WiX is actually really cool.... if you like authoring installs by hand using XML.    Other then the utter lack of useful designers, it's a very solid technology.

InstallShield also rocks.  Stick with a Basic MSI project and avoid custom actions until you know how to do them properly and it's a very `Pure` MSI solution.

YearOfTheLinuxDesktop wrote:



I'm now using WiX because is more customizable than normal windows installer projects. IS is easier but after having problems with buggy IS runtimes I stopped using it.

Buggy IS runtimes are a thing of the past.  InstallScript CA's ( if you choose to use them ) now compile to clean Type 1 DLL CA's. See:

http://www.devinstall.com/content/view/118/302/

chrpai wrote:

Visual Studio deployment projects, well, suck.   That's not just my opinion, that's the general consensus[...]

Wow, my very own stalker.  First you linked to my blog post by Googling installshield sucks, now you've somehow found my thread asking for a general consensus. 

I have to wonder at this point if your hobbies include "fighting the good fight".  Nonetheless, thanks for contributing to the conversation and for leaving a comment this time.

chrpai (In a comment on my blog post) wrote:


BTW, I work on very large and complicated product lines

Then perhaps the problem is that Project Convergence, which this started in reference to, is not a "very large and complicated product". It's just an application with an optional MSDE SP4 installation. I have to wonder whether that actually requires such an investment.

Further,

chrpai (In a comment on your blog post) wrote:


MY blog where I post MY observations and opinions.

QFT - This started as a short series of posts on my blog where I posted my observations and opinions; it was you who chose to escalate this into a flame war.  Now that I'm off the InstallShield project, it's unlikely I will be posting any more on the topic.

Having gotten that rant off my chest, it's good to meet a forum lurker when they finally speak up.  I, for one, invite you to be a more active member of the community - With your C# experience, your distinctiveness will add greatly to our own.