Software Deployment

To answer your first question, it depends on what isscript is doing within the MSI. You can use isscript to create dialog boxes or run custom actions or both. If isscript is only used for dialog boxes and you're running in the install/uninstall silently, then you shouldn't need isscript at all. If isscript is being used for a custom action that runs on install only then you'd need it for install only. Same goes for uninstall.
To be safe, I'd uninstall the MSI first, then isscript.

I'm no expert in isscript, this is just what I've encountered personally.

Your second question: "usually". They're supposed to be fully backward compatible but I've heard of rare cases where a specific version was required. 99% of the time, you should be ok.

Thanks very much for this reply, you've confirmed some suspicions I had about ISscript.

1) ISScript may be required at any time during the installation, repair, or removal of a product, depending on how the package was built and which custom actions are called in the sequence. Therefore, you should not uninstall ISScript before uninstalling the product. Although, to be honest, I'm not sure you can. I think (but I haven't confirmed) that ISScript is a one-way installation.

That aside, I would never uninstall ISScript in case it is needed by another ISScript-dependent application on the machine. Unless you are taking particular care to track every ISScript-dependent application and you are using some kind of shared component counter to track how many applications require each version of ISScript so as not to remove it until the shared counter equals 1, you should not uninstall ISScript.

2) Newer versions of ISScript (e.g. ISScript11.msi, ISScript105.msi, etc.) are not backward-compatible. That is, if you are deploying an installer that relies on ISScript8.msi, you cannot get away with installing ISScript10.msi. You must* deploy ISScript8.msi. If there is a newer minor release of a particular version of ISScript (e.g. 8.0.123 vs. 8.0.120), I suppose you can use the newer of the two.

* If you carefully modify the installation sequence to eliminate your dependency on ISScript (usually by disabling custom actions that call ISScriptBridge.dll), you may be able to free yourself from the need to distribute ISScript at all. I have done this in the past (at the request of others), but I am reluctant to promote this because you are essentially modifying the vendor's installation, and you must compensate for any custom actions that you remove that are critical to the installation of the product.