My apologies to anyone who frequents the IS Community and has already been through this.
We are currently using IS DevStudio 9, and have two major projects set up as InstallScript MSIs. We also have an increasing number of customers using Active Directory who would like to distribute our client through that technology, so we are in the process of evaluating a move from InstallScript MSI to Basic MSI.
I'd appreciate getting some opinions on some of the issues I can see we'll be facing.
1. We'll have to create some custom actions to replace some of the stuff we currently do in scripting in OnBegin, On...UIBefore and On...UIAfter. What is the best way to create custom actions in a pure MSI? I understand that Windows Installer will handle custom actions in VBScript or JScript without requiring that you load a script engine - is that correct? Or would calls to an external dll be preferable?
2. Currently, our main client project installs the core client files, then executes a series of Basic MSIs to install add-ins that are licensed and selected. I have read several places that Installer's nested installs are a good thing to avoid. What's the best way to conditionally execute other installs from an MSI? Or would we be better off redesigning our projects so that these additional installations go away? We originally designed the projects the way we did to cut down the size of the installation package so that customers wouldn't have to download or copy stuff they didn't need.
3. We have been looking at the material released on the upcoming MSI version 3.0. My management is particularly interested in the uninstallable patch capabilities. Currently, I distribute minor upgrades to our product as a full package because of the add-in installs and because we've had some issues creating patches with IS. Are there any design techniques that I should adopt to make patching go more smoothly with an MSI? Are there any issues that you're aware of with issuing patches to projects that are distributed with Active Directory?
Again, I welcome any suggestions/hints/comments that you feel like sharing. Thanks.
Kathy Morey
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Converting to Basic MSIs for AD
Started by
KathyMorey
, Aug 05 2004 15:06
2 replies to this topic
KathyMorey
-
- Full Members
- 111 posts
Posted 05 August 2004 - 15:06
Kathy Morey
Synergy Software Engineer
ProfitStars, a Jack Henry Company
kmorey@profitstars.com
Synergy Software Engineer
ProfitStars, a Jack Henry Company
kmorey@profitstars.com
Glytzhkof
-
- Moderators
- 1,447 posts
Posted 06 August 2004 - 04:47
| QUOTE |
| 1. We'll have to create some custom actions to replace some of the stuff we currently do in scripting in OnBegin, On...UIBefore and On...UIAfter. What is the best way to create custom actions in a pure MSI? I understand that Windows Installer will handle custom actions in VBScript or JScript without requiring that you load a script engine - is that correct? Or would calls to an external dll be preferable? |
Basic MSI does not have an event model like Installscript MSI, but in return it is much less buggy. I do think there are about 4 event handlers still there, but I don't have the software here to check what they are. Should be something like OnBegin, OnEnd etc...
Custom actions can run an EXE, DLL, VBScript, JScript, Installscript etc... It is correct that script custom actions does not require the Windows Scripting host to be installed. It does require a couple of runtime files however, but these are all protected OS files from W2K upwards.
What I would generally avoid is the Installscript language. Saying that here will be controversial, but the problem is that running Installscript requires installation of a runtime engine whose installation is often problematic and can turn out to be the leading source of errors for your setup.
My personal choice would be script actions for everything except stuff that needs heavy exception handling. For this I'd use pure C++ (no MFC, ATL etc...).
| QUOTE |
| 2. Currently, our main client project installs the core client files, then executes a series of Basic MSIs to install add-ins that are licensed and selected. I have read several places that Installer's nested installs are a good thing to avoid. What's the best way to conditionally execute other installs from an MSI? Or would we be better off redesigning our projects so that these additional installations go away? We originally designed the projects the way we did to cut down the size of the installation package so that customers wouldn't have to download or copy stuff they didn't need. |
Yes, please avoid launching custom action MSI's. They will just cause you headache. Hard to know your requirements just by reading here, but I would go for one main setup, and one separate setup for the addins. You could use compiler flags in your second setup to deliver smaller setup.exe files for single addins.
Another option is to install all addins and have the main app activate or deactivate them based on license keys inserted. I find this more reliable.
| QUOTE |
| 3. We have been looking at the material released on the upcoming MSI version 3.0. My management is particularly interested in the uninstallable patch capabilities. Currently, I distribute minor upgrades to our product as a full package because of the add-in installs and because we've had some issues creating patches with IS. Are there any design techniques that I should adopt to make patching go more smoothly with an MSI? Are there any issues that you're aware of with issuing patches to projects that are distributed with Active Directory? |
Yes, I would get a copy of the "Practical Windows Installer Solutions" book from Bob Baker (Installshield press). If you read chapter 11 and 12 (I think), you will have what you need to build more patchable setups.
Regards
-Stein Åsmul
-Stein Åsmul
KathyMorey
-
- Full Members
- 111 posts
Posted 06 August 2004 - 14:08
Thanks for your reply. I have a couple clarification questions:
| QUOTE |
| It is correct that script custom actions does not require the Windows Scripting host to be installed. It does require a couple of runtime files however, but these are all protected OS files from W2K upwards. |
We have customers who are still using Win NT. Are there distributables for installation of those runtime files, and where can I obtain them?
| QUOTE |
| ...but I would go for one main setup, and one separate setup for the addins. |
Our current add-in setups use AppSearch to obtain they information they need to install - they run with no user interface dialogs (we've removed them from the user sequence), and the main client files must be installed first. Will that work in an Active Directory environment? In other words, if a customer publishes our client and the add-ins they want their users to have, can they control the order of the installation, or do we have to allow for user interface in the add-in projects as well?
Kathy Morey
Synergy Software Engineer
ProfitStars, a Jack Henry Company
kmorey@profitstars.com
Synergy Software Engineer
ProfitStars, a Jack Henry Company
kmorey@profitstars.com