This sounds like a great idea on the surface, but having probed it a bit deeper it raises a lot of questions I don't have good answers to. No matter the answers this strikes me as too big for 12.0, but say we implemented this, what do you think it should do in each of these scenarios:
1) You have a basic msi without any script CAs and are editing it in direct mode. You add a setup.rul file and sequence an IS CA. You hit save only to receive a compile error. What should be saved?
2) You fix all your compile errors and then want to add another action. Is the setup.rul you were editing in step 1 still available, or do you have to add a new one?
3) You save your work, close the IDE, and go home (I hear it happens, honest!). The next day you want to modify one of the three functions you added in one go the previous day. Is the original setup.rul somehow still available, or do you have to "obsolete" one of the functions from the first set and work on a new setup.rul today which reimplements that function?
I'm not convinced there's a good answer to any of these. Any time we completely discard a previous setup.rul that means there's a an issetup.dll worth of overhead. But if we don't there's the chance of accidentally pointing to the wrong setup.rul (if it's stored externally) or accidentally releasing your script code (if it's in the direct MSI somehow). And this still sidesteps a lot of making sure we don't end up with multiple conflicting f1, f2, etc. entry points.
Maybe what would be more useful is an "issetup.dll project" whose input is a script file and whose output is an issetup.dll ready for inclusion as an MSI DLL with a document mapping entry points to function (or vice-versa).
Michael Urman - Staff Software Engineer - Flexera Software: InstallShield Team