The AppLife Update Blog
A complete solution for maintaining deployed software on the Windows platform
For applications that deploy a Windows Service, updating the installed service can present a maintenance challenge. This is a scenario where integrating AppLife Update makes a difficult task extremely easy to accomplish. Using AppLife Update actions, a Windows Service can be updated in three easy steps.
- Stop the Service using a Stop Service update action.
- Replace the Service assemblies using one of the available file replacement actions.
- Restart the Service using a Start Service update action.
Tada! Big maintenance challenge accomplished.
The release of AppLife Update 4.5 included a few very small changes to our AppLife Update Windows Service. Specifically, in previous versions, if the Windows Application Event Log was full and not configured to replace old events, our service would not apply an update. This issue affects a very small number of systems as since Windows Vista, the default logging behavior is to replace old log events when the event log is full, and the event log has to actually be full to cause an issue. For customers who use our AppLife Update Windows Service, if you choose, you can update the AppLife Update Windows Service on your deployed clients during your next application update. This is optional because if the logging issue isn’t a concern, you can leave the previous version alone. Any past version of the elevation service will operate properly with the latest AppLife Update controller. If you do so choose, here is how you can update the AppLife Update Windows Service (or any other Windows Service for that matter).
Stop the Service
To stop the service, we need to know the service name. If you don’t already know the name of the service you are updating, it can be found in the Services manager.
Open your application update project file (.aup). Add a Stop Service action to your update. Set the Service to Stop property to the name of your service. In this case, the service name is KjsUpdateService2.
Replace the Service Assemblies
We use an Add & Replace files on restart action to update the assemblies. The AppLife Update Windows service is initially deployed using an MSI merge module, and is always installed to the Common Files Folder\AppLifeUpdateService2 folder. To update the service, we’ll select the Common Program Files (x86) client folder and set the appropriate sub-directory, and then add the two assemblies that constitute the service. Choosing the x86 variant of the Common Program Files folder will ensure we target the x86 common files folder on x64 operating systems. Using the non x86 Common Program Files directory targets the x64 folder on 64-bit operating systems. On x86 operating systems, there is only one common program files directory, and either variant will target the correct folder.
Note: When updating most Windows Services, even when a service updates itself, the service assemblies can be replaced immediately, without deferring to a restart. The AppLife Update service core assembly houses a class used to marshal information between the User Interface process and the service started worker process. For this reason, even though the service is successfully stopped, a lock is still being maintained on the core service assembly while the update is executed. Because this lock is not released until the update completes, the file replacement is deferred until restart. We do not need to force an operating system restart, as the previous update service can be restarted and function properly until the system is restarted. If a restart were necessary, we could include a Restart Operating System action to accomplish this.
The service assemblies ship with AppLife Update already embedded into the AppLifeUpdateService.msm merge module. After an installation, the assemblies will be in the common program files folder and can be extracted from there. After this action executes, the Windows Service will be updated. Now we just need to restart the service.
Restarting the Service
The service is restarted by adding a Start Service update action. The action is configured by defining the name of the service to restart. In this case it is again, KjsUpdatService2.
That’s it! Windows Service update completed.
But My Service is My Application?
This example assumes an existing update process exists and can be utilized to update the Windows Service. This is usually an installed application that utilizes the Windows Service, and can take responsibility for updating it. A stand-alone Windows Service can become “Self Updating” just as easily by integrating an update process using an AppLife Update controller. There is one point to make in this scenario. When applying an update, you want to use the option to instruct the update controller not to shut down the host application (the service). The Stop Service update action performs a proper service shutdown through the use of the Windows Service Control Manager, and is the recommended method to use when stopping a service for an update.