views:

447

answers:

3

Problem

I have an MSI that creates and starts a Windows service during installation and stops and removes the service during uninstallation. This works fine when installing and uninstalling by itself, but when upgrading, the Files in Use dialog is displayed (only on Vista and later due to the new Restart Manager), indicating that the service is in use.

Background

The Files in Use dialog is displayed during the InstallExecute sequence by the InstallValidate custom action, which is scheduled immediately before the RemoveExistingProducts custom action; this means that the previous version has not been uninstalled yet, so the Files in Use dialog should be shown.

The MSDN documentation indicates that the RemoveExistingProducts action must be scheduled after the InstallValidate action, and I currently have the RemoveExistingProducts actions scheduled immediately after the InstallValidate action.

Potential Solution

I would like to reschedule the RemoveExistingProducts custom action to immediately before the InstallValidate custom action so that the previous installation has a chance to stop and remove the service before the Files in Use dialog is shown. I tried rescheduling the actions, and it appears to work correctly with no adverse side-effects (although the log still indicates that the InstallValidate action executes before the RemoveExistingProducts action), but I'm hesitant to use this solution since it violates the MSDN documentation, and there may be adverse effects that I'm just not seeing yet.

Has anyone tried this? The only other alternative I can think of is to have the new installation stop the service of the old installation, but this is undesirable because it requires the installation to have information about all old installations that it can upgrade (stopping this particular service may involve more than just a simple call to the Service Manager to stop it).

A: 

One potential problem would be that if the user cancels during InstallValidate (e.g. due to not enough disk space or a file in use) or during the installation, what is the rollback behavior. The ideal situation is that the application state is the same as it was before (e.g. the previous application is installed). You might be giving that up with your sequencing, although rollback may be a feature you can live without.

Edward Brey
It's strange, but I've observed (by monitoring the installation dialogs and looking at the log) that the **InstallValidate** action still appears to be executed before the **RemoveExistingProducts** action even though they're scheduled in the opposite order; scheduling them this way does solve my problem, though, even if I can't explain the behavior. Also, in the scenarios I tested, the rollback still functioned correctly. I'll have to test it more carefully based on your suggestion.
CodeSavvyGeek
A: 

I implemented the potential solution outlined in the question, scheduling RemoveExistingProducts immediately before InstallValidate. I haven't seen any problems yet, but I will post again after the installation gets more use.

Update

Our installation has been using this for some time, and I haven't noticed any ill effects.

CodeSavvyGeek
A: 

when I do major upgrade, I had to RemoveExistingProducts, by default it will remove all the data of previous version include user data in local setting. we really want to keep these data. how to do this, can you modify the default behavior of RemoveExistingProducts. Many Thanks

Frank
This is not an answer to this question. Please post this as a new question instead.
CodeSavvyGeek

related questions