not to be a negative nancy, but ditch InstallScript. I found it's main advantage when i was using it was that it would save me the trouble of malloc'ing my buffers when making MSI API calls. You can do all of the same stuff in C# (if you know your target machines will have .NET) or C/C++/C#.
Considering that most of us InstallShield engineers are lone gunmen, and the rest of the engineer team doesn't know what we're doing, using installScript instead of C/C++ just puts you one more step away from the engineering team. You're more likely to get help from the rest of your team if you use C/C++/C#, and you know you can just debug into your custom actions using Visual Studio or whatever you use if you just create an MSI dll, and use that to implement your CAs.
From personal experience, i'll tell you this: I started off using InstallScrip for almost everything. Sure the initial ramp-up was fast, but the gotchas got me. Including things like the auto case correction "feature" in installscript which actually broke my code! Visual Studio, and C/C++/C# are industry standard. The experience you get from using them actually translates well if you want to get the heck out of the Installation Engineering sub-field, and the tools are more widely used, better supported, and better written.
We recently started working on a new product, and for this product, i'm using an MSI dll to implement all of my non-trivial custom logic, and it's a dream to debug. I can simply put a message box in the CA i'm debugging, and set up a remote debug session in Visual Studio, connect to the process, and boom! I'm in like Flynn, and stepping through code, inspecting memory, stepping through the stack and loving life...and if i have any trouble, the rest of the engineering team is there to help. I'm no longer in a box by myself relying on the community.
Additionally, if you decide that you don't want to pay $2500 for the next version of IS, migrating to another product is much easier if you don't need to rewrite all of your CAs.
