He posts twice ( here and here ).... I'm trying to be gentle tonight but here a goes dissection:
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.
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).
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
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.
Christopher,
ReplyDeleteI guess I don't understand the us VS. them mentality that this post is trying to convey. I am a professional developer with 10+ years of experience as yourself.
To me it seems that you are hawking a particular installation technology. I have followed your blog for quite some time. Recently, I have felt that the blog discussion has coalesced around disapproval of WIX as a viable installation toolset and InstallShield as the one true toolset in the darkness to bind them all. This may/may not be the case.
However, the last few posts seem to indicate this conclusion.
Admittedly, VDPROJ are retarded. However, what is wrong with the Votive view of the world. I happen to agree with Rob when he says that the person responsible for the feature should also author the setup for the feature. I am one of those Enterprise developers that doesn't usually put a UI on my MSI. And you know what my Systems Administrators love that. It is one less thing that they have to feed/configure/understand/tame. They can configure it as needed but usually don't because we have collaborated on the details.
In addition, I truly enjoy the fact that from a development perspective my install code is now version controlled. Personally I have never used InstallShield, so I do not know if it is as easily version controlled as WIX projects. I have used the Wise product in the past and found it to be an abomination. Likewise the VDPROJ as stated earlier is retarded. Click-Once is an abomination!
I have spent a significant amount of time supporting users and installations. Our corporate policy used to be quite lax. Last year I convinced the corporate establishment that we needed tighter controls over the install base. The only way to accomplish this from a corporate perspective was to promote MSI as the install vehicle. The only way to get corporate IT to buy-in in to this concept was to use a no-cost solution. WIX fit the bill. If I had had to sell an additional licensing cost per build/deployment to the administration staff and my higher ups I would have been crucified.
I am sure that InstallShield has some advanced features that WIX does not offer. However, I am willing to stake my claim on it for the time being until the bigger players become more competitive with the free nature of wIX and its good enough nature4/25/2008 12:25:06 AM.
I have probably made myself open to be crucified after these statements. Here are my hands.
Thanks,
Kirk
Kirk,
ReplyDeleteWiX has its value; however, I think it depends on what you're looking for.
IS provides a laundry list of features that WiX cannot and with IS 2009, it only proves to be longer.
I think anyone can be a talented, quick developer with WiX; however, when you know what you're doing I personally believe (unsubstantiated) that InstallShield can do what you can with WiX faster.
WiX is good for what it's good at doing, but I wouldn't go so far as to say InstallShield is competing with it. They are two different market places.
Plus it wouldn't make sense to rebuff on someone ragging on InstallShield specifically using WiX unless you were doing an advertisement for WiX.
Shadow-
ReplyDeleteYou are right, this wasn't really a post about WiX... I only mentioned it in passing to say that InstallShield better get it's house in order or more developers will turn to whatever is in the next version of Visual Studio, which just happens to be WiX based because WiX has a much better image these days with many developers.
Kirk-
Read more of my posts to see that I actually like a lot of things I like about both WiX and InstallShield. The problem is the `good enough` attitude where the tools are praised and the customers stories are ignored. Sadly this attitude comes from both camps to a degree. I personally think it's much more prevelant from the WiX camp ( which has a reputation of ignoring customer stories and dismissing bugs as `hey, it's only my part time job`. but many think InstallShield takes the cake for bugs not fixed release after release. but much more so from the WiX camp. Anyways, if you were to hang with me for a few hours as I compare / contrast the tools, I believe you would begin to see my point of view.
I believe we do need to see a blend of the two philosphies coming together to become the one product to `consume` ( code sense, not world domination ) them all. I'm hoping Rosario will be much closer to this but I doubt it will be 100% there.
In a perfect world, I would also like think that developers should contribute to setup development. But note that you said you were a developer, not a setup developer with 10 years of experience. While I'm sure you are professional, that very distinction is what I was talking about in my blog. The vast majority of developers a) know very little about deployment b) unknowingly accept antipatterns as `good enough` and c) don't really want to touch deployment with a ten foot pole.