Look, No Hands! Really??

I was just reading an interesting blog post over at InstallShield titled Look, No Hands: InstallShield’s Automation Tools. It's an interesting read so go check it out and come on back.

Ok, now I'd like to share my experience with InstallShield automation.  This no doubt get's me in trouble since people don't like being called out but here goes anyways:


I've done extensive ( e.g. C# Linq to XML NAnt tasks that parse WiX fragments and build up InstallShield projects and working as part of a build team that does over 100,000 automated builds per year) work in this area and the main problems I find are:

1)  The Automation interface is based on COM and isn't very easy to use with C#.  It doesn't feel like the .NET base class libraries, it's clearly something from a decade ago. 

2) The way it's set up, there is no easy way ( short of reflection ) to write code that will work with multiple versions of the automation interface.  You can't just call into a factory and ask for the implementation for any given version of InstallShield.  They show examples in VBScript where you just change the ProgID but any build engineer writing automation in VBScript should be summarily fired.

3) If you spend any amount of time using the automation interface you'll find that it has feature gaps galore.  At this point you are stuck manipulating the XML directly or saving it in Binary format and using an MSI interop to directly update the tables.

4) Another annoyance is that Product Configurations and Release names are case sensitive and that if you pass in an invalid PC/Rel it won't throw an error, it'll just instantiate it for you and then build with incorrect results.

5) I've never been able to get the TFS SCC integration to work correctly.  I always get a C++ ChatterAbstractionLayer error ( or something like that. )  Also, as of the last time I tried, InstallShield doesn't handle more then a handful of ISM/ISPROJ's in a single solution.  In order to have dozens of merge modules build in a single solution I had to author the SLN file by hand and pass it off to msbuild.  Opening it in VS would fail with an error.    This isn't a huge deal to me as I've never really liked the new Visual Studio style UI over the old DevStudio style UI but I think it's worth noting.

Finally, I'd like to say if you read this far you should give yourself a pat on the back for caring about build automation.   My observations from over the years lead me to believe that far to many IS developers users follow very poor practices including the use of magical build machines / desktop builds.   I believe that this is supported by the decision some years ago to remove the SAB from IS Pro and I have hope that since one license of SAB was recently added back into Pro is evidence of a maturing of the user base in adopting formalized processes/automation for building their installer.