We’ve long heard the rants against Script based CA’s, Managed Code CA’s and CA’s in general. Lately Microsoft has begun blogging about the horrors of even EXE CA’s.
IMO when talking about CA problems, is isn’t really the CA that is the problem. The problem is in the CA hosting models and therefore it’s really MSI that is the problem. And when preaching against CA’s in general, yes it is true, somewhere north of 90% of the CA’s written by developers truly aren’t needed. However the other 10% is really a result of MSI not being `feature complete` as defined by the customer instead of as defined by Microsoft. Unfortunately there doesn’t seem to be any change coming in the near future.
So where does that leave us? Type 1 DLL standard call CA’s:
Ultimately, avoiding CAs is the best approach but, when necessary, you should develop DLL CAs. Immediate DLL CAs can read from the installer package database and should be data driven, making it easier to service that data and providing perhaps some transparency to what your CA does. Those immediate CAs can then schedule deferred, rollback, and commit CAs as necessary based on that data and the current state of the machine. -Heath Stewart
But wait, who says they have to be written in C++? Well, no one does really. You see, as I previously blogged, starting with InstallShield 12 InstallScript CA’s are really just unmanaged Type 1 CA’s.
While there are a couple downsides ( mainly larger package size and slightly slower execution ), I think the upsides far outweigh them.
Not based on ActiveScript / Windows Scripting Host.
A C like language that is easier to code in then C++.
A domain specific language that has many proven functions for tackling setup related problems. This results in increased reliability as you aren’t making stupid mistakes trying to roll your own everything and reinventing the wheel in C++.
Integrated into InstallShield. This makes it easier to develop, build and test in one easy to use IDE.
Doesn’t add additional dependencies to your install. You won’t need setup.exe to deploy some runtime to run your CA. You also won’t find broken installs because someone built the debug C++ bits or didn’t include some C++ runtime dll.
Can be transplanted into other installs. Stream out of one binary table and into another. It’ll even work when writing transforms for packages made in other authoring tools.
Can easily use MSI API’s to create data driven CA’s.
I’m sure I could go on and on but I’ll stop right there. InstallScript has really come a long way and is the right tool for the right job.