Technology > Programming > Windows Services

My Introduction to Windows Services

I was asked to develop an application which required a fair bit of data manipulation to produce daily reports which were emailed external to our company. Looking back now I think I could have got away with some nifty T-SQL in a stored procedure called from a SQL Server Job. However, at the time (2004) I was into C# and was wanting to try my hand in other areas where possible.

I learnt how to create Windows Services using Kalani's book for XML Web Services. I have since self-learnt various techniques for making sure the testing and deployment goes according to plan. There's lots that the books don't tell you to look out for.

e.g. the deletion of services is best done

  1. once the service has been stopped using the MMC snap-in for services
  2. following the MMC snap-in has been shut down (tends to prevent problems with reinstallation. Perhaps shutting down clears some cache or other)
  3. by executing the installation exe instead of using add/remove programs (tends to be faster)

Testing and Maintenance of Windows Services

Using .NET WinForms are also a great way of testing out Windows Services. With the bulk of operations handled by C# libraries, it can be convenient to test functionality in response to button clicks or by prompting the user to find a file using the usual dialog. This testing can also be done without the stop/delete/re-installation cycle that services require when things go awry. I'm sure there are other ways of testing Windows Services but WinForms suit me fine for the time being.

I tend to leave in my WinForms project in the Service's solution file and also comment out the test code from the libraries. This approach allows me to come back to a familiar client-driven test environment for any further maintenance.


Examples

1. Process Model Windows Service

Other windows services which I have developed include the running of a process model on a 5 minutely schedule, requiring:

  1. manipulation of real-time data from a data historian
  2. the creation of input text files
  3. the consecutive execution of 2 (3rd party) executables and
  4. the parsing of output text files to write to the real-time data historian.

2. XML Processing from Mobile Device using ActiveSync

Most recently I have used a windows service to pick up and process XML files saved from a mobile device. A low-cost plant trial using mobile devices involved the use of a 3rd party software package for PocketPC. This allowed a customised form to be created prior to proving the devices could supplant the existing paper-based system. This package allowed for manual input and automated export of XML data. Synchronisation via Microsoft ActiveSync allowed for user-friendly saving to a default location. This feature was key to the exploitation of a windows service to further process the data into our MIS.

Following data input, users docked their mobile device and "Synchronised" the data with their PC. The data session(s) were saved directly to a nominated share on the Web Server. The Windows Service picked up these precisely formatted files and processed them into a SQL Server database. The service had to allow for certain mandatory inputs and also the potential for user error (in both data input such as letters where numbers were expected and the configuration of the data export options). The data captured were also subject to calculations, but only once all data had been validated.

Also, operators and managers were mapped to different shares and the service was programmed to differentiate between the share directories and attribute different behaviour. Processing of the files could potentially be done using either the FileSystemWatcher component or using a Timer component. I have found that the former was riddled with inconsistencies, especially in the treatment of multiple file processing. In this application I employed a Timer component and limited the number of files to be processed between controlled occurrences of the Elapsed event.

These types of software described above are more suited to the windows service than any other which I am currently aware of.