1 reply to this topic

[pnunes]

I primarily use InstallScript to handle custom logic in my installers. However, lately I have been considering using VBScript or DLLs for the following reasons.

1. When using any Installscript Custom Actions, the MSI file explodes by as much as 2MB. Using Orca shows that the bulk of this is the InstallScript Engine.

2. During MSI initialization, the entire MSI file is copied to the TEMP directory and the Installscript Engine is activated. Although most of the engine is stored in Common Files, the design of MSI forces the Engine components to always go along with the MSI file.

Lately, I have been required to minimize the size of installations so that remote users have shorter download times over dial-up lines.

Has anyone explored ways to make InstallScript behave more efficiently maybe by editing the MSI directly?

If not, I now need to migrate all of my InstallScript to a more efficient language like VC++. Does anyone know of any tools that speed this process?  I have a lot of code that depends on Installscript functions that need porting. I think porting to DLLs is my best long term solution, but I need a stopgap solution for the near term.

Any ideas would be greatly appreciated.

PRN

[pnunes]

With a little experimenting I found that I could remove the "Engine Startup" action from both the "InstallUISequence" and the "InstallExecuteSequence". This allowed me to also remove the "ISScript.msi" from the Binary table. I believe that this binary and CustomAction together form the bootstrapping for the InstallScript Engine.  I should be able to handle the Engine installation myself in a different mechanism.

It seems wasteful to me that Installshield opted to include a copy of the InstallScript Engine with every MSI. Since this is included with every cached copy of the MSI's that use ISSCript, that is a lot of disk space.

Any thoughts on the validity of removing these items from MSIs?