4 replies to this topic

[MonkeyK]

I was wondering if there are any best practices for custom actions. Some considerations that I have noticed are:

1)Reasons VBscript is better for custom actions than InstallScript

• Doing so requires the installscript engine while the windows scripting engine is already installed. (for web based installs the bandwidth difference could be significant)
• VBscript is quicker to develop (not within InstallShield, but it is faster to create a .vbs file and run it than to build an installshield project and run it to get to the script)

2)Reasons InstallScript is better for custom actions than VBscript

• Installscript has some functions not available in VBscript
• Installscript has better error handling (try,catch) than VBScript

Would anyone care to expand on this?
Anyone know of performance implications of VBscript vs Installscript?
How about specific limitations of either one?


Todo when using VBscript:

• Where to put the script code
  • for simple scripts put it in the custom action
  • for bigger scripts put them in binary - binary and in custom action give flexibility in when the custom action is called (can be before the files are copied)
  • for persistent scripts use a installed file
• know and use return values - these allow the install to handle errors in your script
  • ERROR_SUCCESS = 0
  • ERROR_INSTALL_USEREXIT = 1602
  • ERROR_INSTALL_FAILURE = 1603

any others?

[Stefan Krueger]

VBScript may be disabled or blocked by anti-virus software.
The most robust custom action would be a DLL written in C, however it would also be a black box.

[MonkeyK]

C DLLs are probably the best solution overall. Probably fastest in execution and smallest in size. Debugging can be done in Visual Studio. The only downside is that the install developer needs to be able to create a C DLL.

I thought that I saw a previous topic explaining that vbscript would not be disabled under Windows Installer as Windows Installer is it's own script host.
The antivirus software blocking scripts would be a serious problem. How does antivirus software know that the vbscript in an install copying a file is bad, but that the installscript doing the same thing is not?

[MonkeyK]

Hmm, it looks like AntiVirus programs such as Norton AntiVirus redirect the filesystemobject to override it with thier own custom version that then allows the AntiVirus software to block.

This seems like a pretty patchy solution since there are many other ways to copy/create/delete files.

Even if the override were a good solution, one would think that the Windows Installer service's Windows scripting host should redirect it again. If I am already going to be creating, copying, and deleting files, why should something care what I use to do it?

[Stefan Krueger]

I guess Norton's policy is "all VBScripts are bad" no matter what they do or who is running them. On the other hand in general it would be recommended to disable your anti-virus software during installation. But how many users really care about this?