Comments on DeploymentEngineering.com - The Blog: More Interesting and Uninteresting Comments

I agree, in a micropackaged chained setup environm...

2007-11-30T15:52:00.000-06:00

I agree, in a micropackaged chained setup environment, the cummulative overhead could be considerable.

But consider this, C++ Type 1 CA's written in Visual Studio 2005 have the same problem. The general consensus now is to statically link the CRT libs into your DLL to avoid dependency problems at runtime. This add's about 1MB to the CA DLL.

Chris,I'm not weighing in on the InstallScript CA ...

2007-11-30T14:35:00.000-06:00

Chris,
I'm not weighing in on the InstallScript CA issue per se (you already know I don't like them, for many of the same reasons Carl listed). I just wanted to point out your reply to Stefan's size issue is really only valid for large packages (as you said). However, consider the upcoming MSI 4.5 chaining ablities. You will now be able to write an external UI handler to process multiple MSI installations, which (IMHO) would lead to [multiple] small size MSI packages being used to contain the components associated with specific features (see the MS Office 2007 install for an example). Assuming that is correct, now the overhead of InstallScript does come into play because the InstallScript engine is in multiple packages (unless Macrovision does something to counter this like providing an IScript Engine redistributable MSI that can be installed as a pre-req). Just my 2¢

Hi Carl- I'm the first to acknowledge that the *o...

2007-11-30T08:30:00.000-06:00

Hi Carl-
I'm the first to acknowledge that the *old* InstallScript engine had major DCOM/ROT problems. I wrote a blog on this subject where I pointed out that the problems were so bad that they created a support site on their own. But I feel it's a bit dishonest to use this as a reason to hate InstallScript considering that the complete redesign that occurred in IS12 was nearly 2 years ago. I'm sorry, but mentioning this and IS7 suggests to me that you are living in the past.
Rob's comments have to do with design. It's not InstallShield's fault if a developer writes anti patterns. ( See OMG, InstallShield Killed Kennedy ) A developer could just as easily write an MSI anti pattern in C++, VBScript, and/or Installer Class CAs.
Now about your comment of `MSIs are open format database`. That is correct, the database and only the database are open. The standard actions that process the data are completely closed source. You have no idea how they do what they do other then what the contract with the data tables suggest that they will do for you.
Nothing stops you from writing a data driven CA in InstallScript that is essentially the same as above. You can expose the points of variability as data tables and document them to your customer as to which action processes the table and what the rows mean. This is the interface or contract if you would. The implementation ( InstallScript and/or C++ source code ) does not need to be exposed to live up to the same standards as MSI itself.
If you feel you need to expose the actual implementation source, then write in VBScript. The only problem there is Script CAs are every bit as unreliable as the old InstallScript CAs so I find it interesting that you would accept this risk while holding InstallShield to the fire.

Hi Christoper,Carl hereReasons for disliking Insta...

2007-11-30T05:38:00.000-06:00

Hi Christoper,
Carl here

Reasons for disliking InstallScript:
Until InstallShield 12 the engine simply did not work. About 1% of all installs failed. The same problem has dogged every version since 3. It hung, crashed or refused to work. I make no distinction between the InstallScript MSI and an MSI with InstallScript CAs because they both fail unexpectedly.

As Rob Mensching explained, http://robmensching.com/blog/archive/2007/08/17/Zataoca-Custom-actions-are-generally-an-admission-of-failure.aspx most people use it through ignorance. They don't know how to do something through the tables so they script it. People read the help file and see that wonderful collection of InstallScript functions and have no idea that they are doing it wrong. They fall into the traps of not catering for silent installs or worrying what will happen when the package repairs and all the other goodness that the MSI engine provides because they never need to learn about the engine.

I'm sure your InstallScript CAs are fabulous because you do know where to use them appropriately. Unfortunately you are on your own there.

as for your other points:
InstallShield 7 introduced the abomination that is the InstallScript MSI project ... your point is what exactly?

The great thing about MSIs are that they are an open format database. When your corporate customers use them they open them up to see what they do and change them to fit their standards and needs (e.g. no shortcuts on the desktop). They are open, transparent and easy to understand. exactly the same can be said of VBScript Custom Actions