This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Checking for files in use at the Suite level
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
‎Apr 04, 2014
04:39 PM
Checking for files in use at the Suite level
There are two predefined secondary windows for the Suite Wizard pages that appear to be intended to be used for checking files that are in use. They are ISFilesInUse and ISRMFilesInUse. I have not been able to find any documentation about how to use them and their associated properties ISFilesInUseList and ISCloseApplications. While I could get the dialog to display with a Click Show Window action and populate the list there doesn't seem to be any logic hooked up to the dialog. Does anyone have any idea about how these are supposed to be used?
Note to the InstallShield docs team - this feature appears to be completely undocumented!
Note to the InstallShield docs team - this feature appears to be completely undocumented!
(4) Replies
‎Apr 07, 2014
04:23 PM
These are automatically used when a MSI package reports the related event; unfortunately while you can change the appearance, you can't really change the interaction with the running installations.
If you want to make your own similar dialog, while it's easy to use it to set a property, it's unclear to me what you would expect setting that property would do. If this didn't help, can you expand a little on what you want to handle here?
If you want to make your own similar dialog, while it's easy to use it to set a property, it's unclear to me what you would expect setting that property would do. If this didn't help, can you expand a little on what you want to handle here?
‎Apr 08, 2014
04:34 PM
Thanks for explaining that ISRMFilesInUse is invoked automatically by the MSI packages. Once I knew that, I tested while leaving some of the install targets running and saw the dialog appear. It appears that this is just a suite-level replacement for the Windows Installer MsiRMFilesInUse Dialog.
One of the reasons I was confused was that I was expecting a feature that allowed me to terminate selected processes at the start of the suite install and optionally restart them at the end instead of a feature that applies to each MSI package at the time it is installed.
The other problem I have is that I wanted to specify processes that wouldn't normally be detected by Windows Installer. See https://stackoverflow.com/questions/20561990/how-to-solve-the-specified-service-has-been-marked-for-deletion-error for details. I solved this problem by adding a custom kill-process action to one of my MSI packages. It would have nice to have a feature where I could just specify a list of image names and let the suite handle it.
One of the reasons I was confused was that I was expecting a feature that allowed me to terminate selected processes at the start of the suite install and optionally restart them at the end instead of a feature that applies to each MSI package at the time it is installed.
The other problem I have is that I wanted to specify processes that wouldn't normally be detected by Windows Installer. See https://stackoverflow.com/questions/20561990/how-to-solve-the-specified-service-has-been-marked-for-deletion-error for details. I solved this problem by adding a custom kill-process action to one of my MSI packages. It would have nice to have a feature where I could just specify a list of image names and let the suite handle it.
‎Apr 09, 2014
07:46 AM
On the surface, this sounds like it could be a reasonable request for a package operation setting to kill processes of the specified names (per operation so you could kill different processes at install or removal, etc.).
But I've always seen killing tasks as a crude instrument, and I'm reluctant to implicitly encourage such a large sledgehammer. The easier it is to use, the more likely it is to be misused, especially if there's a better answer that's harder to implement. I'll have to think about this one some more.
But I've always seen killing tasks as a crude instrument, and I'm reluctant to implicitly encourage such a large sledgehammer. The easier it is to use, the more likely it is to be misused, especially if there's a better answer that's harder to implement. I'll have to think about this one some more.
‎Apr 09, 2014
01:05 PM
Thanks for considering the possibility of a new feature. While I was researching the subject I found a few hits describing the Windows Installer calls required to do this in an MSI so I'm not the only person to want the functionality.
The other subject I found much more frequently in my search was people asking for ways to stop the MsiRMFilesInUse dialog from appearing. Is there a best practice way to stop the ISRMFilesInUse dialog from appearing?
I will also ask that you consider a feature to provide a similar functionality at the start of the suite install. I am under the impression that suites are intended to do all their UI up front and then install their packages. Having ISRMFilesInUse dialog's pop up for each MSI package seems at odds with this approach. This is a fairly low-priority suggestion as I realize that it may be necessary to perform package-specific UI (one of my suites does).
The other subject I found much more frequently in my search was people asking for ways to stop the MsiRMFilesInUse dialog from appearing. Is there a best practice way to stop the ISRMFilesInUse dialog from appearing?
I will also ask that you consider a feature to provide a similar functionality at the start of the suite install. I am under the impression that suites are intended to do all their UI up front and then install their packages. Having ISRMFilesInUse dialog's pop up for each MSI package seems at odds with this approach. This is a fairly low-priority suggestion as I realize that it may be necessary to perform package-specific UI (one of my suites does).