EVALUATION
I think Bill intended to say we need to call our Files-In-Use custom action *after* the other custom actions above.
Please also see CR 6674868...we initially called our own FIU (custom action) as a workaround to the difficiencies of the MSI native version.
The native version is invoked in InstallValidate in the InstallExecute sequence. We needed to call our own before InstallValidate in order to avoid the native version.
To address the issue of this CR, we'll need to move our own FIU to a point in the InstallExecute sequence that is *after* InstallValidate. This will increase the likelihood that MSI's native version of the dialog will be invoked, but that's ok. Here's why...
The native version of the dialog will not catch java[w].exe or jbroker.exe because there is no associated window with these processes. This is one of the downfalls of the native dialog that prompted us to create our own version in the first place. Therefore, we will not need to remove java[w].exe or jbroker.exe from the RemoveFile table...they will not cause the native dialog to be invoked.
In considering 6674868, any problems associated with the native version of the dialog will STILL be handled when our 'custom' version is invoked. For example, if the user clicks 'ignore', that's ok because our FIU will be invoked later and handle any processes that are still locking the JRE.
The ONLY downside to this fix is that there is potential for 2 "files-in-use" dialogs being displayed. In my opinion this is also ok because the potential for that is very low (user would need to click on 'ignore', or start more java procs after the MSI version is invoked).
Generating a webrev now for moving the Files-In-Use custom action down the InstallExecute sequence...
|
Java