I have actually had some luck with this. Though the InstallShield automation does not provide any method for creating or modifying a Chained MSI setup, there is another option.
As long as the project file is saved in binary format (instead of xml), it can be accessed as if it were an MSI by using Windows Installer Automation to edit the database tables. In order to discover what changes needed to be made to which tables, you can save two identical projects in XML format, diff them with a tool and see which tables get modified.
My current method of automation for creating a Chained MSI is as follows:
- Save a project 'template', containing non-dynamic options and elements.
- In that template, add a single, empty, placeholder Chained MSI package (needed so that the other tables have the necessary Chained MSI tools, so we don't have to add them dynamically).
- Open that project with Windows Installer Automation in a script.
- Edit the ISChainPackage and ISChainPackageData tables to add an entry (in each) for each Chained MSI package desired. You'll find that if you analyze what these tables look like if you were to add packages from the GUI, you'll find that everything is straightforward except for a string preceded by an underscore in ISChainPackageData. This string, as it turns out, is a simple MD5 hash of the file name of the msi.
- Remove the placeholder entry from both ISChainPackage and ISChainPackageData.
It's definitely not the most straightforward technique, nor anywhere near easy to implement, as Windows Installer Automation usually lacks good examples, but with a good amount of trial and error and time, it's doable.
Edited by scrilla103, 05 September 2014 - 18:40.