I have been playing around with Installshield 2009 and C# to create a setup project that validates a serial key (the algorithm written in .NET) before installation. It works great.

However I have several versions of a product. At the moment I use separate setup projects for each version. However many of the files are the same, with only small variations in which files are included or not. I would love it if I could have a single deployment project that installs certain files depending on which valid serial key is detected.

Basically I'm wondering if this sort of thing is possible with Installshield.

Thanks in advance

+1  A: 

Windows Installer isn't well suited to the scenario you describe, at least unless you take the time to prevent the use of improperly installed files with some sort of licensing technology. You could have your serial validation dll also set a property that various features or components condition off of, however a transform can easily sidestep this. Unless you've taken (or can take) the time to implement license verification, your best bet is to maintain separate builds (one per different set of allowed files). However you may be able to merge these into a single project.

Depending on exactly what differs between builds, I think there are two complementary approaches that get you your separate SKUs. The first is most easily specified on a per-release basis, and you can select which release to build e.g. from the command line. The second is irrespective of release, and can either be updated manually or can be overridden in a command line build.

  1. Release Flags

    You can separate groups of items into extra features (perhaps hidden so they don't clutter the feature selection dialog), and then use release flags on a per-release to include or exclude these files at build time. This would probably work best if you are changing out content files, but continue to use the same custom action DLL across separate SKUs.

  2. Path Variables

    The path to your custom action DLL can be specified with a path variable that you can then use to override the source location of the file. Make sure the corresponding entry (likely either in the File or Binary table) uses its own variable in the angle brackets, and then you can swap it out individually at build time as well. This makes sense if you need to change your custom action DLL, and can be used alongside Release Flags.

Michael Urman
thank you that helped a lot
If it helped, then please accept his answer as the correct one!
Mat Nadrofsky

You can add and remove features at run-time. This can be accomplished with (a) installer properties or (b) in install shield scripts.

First you would add all the features for all the versions to the project. You would ensure they are not selected to be installed. Then you would use either method a or b to select one while running.

Installer properties (a) can be set in various ways. Command line switches to the installer, OS versions, certain reg keys being present, or via custom logic in a DLL. And features can be included/excluded based on an installer property being a certain value.

As for (b), the script has access to the "feature tree" and can select & unselect them based on custom logic using FeatureSelectItem(), etc