InstallScriptMSI Build Settings

[Christopher Painter]

I havn't done much InstallScript MSI work lately but I decided to play with it since the ISScript engine has been refactored.

I made a release and I noticed a few things:

1) It forced me to create a setup.exe.
2) I streamed ISSetup.dll into the binary table *and* into the disk1 folder.
3) It created a type 19 custom action that enforces use of the setup.exe. It only put it in the UI sequence not the Execute sequence so I don't think it would get checked if I did a /QN install.

Is this still nessecary since the engine no longer has to be bootstrapped? It would be nice to create a .MSI.

[Christopher Painter]

I'm guessing it's needed because of the external UI handler. I've done some interesting tricks with recursion in the past. I wonder what it would be like to use a custom action in the MSI to create the external ui handler process from a stream and then recurse back into the MSI using it.

Probably wouldn't be that pretty..... ohwell.

[MartinMarkevics]

You are right, the ISSetup.dll on the Disk1 folder is always required because it implements the external UI handler, among other things. There has been actually been talk in the past of Windows Installer impelementing a way that you could call an external UI handler inside of the MSI package, but so far it has just been talk. Certainly nothing that we will see in the 4.0 timeframe. Perhaps beyond that, but who knows.

Addtionally, as you noticed in Beta 1, the code always streamed ISSetup.dll into the Binary table, regardless if it was needed or not (e.g. regardless if you had custom actions or not). In a new project (or an upgraded one) it is not required by default, so I changed the code to only include it if it is used in the Beta 2 version. Of course, for Basic MSI (w\ any InstallScript CAs) it is always required as before.

Another thing you might be interested in related to InstallScript, we were able to reduce the engine size since Beta 1, so check it out when you get a chance.

Note: Everyone in this community should have received (or will very soon if you haven't already) information about how to obtain Beta 2.

[Christopher Painter]

Is duplication of ISSetup.dll in the disk1 folder and the binary table really required though? I understand the one in the binary table would be build with the resources for the CA entry points but wouldn't it still have the ExternalUI capabilities in it? It seems like the setup.exe could connect to the MSI database and stream out the one in the binary table, use it in it's process space and then call the msi to begin the approriate sequence.

If so, this would cut the space needed by the package by almost 50%.

PS- I did get word of beta2, but it wouldn't install for me on the machine that I tried it on. I was afraid to upgrade this machine.

[MartinMarkevics]

You're right, currently the two .dlls (in Disk1 and the Binary table if required) are exact duplicates, however, they may not necessarily stay that way in the future. There is obviously some code that is particular only to the UI handler and the MSI custom actions that isn't used in one case or the other, but that's not much. You do incur extra overhead by having the second copy obviously, no doubt about that.

One consideration for InstallScript MSI setups is that, by default, they do not have any custom actions and thus do not require the version in the Binary table. As I mentioned before (starting with Beta 2), you no longer incur the extra overhead if not custom actions are used. It's hard to say how many people would author custom actions rather than use the pre-defined events, but I would venture to guess that most people would utilize the pre-defined events since there is additional overhead in calling a custom (not just the .dll, but the overhead of running another instance of the script engine). Additionally, you don't get the benefit of being able to use any global data from other script calls when you call MSI custom actions, so that would lead me to believe that InstallScript custom actions wouldn't be added that often (in InstallScript MSI setups). It’s certainly possible and not discouraged by any means, it’s just that it’s probably not that likely. That’s just my opinion though.

Having said that, extracting from the Binary table is an interesting option. It has been discussed internally before and it is something we will look at, but almost certainly not for the 12.0 timeframe. There are other optimizations to look into as well apart from this. We’re certainly open to any other suggestions. Thanks for the feedback on this issue.