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?

Housewifely

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. – Collimator

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. – Housewifely

Hi @snae, did you find a solution for this in the meantime? – Teevens

@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. – Housewifely

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. – Teevens

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.

Min

The service stops within 30 seconds, its been designed explicitly to behave properly with service control commands. The issue is that StopServices is not being called in the scenario I originally described. It does stop on uninstall, so this is not the issue. – Housewifely

Answer 2

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?

Paraphernalia

Several people have asked about the same issue. I guess the problems are mainly lost credentials and poor ref-counting and REP like you indicate. I definitely wouldn't mess with conditioning standard actions. – Collimator

The problem with DeleteServices is as Glytzhkof assumes with preserving service settings through an upgrade. If the service account has been changed then this should be not affected through the upgrade. REP is being done after InstallValidate. Could that be too early in the upgrade scenario? Note that the installer 'works' perfectly if I don't care about preserving service settings - but thats the thing that is important in my scenario. – Housewifely

Try something I suggested: Do a repair of the product after the service credentials have been modified. This repair may well fail because Windows can't reinstall the service, and if it succeeds you may find it has lost the user-supplied credentials. In other words this whole area is messy, and the most reliable option may just be to tell users to re-enter the credentials after upgrading to the new product. It's nor as if this is a daily occurrence, right? – Paraphernalia