I'm starting to weed through the user's guide as we prep to make our switch to InstallShield. I have used IS products in the past and seemed to remember that the InstallScript runtime was a separate .msi.
Our projects will be of the Basic MSI variety and probably won't have any custom InstallScript CAs. In skimming the user's guide, I see there are some project settings that might add Custom Actions to the project. For example, Securing Files, Folders, and Registry Keys in a Locked-Down Environment - Custom InstallShield handling. If InstallShield adds any type of CA for this or any other project settings, are they of the InstallScript variety?
The reason we need to stay away from this is as follows... Our client application install must be completely silent and is launched from the .msi itself. So, we can't have the InstallScript runtime bootstrapped in an .exe.
I thought I may have read somewhere that the InstallScript .msi (if this is still the means of deploying the runtime) can be embedded in and launched from another .msi. Is this the case or should I just have a CA to launch a child .msi if the runtime is not there (search and condition)?
In short, how can I prevent the need for the InstallScript runtime to ensure it won't get in the way of our silent client install?
Any information on settings that need to be set a certain way, etc would be greatly appreciated! If this stuff is in the user's guide, let me know that too. That's one big document!
We haven't used a separate installation for the InstallScript runtime since InstallShield 12. Use of InstallScript in custom actions leaves no footprint since then - it's all just part of the custom action itself.
