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.

InstallAware Questionable Announcement

I just received the following email from InstallAware:

----- Original Message ----

From: Erika Lehman <elehman@installaware.com>
To: chrpai@yahoo.com
Sent: Sun, November 14, 2010 3:11:46 PM
Subject: InstallAware 10 First Ship Special - The Only Hybrid Installer

Together with the release of InstallAware 10, we're celebrating Visual Studio Magazine's Reader's Choice Award for InstallAware in the "Installation, Setup, & Deployment Tools" category! Thank you very much for helping make us the number one installer.

...  rest of message snipped ...

Kind regards,
Erika Lehman
Marketing Communications Manager
InstallAware Marketing Corporation
1888 Kalakaua Avenue, Suite C312
Honolulu, HI 96815
808 447 5817

What I find interesting is that they are claiming that they won the "Reader's Choice Award" and that they are the number one installer.

Really? InstallShield is claiming the same thing in a recent press release:

Flexera Software's InstallShield Wins Visual Studio Readers Choice 2010 Award
For Sixth Year in a Row, Gold Standard Installation Development Solution Takes Top Honors in Installation, Setup and Deployment Tools Category

SCHAUMBURG, IL--(Marketwire - November 11, 2010) - Flexera Software, the leading provider of strategic solutions for Application Usage Management for application producers and their customers, today announced that the readers of Visual Studio Magazine have once again selected Flexera Software's InstallShield®, the leading installation authoring solution for the Microsoft® Windows® platform, as the winner of the Visual Studio Readers Choice 2010 Award in the Installation, Setup and Deployment Tools category. This is the sixth year in a row that InstallShield has won this prestigious award, reflecting Flexera Software's ability to sustain the highest levels of functionality, ease of use, and customer satisfaction with the software.

... rest of message snipped ...

So I decided to go to the source to try to understand how two companies could possibly be claiming to win the same award.  Since I don't feel like stepping in the brown stuff today and have someone claim that I am misrepresenting the facts,  I'll just show you what I found and let you draw your own conclusions.

Let's just say that somebody is either not telling the truth or needs to get better at applying the creative use of weasel words. Of course the cynic in me notes that pretty much all of the award categories have 2 "merit award" winners and is aware there are only a few players in this sector in the first place. ( I've also read that VS Mag doesn't include MSFT tools because they want to encourage third party tools development so that explains why WiX won't be on the list. )

InstallShield Setup Prereqs Gotcha (BugBug)

I've recently discovered a weird InstallShield 2010 setup.exe behavior while doing some extensive testing for a client's installer.  Basically on a Windows 7 (x64) machine that I knew should need several redists, only one of the redists would show as needing to be installed.  When I ran the setup.exe again all three would show up as needing to be installed.

I did some googling and found out that setup.exe has a /debuglog option that allows you to diagnosis setup.exe problems.  I decided to do this and compare the bad then good logs.  Doing so revealed the following:

Skipping prerequisite 'Microsoft Visual C++ 2010 Redistributable Package (x86).prq' because it was installed before the reboot


Funny, I've never installed this prereq.   I did some googling and found a thread over on InstallShield Community where another user was seeing a similar behavior.

Now the machine I was testing on was a VM snapshot.  And it was only this one snapshot that I could reproduce the problem on.  I started thinking about how this could be and I think I've figured out the scenario that surfaces this design defect.    I had created a build for my customer that had several prereqs and used that to create the snapshot.  My customer then added additional dependencies to the application so I created a new build that added a couple more prereqs and I scheduled them to be run before some of the prexisting prereqs.  In doing so I think I stumbled into a situation where InstallShield keeps some information around and incorrectly figures it's installed something before that it hasn't.

So just be aware, if your doing setup prereq work and using snapshots for performance / productivity purposes while testing edge cases  with setup prereqs that you might come across this problem.   To  be extra safe, always author AppSearch / LaunchConditions to make sure the problem isn't swallowed and resurfaced when you try to run the application.

If anyone would like to help me confirm this bug, please consider trying to do the following:


1) Build setup.exe v1 with prereq A

2) Build setup.exe v2 with prereq A and prereq B.  Sequence prereq B to run before A.

3) Create a VM and create snapshot 1.

4) Run setup.exe v1 on the VM against snapshot 1 to install prereq A.

5) Create snapshot 2

6) Run setup.exe v2 on the vm . You'll see prereq b ommitted from the list and /debuglog shows it's being skipped

7) Run setup.exe v2 again on the vm. You'll see prereq b in the list and skipping emitted from the log.

8) Apply snapshot 1 and run setup.exe v2. You'll see prereq a and b in the list.

9) Apply v2 and repeat steps 6 and 7.  It should be very predictable.

InstallShield Media Table Gotcha (BugBug)

It should stand without saying that you should always test your installer using the various ways your customer will install it.   For example, if you are building a CDROM / DVD release don't just mount the network share and navigate to DISK1,  actually burn the folder to media ( or ISO's and mount them ) and use this to test your install.   Doing so would expose the following InstallShield bug that I found using InstallShield 2010.  Perhaps this is fixed in 2011 but I wouldn't know since I don't have it available to me at the moment.

1. Create a feature called A1.1 and give it some components / files.
2. Create a Product Configuration / Release of type CDROM, Compressed and tell it to create 1 CAB per feature.
3. Build and examine the Disk1 folder with windows explorer and ORCA.

What you'll find is a Media table with a DiskId 1 row that has a Cabinet name of A11~1.cab.  That is correct as the Media table only understands short names. ( Yes, I know... this is 2010 AD right? )

Take a look at the Disk1 folder and you'll see a CAB named A1.1.cab.  This is incorrect.

If you drop to a DOS prompt and CD to the Disk1 folder you can do a DIR /X (display short names ) and you'll see   A11~1.CAB for short and A1.1.cab for Long.    However if you burn DISK1 to a CDROM you'll see something different for a short name.  What you see will depend on what type of file system you use but generally it won't be what you expect.  A detailed explanation of all this would take a long time and frankly it doesn't matter to me.    The point is if the media table only understands short names then the cabinet files should match it as short names so you don't have to worry about all of this.

As an aside, another gotcha to watch out for is when you burn a release that has more then 1 disk.  Windows Installer cares about the VolumeLabel in the Media table matching the VolumeLabel on the media.  It doesn't matter that your disk has the right cabinet file name with the right hash,  MSI will keep prompting for the next disk unless this VolumeLabel matches up.   This probably goes back to the 1990's when a 'high speed' CD-ROM was capable of only 300KB/sec.  The problem of course is that in many organizations the group responsible for building installers isn't always the group responsible for media control.   So again, make sure you get a copy of what's actually going to go to the customer and test it before signing off on a release.

InstallTalk: Windows 7 Application Compatibility

It looks like after 7 years InstallShield is finally joining the blogosphere.  Maureen Polte kicks off a new blog series called "InstallTalk" with an article dealing with Windows 7 application compatibility. It's an interesting article that addresses "what a software installation developer can do to help".  

Here's a quick list of the pain areas she lists:

1. Legacy Help Files
2. Windows Resource File and Registry Issues
3. UAC File Header Issues
4. Custom Action Security Issues
5. Legacy Control Panel Applet Security Issues

 What I find interesting is that 3 of the 5 issues aren't really installer problems, they are development problems.  Over the last 15 years I've served in a variety of roles including Tier-4 Enterprise Engineering, Application Development, Build Engineering and Installation Engineering.   I've seen the industry from a variety of angles with a number of companies and in general I'd say that Maureen is correct in pointing out that operations folks often encounter pain caused by ISV's.   But I don't point the finger at install developers.  The problem comes when development organizations do a poor job of understanding the platform they are developing for and fail to take integration concerns into account from the moment they create their designs.  Of course the highly complex nature of the Windows platform and related technology stacks doesn't help any of this.

One of these days this message will get back to developers.  Until then I'll keep making the best possible installs and offering practical integration tips wherever I can.