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.


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.

You can leave a response, or trackback from your own site.

6 Responses to “Working with InstallShield Limited Edition”

  1. John says:

    Have you run into the problem with the IS LE project loaded in a solution and VS 2010 blows away when you are working with a source file? I have three separate solutions where this happens. The only workaround I have is to unload the IS LE project, work with the source, and then reload IS LE. Not a pretty picture!

    • adriscoll86 says:

      Are you talking about source files in projects besides the IS LE project? If so, I haven’t had that issue before. That’s a pretty major one and I would consider escalating that to Flexera.

  2. John says:

    Interestingly, it’s not any source file, but specific ones – very reproducible. Since I have a simple workaround, I didn’t escalate. I will now, however.

  3. Dev says:

    This “InstallShield Limited Edition” sucks. Microsoft really screwed up its customers by deciding to retire Visual Studio Installer. Now you must pay for a decent installer builder. To understand what I mean – try to install a Windows Service with this ‘Limited (we are forcing you to pay us) Edition’!

  4. David says:

    I am using the Install Shield LE with VS 2013. I added some files from my local DEV. On adding the files, I see that their absolute path have been taken into consideration. So, if the installer is build in upper environments, will it not break if the files are not there in the same absolute path? Is there any work around without any further upgrade to the Limited edition? Appreciate if somebody can respond

Leave a Reply

In an effort to prevent automatic filling, you should perform a task displayed below.