It's been no secret that I've favored InstallShield over WiX for many years. I've used InstallShield products since 1997 and I've shipped hundreds of installers using this versatile tool. InstallScript, XML Locator, Setup Prerequisites, Multiple Instance Support, COM Extraction, MySQL, Dialog/Control editors, Product/Release configurations and Component authoring wizards/views have made me a very productive and profitable person over the years.
Unfortunatly, there are also things I dislike about InstallShield. The DRM activation ( and now reactivation with IS2010 ) is horrible, difficulty in trying to get updates in an offline scenario (which we always are for security purposes), the random crashes, the horrible DTD/XML transformation, sequenced primary keys and of course, the removal of the stand alone build from Professional and totally useless collaboration tool combined with the really high price of the product.
If I'm hurting anyones feelings, I'm sorry. It's hard for me too since I've used this tool for so long and I do believe it's still a very good tool for many development shops. Just not for mine.
At my day job, I lead a team of 4 ( going on 6! ) setup developers. We collectively maintain dozens of installs that generate and consume hundreds of merge modules from a software product line. Our typical installer ships 10,000 - 15,000 files and includes countless databases, services, webservices and many chained packages of programs that we integrate with. All of this occurs on many active branches.
Unfortunatly InstallShield with it's DTD XML and incremented primary keys just doesn't work well in this environment. Merging branches back together in clearcase is a nightmare since you always end up with unresolved conflicts. Enter WiX. The XSD XML is 95% smaller then DTD XML and is way more expressive. Also thanks to deterministically unique primary keys and guids, changes done on multiple branches can actually merge back together easily.
The problem with WiX of course is the lack of gui designer abstractions and visualizations. Fortunatly I finally have a solution for that. I've recently had an internal tools developer assigned to me to come up with our own collaboration tools to sit on top of votive. Once complete we are hoping to once again try decentralized setup development. I'm not sure it'll work ( it didn't last time ) but we are going to give it a try again. The reality is our environment is growing so fast that we need to retool and try new strategies to keep up. Hiring more and more people just doesn't seem to work anymore.
Chris
ReplyDeleteIt would be nice if you could document what happens even if it fails again, it may just help someone doing the same thing. Joe
Sounds like you have an interesting time ahead of you - keep us informed of how your 'internal tools developer' progresses!
ReplyDeleteI've thought the same thing about the DIM collaboration in InstallShield... useless.
ReplyDeleteAlso, the activation has been becoming more of an issue for us as time goes one and we utilize virtual machines which get renamed at the end of a dev. cycle.
Good luck on your project to create a GUI for WiX... if you can pull if off, you may have a viable, preferrable alternative to InstallShield before you know it!
I would be very interested in what he comes up with.
ReplyDeleteI saw Stefan's side-by-side InstallShield license comparison of IS 2009 and IS 2010 licenses (see http://www.installsite.biz/en/desc/ix/eula0910.htm) and am concerned about the activation stuff as well.
ReplyDeleteWe use IS 2009 Premier for development (2 licenses) and the Standalone Build on numerous build machines (VMWare VMs all configured the exact same way).
If Acresso is going to discontinue the Standalone Build and require a separate license for each build machine then you better believe we'll be switching to WiX pretty darn soon!
Colby - InstallShield doesn't discontinue the stand alone build engine. Does my comparison give that impression? Please let me know because then I may need to fix or clarify it.
ReplyDeleteChris,
ReplyDeleteWe have had the same thoughts about InstallShield for the past two years. However, each year the thing that keeps us going is that we lack the manpower and funding to push us into something new.
This past year we reconfigured the DIM processing system for our own use. We now use system to populate the ISM by running a macro. This allows us to take care of many of the problems that InstallShield had with their implementation of the DIM processing system at build time.
One day the proverbial final straw will break the camel's back and we will move to another tool - probably WIX too.
Activation ( and reactivation ) are pretty par for the course in the business tool world from what I've seen. I don't know that anyone really "likes" it, but it definitely serves a legitimate purpose.
ReplyDeleteShadowWolf, I disagree. It punishes the honest user. The activation routines are hacked the day the software is released and so the dishonest users aren't concerned with it anyway.
ReplyDeleteIt's only the valid users of the software that have to deal with it and how to figure out how to activate software in a secure environment.
Hi Chris,
ReplyDeleteLooking at your previous post (Ref:http://blog.deploymentengineering.com/2007/09/versioning-msi-packages-wix-vs.html)realised that it almost took couple of years for you to switch to Wix (or are you still using Installshield).
Would be intrested in knowing why
It's actually taken me about 5 years to warm up to WiX and while I haven't completely switched over, I am now at a point where I am slowely moving my entire code base (at work) over to it. My reasons involve DRM, cost and a project format that is lousy for branching and merging. When I look at my companies needs, these three things are critical to be solved and we've decided to do so.
ReplyDeleteBut for a great many people, I still think InstallShield is a fine product as most people will probably not be troubled by these issues as much as we are.
I've yet to see a single large application installed by InstallShield that can be removed after six-twelve months. No way, the only answer I get from InstallShield every time is that its own database has been corrupted, vanished, beaten, gone to the dogs in the meantime. It's either tedious manual labor then or, if I'm lucky, reinstall and immediate uninstall. I long ceased to consider InstallShield a setup authoring tool of any real value.
ReplyDeleteI'm a newbie to WIX and was just reading some info about it here.
ReplyDeleteI've created several installers using Installshield and have almost all my CA's written using installscript.
It is probably not possible to convert an msi installer that uses installscript CA's to WIX...?
Do I need to convert every CA to a dll custom action then...?
Technically you can edit your built installshield msi and extract the DLL from the binary table. Then take a look at the CustomAction table and you'll see your CA's call into the DLL using a series of function entrypoints named f1, f2, f3.
ReplyDeleteThat's enough information to call those custom actions using WiX but if you ever want to make code changes you'll have to rebuild the InstallShield project and reextract the DLL.
So for all practical purposes, you'll have to refactor those InstallScript Custom Actions. C++ if you don't have a dependency on the .NET framework and C#/DTF ( way easier ) if you do have a dependency on the .NET framework.