Recently we've expirienced some problems related to InstallScript engine (bugs 1607 and 1608) on start of installation. Although there is a workaround (manually register idriver.exe or msiexec.exe, etc..) its not sufficient. We decided (and were told by InstallShield support person) to move all our projects to Basic MSI, without InstallScript used at all, even for CA.
Now the questions:
1. What is best to use for CA: DLL ? VBScript ? JScript ? External executable ?
2. What is "Windows Installer dynamic-link library" ?
3. Where is best to store: binary table, install with product, property table, custom action ?
thanks
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.
Eliminating InstallScript
Started by
mishka
, May 17 2004 11:24
2 replies to this topic
Posted 17 May 2004 - 11:41
And additional question - if I'm using "Basic MSI" project and do not use InstallScript, why do I need InstallShield Developer ?? Only as IDE ?
Posted 17 May 2004 - 12:56
I was considering doing the same thing for a package I developed some time ago. The way the Installscript engine is installed is just not reliable. Most often however, the error is local to a specific machine. If you get the error on all machines recompiling the installer a second time usually eliminates the error.
I don't need to tell you I am sure, but what you want to do (convert all custom actions) will require significant effort. I have used VBScript for several custom actions, and it works OK (I was afraid that these custom actions would not work for systems without windows scripting host enabled, but this is not the case. Windows installer runs the scripts on its own). When you use script actions you have access to the session object, this can be useful.
What I really dislike with VBScript custom actions is the poor error handling it offers. I am not sure if JScript is any better, but if it has even remotely better error handling than VBScript it will be worth using over VBScript.
A Windows installer dll is a special dll that only takes one argument, which is the handle to the currently running windows installer session. In other words you cannot pass other values to the dll. Note that you cannot call a function in a DLL that is already on the system as a custom action. The dll must either be installed with your application or contained in the binary table. DLL custom actions run as a separate thread in the same process as the main installation and hence has access to the database at run time (unlike EXE custom actions). You will need to write these actions in C or C++.
When using Basic MSI you are creating real windows installer MSI files. You still benefit from the Installshield Developer interface and a number of advanced features it offers (path variables, dialog editor, in general a much more user friendly front end to MSI-creation). Creating an MSI database without it is a real pain, but there might be new tools on the horizon that makes it easier.
I think what this boils down to is that VBScript or JScript will work fine for easy tasks, but C or C++ might be used for complex tasks that require something more than basic error handling. You will see this from the Installscript code - if you see a lot of try...catch, and you determine that this error handling must still be there after conversion, you need a DLL.
I don't need to tell you I am sure, but what you want to do (convert all custom actions) will require significant effort. I have used VBScript for several custom actions, and it works OK (I was afraid that these custom actions would not work for systems without windows scripting host enabled, but this is not the case. Windows installer runs the scripts on its own). When you use script actions you have access to the session object, this can be useful.
What I really dislike with VBScript custom actions is the poor error handling it offers. I am not sure if JScript is any better, but if it has even remotely better error handling than VBScript it will be worth using over VBScript.
A Windows installer dll is a special dll that only takes one argument, which is the handle to the currently running windows installer session. In other words you cannot pass other values to the dll. Note that you cannot call a function in a DLL that is already on the system as a custom action. The dll must either be installed with your application or contained in the binary table. DLL custom actions run as a separate thread in the same process as the main installation and hence has access to the database at run time (unlike EXE custom actions). You will need to write these actions in C or C++.
When using Basic MSI you are creating real windows installer MSI files. You still benefit from the Installshield Developer interface and a number of advanced features it offers (path variables, dialog editor, in general a much more user friendly front end to MSI-creation). Creating an MSI database without it is a real pain, but there might be new tools on the horizon that makes it easier.
I think what this boils down to is that VBScript or JScript will work fine for easy tasks, but C or C++ might be used for complex tasks that require something more than basic error handling. You will see this from the Installscript code - if you see a lot of try...catch, and you determine that this error handling must still be there after conversion, you need a DLL.
Edited by Glytzhkof, 17 May 2004 - 12:57.
Regards
-Stein Åsmul
-Stein Åsmul