Suggestions needed in creating a flexible InstallShield project architecture

[Hiren_Patel]

Hi All InstallShield Gurus,

I need suggestions in creating a flexible InstallShield project architecture for a software that will be sold to hardware OEM. Sorry I cannot give out more details on the customer names... hope you understand.

So basically, my company sells OEM branded software that is repackaged with same files but compilations\run-time behavior is different based on the OEM customer.

I have to create an installation software project that installs same files, BUT it must install those files as a different Product Name and as such it must have its own unique Company Name, folders, graphics, shortcuts, registry entries, Add\Remove Applet entries, Component GUIDs etc… One major requirement is that if this final software were to be installed side by side by consumers, the installer from both OEM should work and components are not shared or uninstalled by each others hardware.

Obviously, I was thinking of creating a solution\project file and once it installs properly, change all STRING Table entries and GUIDs and save it as a new ISM file… and keep doing it for EACH new OEM customer we sell our products too…. so I know already that I have GUID management nightmare… is there an another solution more elegant and easy to maintain other than managing multiple ISM files…

BTW, I have flexibility to use MSI or InstallScript engine and\or even NEW IS2012 InstallShield projects with external IS GUI in MSI… Other things to know, this project will be localized in over 7 different languages and more... and may have customized GUI for InstallShield screens--which I know it can be done with MSI 4.5 projects in InstallShield 2012 (in concept, at least).

Thanks in advance!

[operaza]

Create a database (that could also be updated automatically for new "environments") and use the installshield automation object to create your installer project with the information from the database.
For stuff not supported by the automation interface, which I'm sure you will find in the process, you can use xmldom to modify directly the .ism project as part of the build script, and you can also use WixXML to create merge modules for stuff not supported in installscript projects (thanks Christopher Painter for the tips)

[Hiren_Patel]

Thank you! A DB driven ISM file seems interesting I will have to prototype it on small scale to see how it pans out...

I was also thinking of searching and replacing various strings in ISM's XML file and then building a project... via scripting in build automation, of course!