Prevent service removal/install during WiX major upgrade - service not stopping

Question

I have what is I imagine a common scenario, but am having trouble getting things working completely.

The scenario is quite simple, I would like to perform a major upgrade of a product, without changing the service settings and without requiring a reboot.

• On a normal install, the service should install and start
• On an uninstall the service should stop and be removed
• On an upgrade the service should be stopped (not removed), new files written, and the service started again

I have this mostly working by using the condition NOT UPGRADINGPRODUCTCODE on DeleteServices. However, the service is not being stopped during the upgrade and therefore a reboot is required.

Is there some way on an upgrade to stop a service, install the new files and restart the service without removing/installing the service?

Answer 1

Have you enabled the wait flag for windows installer to wait for the service to stop correctly? http://msdn.microsoft.com/en-us/library/aa371634(v=vs.85).aspx . Even with this flag enabled, your service must stop within 30 seconds or the major upgrade proceeds. There are ways to implement your own delay to give it more time, but don't do that if it is not necessary. Essentially this could just be a custom action with some code that implements a delay as specified in a custom property in the property table.

Note that the NOT UPGRADINGPRODUCTCODE on DeleteServices may appear to be without side effects, but what can happen is that a major upgrade will not delete a service that is scheduled for uninstall as part of the upgrade. In other words you have deleted a service, perhaps added a new one and the old one won't get uninstalled correctly. Messing with standard Windows Installer actions like this is not best practice, and will almost certainly have unexpected side effects. You paint yourself into a corner for later updates when fighting Windows Installer.

If I were you I would rather split the service install in a separate MSI in case it is in a state that is not supposed to be affected by the main install. Then you chain the MSI files together with a bootstrapper. This is very flexible if you need to add new services in the future, or remove older ones. And it is totally vanilla and doesn't fight against the Windows Installer design. This is thinking from a corporate perspective where the issue is to be able to control each service reliably when each one may have very different release schedules. It is probably not what you would prefer if you deliver an installer as a third party product to someone.