I was browsing the blogosphere tonight when I came across this frustrating blog post from a frustrated blogger who fits a growing stereotype: a hubris software developer who is clueless about Setup Development and loves to blame his own shortcomings on InstallShield.
It’s a .NET 2.0 Winform project, which for some god-awful reason uses InstallShield instead of the free installer that comes with Visual Studio
I guess just because VDPROJ is part of Visual Studio ( which, btw, is not free ) is must be good, right? I mean, it’s obviously the better choice then InstallShield and anyone who would think otherwise must be an idiot! ( Do I need to enumerate it’s weaknesses here? )
So in order to add any kind of logging or streamlining to this abomination of an application, I have to learn this language.
Hmm, he never says what project type he’s using but I’m guessing it’s not Windows Installer. If he was, InstallShield has a project setting to turn logging on automatically and if that’s not enough information, a call to MsiProcessMessage() here and there would certainly add any additional information you could need without requiring a whole lot of coding.
Why don’t I like it? Well, first there’s the obvious: Nobody should have to learn a whole extra language just for their installer; it costs money when we already have a free product that works better
Oh I see, Setup Development isn’t Development! You shouldn’t have to actually learn anything, it just be super easy. OK fine…he’s got a little bit of a clue here, that sure would be great… but it’s still SETUP DEVELOPMENT. Oh but VDPROJ works better (not).
Then there’s the less obvious stuff: No Framework accessibility, needing to deal with handles and memory pointers (Unsafe code; oh noes!), and no try/catch/finally block equivalent. This thing is just a big ol‘ turd.
I’m sorry, is this guy using the same tool that I’m using? InstallShield has THE BEST .NET framework accessibility model out there. For a couple years now you can instantiate .NET classes using CoCreateObjectDotNet() and DotNetCoCreateObject() and in InstallShield 2009 you’ve got the ability to declarative invoke .NET code including passing the handle and using Interop to communicate back with the Installer. This kicks the ass out of the crappy InstallUtil pattern that the .NET Framework and VDPROJ dumped on the world. Also InstallScript has had exception handling since about 1999 or so when IS 6.0 came out. (PS: Maybe he should come vote Yes for my Managed Code Custom Action Poll )
Project Newgood, which will replace Project Convergence, will use the installer built into Visual Studio. When coding a VB.NET application, does it not make sense to code your installer in VB.NET as well?
Code your Install in VB.NET? Oh my, it sounds like he’s going to be using InstallUtil and VDPROJ. May the force be with him….
So by now your either laughing, nodding your head up or down or already surfed to your next web page. If you’ve hung in this long I promise I’m almost done…. just a few more thoughts:
1) Part of this problem is Microsoft/InstallShields fault. So little has been done to foster the professionalism and education in this space. Search for help from your local development ecosystem and you’ll likely hardly find anything. No code camps, no user groups, few few few MVP’s ( seriously, every software shop in the world ships product but there are around a dozen MVP’s worldwide! ) You’ll find precious few books on the shelves of your local bookstore; the ones that exist are ancient and/or completely get it wrong. I want to say college courses barely touch this area but I’ll leave that to Colby to comment on since he’s got a better perspective. There is also no certification tracks.
For the last 12 years I’ve been writing Installs I’ve seen over and over that you get very little respect. Every time I change jobs I have to once again destroy misconceptions and ignorance and show the mighty developers ( who typically want write anti patterns into the requirements if there is a requirements document ) how to do things correctly. Almost always there has never been a dedicated installation professional following industry best practices. It’s always some junior CM analyst or developer who gets stuck writing the installs and is now happy to dump it like a hot potato.
2) Another part of the problem is InstallShield has a really positive yet really negative image problem. On one hand they are THE brand name trusted product and yet they are also a huge target of developers who get frustrated and then blame InstallShield instead of blaming themselves. They then flood the blogosphere with `InstallShield Sucks`. This is read by other equally clueless developers and a vicious feedback cycle is formed.
This probably wasn’t a problem 10 years ago, but in today’s ever connected world, the damage will penetrate more and more regardless of whether the complaints are based on reality. InstallShield can’t risk keeping quite like they have in the past. Real efforts need to occur to educate and foster loyalty from the development community or otherwise I see a really bad future. Especially once Visual Studio comes out with a decent WiX authoring tool.