Guess What Else InstallShield Can Do!

Flexera’s InstallTalk blog recently posted a blog articled titled `I Didn’t Know InstallShield Could Do That?` I mainly reference the article not for the content but to use it as a hook for a more interesting albeit darker version:

InstallShield can be used a bootstrapper for a WiX MSI.

…evil laugh…

It’s simple.  InstallShield 2011 Premiere has some new features that allow you to inject custom commands at various stages of the build process.  One of these steps is the Precompression Event.  This event occurs right after the MSI has been built but not yet digitally signed.   This allows you to do custom post build processing of the MSI without breaking it’s digital signature. 

InstallShield’s handling of Setup Prerequisites ( the kind that run before you MSI ) it’s fairly loosely coupled from the MSI.  Feature prerequisites are a bit more complicated but not impossible to reproduce.   Let’s look at the work flow.

1) Create a Basic MSI project ( call it anything you want ) and then give it a feature and a component.

2) Add the .NET 3.5 SP1 setup prerequisite using the redistributables view.   Right click and select properties and type in a release flag of DOTNETFRAME35SP1.

3) Create use the Release Wizard to generate a new Product Configuration and Release.  Pick a compressed network image with setup.exe.

4) Set ProductName, ProductVersion, PackageCode, ProductCode and UpgradeCode to the same values as in your WiX msi.  Set the Generate Package Code value to false and set the MSI Package File Name field to be the same as your WiX msi ( without the .msi part ).

5) Copy your WiX MSI to the location specified as under Path Variables.

6) On the Build Events tab of the release paste in the following precompression command

cmd /c copy "<ISPROJECTDIR>WiX35.msi" "<ISPROJECTDIR>WiX35Release 1DiskImagesDISK1"

8 thoughts on “Guess What Else InstallShield Can Do!

  1. MSIYER

    Hey Chris,
    I have started blogging and would like to share my experiences with the world. Would you be kind enough to go through my blog and tell me if it is proper.

    Also, could you tell me how to make it accessible to more people. I have no idea about the blogging universe.

    Thanking you in advance.

  2. Christopher Painter

    Just for fun I rebuilt IsWiX.msi as en-US and es-es. Then I used torch to generate 1033.mst and 1034.mst to match InstallShield naming standards. I built a ProductConfiguration that used the Languages dialog (setup.exe) and the en-US an es-es languages. Everything slipped together just like you would expect.

  3. Christopher Painter

    You'll have to reverse engineer how InstallShield handles the language transforms. I think it builds a bunch of transforms then embeds them in storage and calls them with different TRANSFORMS= command line arguments. If that's the case ( 95% certain ) then you'd have to build and embed those same transform names into your WiX MSI. Then I'm betting that InstallShield's Setup.exe dialog that picks the language would then connect the dots to your transforms.

  4. Anonymous

    It seems a very promising approach, which allows for combining the power and reliability of IS bootstrappers with WIX MSI files. Yet, there is a question about the applicability of this method in the scenario of building multlilingual packages.

    Let's assume we need to build English and French language targets. The corresponding release folder will contain 1033 and 1036 transforms along with setup.exe and MSI files.
    Did you have a chance to verify if the transforms for the WIX MSI files can be manipulated so that they would replace IS MST files? And actually, which MST file should be used instead of 1033.MST (assuming that fr-FR.mst should allegedly replace 1036.mst)?

  5. MSIYER

    Hi Christopher,

    I am a Mechanical Engineering graduate who jumped into software industry in 2009 to stay close to Abstarct Mathematics.

    I have been in the installation business since MAY 2010.I was thrown into it because in a team of 30 developers(all vastly experienced than me), no one wanted to do the low profile installation, setup development job.

    I had no choice. My prior experience was in c# and VC++ MFC.
    I had no idea how Windows Installer worked or what Installshield shielded us from.

    I can learn. And learn well. That is the only thing I am good at. But learning Windows Installer technology and simultaneously providing the learned clients(who themselves are seasoned professionals) quality solutions to the installation problems
    was like fighting Bruce Lee blindfolded.

    By DEC 2010, I had released four products and created a new installer for an indexing utility designed for replacing the Full-Text indexer of SQL Server 2008.
    A team of 35 professional testers could not find any show stopper in the installation.

    No one ever believed I could achieve that. Alone I would not have. I had guys like you to learn from. Rob Mensching, Stefen Krueger, Phil Wilson were so inspiring.

    The word in one of your blogs that forced me to write this comment is PASSION. I know what that means.

    The troubles and the level of difficulty in setup development brings the best out of me. It took me deep into my true self. It gives me something to cheer about and to be proud of.

    I have immersed myself into the Installscript project type. So, I am, now standing where you started from- script based installs.

    KEEP INSPIRING CHRIS.

  6. Christopher Painter

    I'll have to try this at home with 2011 but I know on 2010 you can build a single compressed MSI with no setup.exe and enable language transform generation. You get files like 1033.mst and 1034.mst. The 1033.mst is empty ( 4kb ) in my case and the 1034.mst is bigger ( 89kb )

    If you use WiX to build product_1033.msi and product.1034.msi you could then use WiX's Torch utility to generate those two transforms.

    As long as you keep the file names the same you could copy it all in during the precompression step then it would all get sucked into the setup.exe.

    Untested of course but I'm 99% certain this would work.

  7. Colby Ringeisen

    Regarding the language transforms questions: also make sure you check whether the InstallShield generated transform files are embedded in the MSI or in the EXE. I _think_ they are embedded in the EXE itself by InstallShield (but I could be wrong about this).

  8. Colby Ringeisen

    Interesting. I didn't know you could do that. This seems like it would work well with (or maybe even replace) the [undocumented] InstallShield utility for updating the key=value settings in a setup.ini embedded in a compressed setup.exe (SetupINI.exe for 2009, internal_SetupINI.exe for 2010, not sure if it still exists for 2011).

    I use that tool extensively in my build process to change the location of prerequisites and for dynamically changing the setting that modifies the msiexec command line during a minor upgrade installation (that adds "REINSTALL=ALL REINSTALLMODE=vomus IS_MINOR_UPGRADE=1" to the msiexec command line) so that I can control at build time whether or not the install will require the uninstall of a previous build or not. The only issue with the tool I've had so far is that it doesn't work after setup.exe has been signed so you have to have InstallShield generate an unsigned setup.exe, tweak the embedded setup.ini, then sign the setup.exe during your build process.

Comments are closed.