This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Excluding the InstallScript runtime???
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 21, 2010
08:42 AM
Excluding the InstallScript runtime???
Hi all,
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!
Thanks so very much in advance!
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!
Thanks so very much in advance!
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 21, 2010
11:05 AM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 21, 2010
12:32 PM
That sounds great to me. I take that to mean no worries!