tag:blogger.com,1999:blog-9537945.post-44959225976858767262007-11-30T08:30:00.000-06:002007-11-30T08:30:00.000-06:00Hi Carl-<BR/> 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.<BR/>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.<BR/>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.<BR/>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. <BR/>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.Christopher Painterhttp://www.blogger.com/profile/12167478740431444267noreply@blogger.com