Stefan Krueger recently waded into the custom action debate with some very interesting comments.
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.