Stefan references my believe in InstallScript custom actions and mentions a couple downsizes. Mainly Installscript engine size ( package bloat ), possibility of InstallScript engine failure and the temptation to use InstallScript CA's to make system configuration changes instead of built-in MSI patterns. Specifically he says:
However I believe that the tasks of a custom action often aren't typical installation tasks (copying files, accessing the registry) but require calling some APIs to interact with other applications.
Personally my packages tend to be very large and complex so the engine overhead is a non-issue to me. However, I could see it could be a consideration for small packages. I've also found the InstallScript engine to be very reliable.
I find InstallScript's ability to call Win32 API, COM and ManagedCode with very little plumbing ( let's just say you won't be worrying about things like allocating memory, casting datatypes and hosting COM servers and the CLR ) to be one of the strongest reasons for using InstallScript. For example, in one of my client installs I prompt the user for the hostname and port number of an application server. I then pass this information off to a .NET class that invokes uses the information to invoke a webservice. Anyone want to take a guess at how many lines of InstallScript and C# that is? Anyone want to take a guess how many lines that would be in C++? I've been using this code in production for 1 1/2 years now and I've never ever seen it fail.
Another example would be where you need to make a change that MSI doesn't support. The built-in MSI functions make it easy to implement the database queries needed to author data driven CA's and the extensibility makes it easy to interop with whatever external API you need to talk to install, uninstall, commit or rollback the configuration change.
Now for the uninteresting comment. A developer named Carl replied to Stefan's blog with this nugget:
Christopher Painter is wrong. InstallScript MSIs are never appropriate. Leveraging the language into MSIs was dreamed up by InstallShield's marketing team to con people into 'upgrading' to InstallShield 7 saying that "you can upgrade to MSI and your old scripted package will still work"
It had no place in an MSI then, and it has none now.
Personally I like VBScript. It has the advantages of being easy to read, open source and can be debugged from within the MSI using the MSOffice debugger.
Well, I've said it before and I'll say it again. Some developers just LOVE to HATE InstallShield. Here is another developer who's convinced that I'm wrong and InstallShield sucks. Never mind that he doesn't know the difference between an InstallScript MSI and a Basic MSI with InstallScript CA. Never mind that he mentions InstallShield 7 and that he prefers to use ( shudder ) VBSCript CA's. InstallShield is evil and they have conned the world.
4 comments:
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
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.
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¢
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.
Post a Comment