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

7
votes

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?

2
wix
The first check would be to see how long it takes for your service to stop. If it doesn't stop in a timely fashion you need to look at that first. – Stein Åsmul
The service stopping in a timely fashion is not the problem - no attempt is being made to stop the service before the upgrade proceeds when I have used the specified condition on DeleteServices. – 0E322070
Hi @snae, did you find a solution for this in the meantime? – Peter van Kekem
@PetervanKekem, nope afraid not. I'm no longer working on this product so not sure if it as ever achieved. I do work now on another product that also has a service that requires upgrading, but in this case we don't care about it being removed before re-installed. Sorry I can't be of more help. – 0E322070
Alright, thanks! I've got the following (temporary) solution: while upgrading, the setup will ask for permission to stop the service. Not the nicest solution, but at least the service is not uninstalled. – Peter van Kekem

2 Answers

1
votes

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.

0
votes

This should just work (putting aside the Delete for now), but without knowing where you have the RemoveExistingProducts action for your upgrade it's not clear what's going on, especially if you are adding conditions and your StopService isn't working for some reason. However what's the issue with DeleteServices? If the service isn't running anyway the momentary effect on the system is minimal. Are you trying to preserve something about the service that was added later, like an account? If that is what you're doing there is an issue because repair probably fails.

Anyway, if your REP is at the end, then the simplified sequence of events as it applies to your service is something like:

Incoming install stops the old service, deletes the service, installs any updated files, installs the service again and starts the new service.

The REP afterwards stops the service, doesn't delete it because it's ref counted, then starts it. But there is one momentary delete, so the issue is why the stop doesn't work, and the question is what's so bad about the delete?