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
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.
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.
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.