Working with InstallShield Limited Edition

I’ve had some limited experience with InstallShield in prior initiatives and didn’t find it all that difficult to work with. I know many others have a different opinion. In our current project here at Quest, we were using the Windows Installer XML (WiX) toolset, but decided to move to InstallShield because all the other components are packaged with the software. Rather than take over our dedicated installation builder box for my purposes I decided to use InstallShield Limited Edition which is available for free with every copy of Visual Studio 2010. Here’s what I found.

Overview

Creating a simple installer is a snap, at first. InstallShield LE (ISLE) integrates into the solution with a ISProj project file. You can then point it at particular projects within the solution to have it consume the primary output, content, localized resources and other artifacts. Other aspects of install projects like branding and simple dialogs were easy to plug in.

You configure releases through the configuration manager. Unfortunately ISLE adds 3 solution configurations for each type of release (I hate that!). You can then select which components are built during this process.

Building the project also went by without a snag. I started to run into problems when I dug deeper. Read on for the down and dirty.

ISLE Need-To-Knows

• The ISProj is just a .Net project reference holder; the ISL file in the same directory is really the driver for the installation builder
• Edits to the ISL file are not recognized by TFS as a pending checkin; any changes require a manual checkout
• ISLE (any IS version for that matter) creates very deep folder structures; release folders should start shallow
• ISProj files and MSBuild do not play together nicely; hand fix ups are required (see below)

Snags Along the Way

Direct File References are Hard Coded

Doesn’t matter, until someone else tries to use it. Adding a file through the file browser will hard code the path into the ISL file. This pretty much breaks Team Build systems or other developers. To fix this I had to open the ISL file by hand (don’t worry it’s just XML).  You need to locate the <Table name=”File”> node. This contains all the files included in your installer. You can add “&lt;ISProjectFolder&gt;”, without the quotes, to get a path to the current location of the ISL file. Hacky? Yes, but it does allow the file path to stay relative.

Great Side Note: Any time you edit something in the ISLE designer it will reset this file path.

ISProj files and MSBuild hate each other

Notice how the “Name” node contains a truncated version of the actual file name? For some reason the ISProj does this. It’s ok for local builds but once MSBuild gets a hold of this you’re done for. Strange “cannot  find project output” errors. Add the full name  in that node to get to get MSBuild (well InstallShield.Targets I think) to behave. Once again, the ISLE designer will re-break this every time.

ISLE Configurations don’t allow Solutions Platforms

At first it seems inconvenient that you cannot select a new solution platform for anyone of the ISLE release types until you realize this limits you to a single output path; now it’s down right annoying. This means you need two builds for your installer because the MSI output will  overwrite the previous one in the Team Build output folder.

One way around this is to venture into the ISL file once again. Before you stop reading, this setting doesn’t get reset by ISLE designer changes! Find the <table Name=”ISRelease”> node. This contains information about your releases (go figure!). You can switch the fifth <td> in the <row> to 1 (or whatever release type you’re trying to duplicate) to trick ISLE into building 2 versions of a particular type of release (CD_ROM, DVD or SingleImage).

In my case I made CD_ROM actually build a SingleImage; but for x64 rather than x86. This way I can create a single “Installer” solution configuration. For the x64 configuration I select CD_ROM (which actually builds as a SingleImage) and outputs to a x64 directory.

My x86 configuration is also a SingleImage and outputs to a x86 directory. A lot cleaner!

One Last Snippet

I was given a requirement to enable the “Install this application for” radio selection. Unfourtunately ISLE does not allow you to enable this in the design. If you head into the ISL file and into the <Table Name=”Property”> you can add a node with the key “ISSupportPerUser” and the value of “1”. This should expose this control.

Hopefully some of this info will help the next troubled soul who decides to use ISLE. If you know any easier ways to solve some of these issues I would love to hear them!

Stay tuned for my next post as I’ll be discussing my proposed architecture for the PowerGUI VSX Debug Engine.