Microsoft SQL Server, Exchange Server, Internet Information Server (IIS), and antivirus software all use Windows Services to perform tasks in response to events that occur on the system overall. Only a background service, or Windows Service, that runs no matter which user is logged in, could perform such operations. For example, consider these potential Windows Services:

To properly design and develop a Windows Service, it is important to understand how it differs from a typical Windows program. Here are the most important characteristics of a Windows Service:

You can view the services that are used on your computer by opening the Service Control Manager user interface. To do so in Windows 2000, select Administrative Tools

Figure 33.1. Figure 33-1

The Status column indicates the current state of the service. If this column is blank, then the service has not been started since the last time the computer was booted. Other possible values for Status are Started, Stopped, and Paused. You can access additional settings and details concerning a service by double-clicking it.

When a service is started, it automatically logs into the system using either a user or a system account:

The Service Control Manager shown in Figure 33-1 is part of the operating system (OS), which is what supports Windows Services; it is not a part of the .NET Framework. Any service run by the OS is exposed through the Service Control Manager, regardless of how the service was created or installed. You can also interact with Windows Services via the Server Explorer in Visual Studio 2008. You will see this technique later.

Prior to the release of the .NET Framework, most Windows Services were created with C++. Third-party toolkits were available to enable Windows Services to be created in VB6 and earlier, but deployment problems and threading issues meant that few developers took this route.

In .NET, the functionality needed to interface to the operating system is wrapped up in the .NET Framework classes, so any .NET-compliant language can now be used to create a Windows Service.

Now it is time to create and use a Windows Service with Visual Basic, using the previously discussed .NET Framework classes. These tasks are demonstrated later in a detailed example. Here is a high-level description of the necessary tasks:

You can also start a service from the command console if the proper paths to .NET are set. The command is NET START <servicename>. Note that the <servicename> used in this command is the name of the service, not the name of the executable in which the service resides. Depending on the configuration of your system, a service started with any of the aforementioned methods will sometimes fail, resulting in an error message indicating that the service did not start in a timely fashion. This may be because the .NET libraries and other initialization tasks did not finish fast enough to suit the Service Control Manager. If this happens, attempt to start the service again; it usually succeeds the second time.

At this point, a service is installed and running. The Service Manager or the Server Explorer can stop the service, or it will be automatically stopped when the system is shut down. The command to stop the service in a command console is NET STOP <servicename>.

The service does not automatically start the next time the system is booted unless it is configured for that. This can be done by setting the StartType property for the service to Automatic when developing the service, or it can be done in the Service Manager. Right-clicking the service in the Service Manager provides access to this capability.

This process is superficially similar to doing most other Visual Basic projects. There are a few important differences, however:

To illustrate the outlined steps, the following example creates a simple service that checks the value of a performance counter, and when the value of the counter exceeds a certain value, the service beeps every three seconds. This is a good example for stepping through the process of creating, installing, and starting a Windows Service. It contains very little logic, and you can easily tell when it is working.

In the first phase of the example, you create a service that always beeps. Then, in the second phase, you add logic to monitor the performance counter and only beep when the counter exceeds a specific value:

Installing the service

Now you are ready to install the service. The utility for doing this, InstallUtil.exe, must be run from a command line. It is located in the .NET utilities directory, found at C:WINNTMicrosoft.NETFrameworkv2.0.50727 on Windows 2000 and NT systems, or C:WindowsMicrosoft.NETFrameworkv2.0.50727 on Windows XP, Windows Vista, Windows Server 2003, and Windows Server 2008.

You can easily access this utility (and all the other .NET utilities in that directory) using an option from the Programs menu that is installed with Visual Studio 2008. Choose Microsoft Visual Studio 2008

InstallUtil CounterMonitor.exe

Check the messages generated by InstallUtil.exe to ensure that the installation of the service was successful. The utility generates several lines of information; if successful, the last two lines are as follows:

The Commit phase completed successfully.

The transacted install has completed.

If these two lines do not appear, then you need to read all the information generated by the utility to find out why the install didn't work. Reasons might include a bad pathname for the executable, or trying to install the service when it is already installed (it must be uninstalled before it can be reinstalled), as described later.

Starting the service

Later in this chapter, you will create your own "control panel" screen to start and stop the service. For now, to test the new Windows Service, you will use the Server Explorer in Visual Studio 2008. Open the Server Explorer in Visual Studio 2008 and expand the Services node. The resulting screen is shown in Figure 33-4.

Figure 33.4. Figure 33-4

If the CounterMonitor service does not appear in the list, then the installation failed. Try the installation again and check the error messages. Right-click the CounterMonitor service and select the Start menu option. You will hear the service beep every three seconds. You can stop the service by right-clicking it again and selecting the Stop menu option.

You can also use the Service Control Manager built into Windows to start the CounterMonitor service, shown in Figure 33-5.

Figure 33.5. Figure 33-5

Start CounterMonitor by right-clicking it and selecting Start or by clicking the Start link. As before, you will hear your computer beep every three seconds. Stop the service by right-clicking CounterMonitor and selecting Stop or by clicking the Stop link. Note that if you already started the service via the Server Explorer (as described earlier), then it will be in a started state when you access the Service Control Manager program.

InstallUtil.exe /u CounterMonitor.exe

Service CounterMonitor was successfully removed from the system.

Performance counters are a system-level function of Windows. They are used to track usage of system resources. Performance counters can be expressed as counts (number of times a Web page was hit), percentages (how much disk space is left), or other types of information. Many counters are automatically maintained by the operating system, but applications can create and manage their own performance counters.

To demonstrate how services can interact with system-level functionality, you will add to the CounterMonitor the capability to monitor a particular performance counter, and only beep when the performance counter exceeds a certain value.

Performance counters can be monitored by a user with the Performance Monitor. A variety of performance counters are built into the operating system, providing access to information such as the number of threads currently active on the system, or the number of documents in a print queue. Any of these, and any custom performance counters, can be graphed in the Performance Monitor.

Creating a performance counter

This example creates a performance counter named ServiceCounter. Then you will change CounterMonitor to check that counter and only beep when its value is over 5. To test it, you will also create a small Windows Forms application that increments and decrements the counter.

Performance counters are typically accessed in Visual Studio 2008 through the Server Explorer tab. To see the available performance counters, open the Server Explorer, shown in Figure 33-6.

To see the categories of performance counters, click the plus sign next to the Performance Counters option in the Server Explorer. Several dozen categories will be shown. You can look at the counters in any particular category by clicking the plus sign next to the category.

You can also create new categories and new counters. For this example, you need to create a new category for the counter called Service Counters. To do that, right-click the Performance Counters option in the Server Explorer and select the Create New Category option. In the resulting Performance Counter Builder dialog box (shown in Figure 33-7), enter the name of the category as Service Counters, and create a new counter by clicking the New button and entering TestCounter for the name. Once that is complete, click the OK button. Visual Studio 2008 will then create a new category called Service Counters that contains a single performance counter called TestCounter.

Figure 33.6. Figure 33-6

Integrating the counter into the service

Using a performance counter in the CounterMonitor service you created earlier is straightforward. Open the CounterMonitor project and go to the design surface for CounterMonitor. Then open the Server Explorer so that it shows the TestCounter performance counter you created. Click TestCounter from within the Server Explorer and drag it onto the CounterMonitor.vb design surface.

A new visual control named PerformanceCounter1 will appear on the page's design surface, ready for use. Change the logic in the Elapsed event for Timer1 as shown here:

If PerformanceCounter1.RawValue > mnMaxValue Then
    Beep()
End If

Figure 33.7. Figure 33-7

The RawValue property being used in this code fetches the unformatted value of the counter. For counters that track whole numbers (such as the number of times a Web page is hit), the RawValue property is normally used to get the value of the counter for testing or display. Some other types of counters use a NextValue method to get a formatted value. See the CounterType property of the PerformanceCounter class for more information on the types of performance counters available.

Next, put this statement in the code module just under the first line of the CounterMonitor class:

Dim mnMaxValue As Integer = 5

This creates the mnMaxValue as a Private variable. Now build the service again, install it as before, and start the service. It should not beep at this point because the value in the performance counter is zero. You can leave the counter running, because you will now create a program to change the value in the performance counter, thereby making the service begin beeping.

Changing the value in the performance counter

To manipulate the performance counter, you will build a small forms-based application. Close the CounterMonitor solution in Visual Studio and start a new Windows Application Project named CounterTest. Place two buttons on Form1 and change their properties as shown in the following table:

Name	Text
BtnIncrement	Increment Counter
BtnDecrement	Decrement Counter

Then, open the Server Explorer and drag the TestCounter performance counter onto the form itself, just as you did earlier with the CounterMonitor project. As with all nonvisible components from the Toolbox, the counter will appear in the component tray (just under the form), rather than on the form's design surface.

The PerformanceCounter1 control for CounterTest needs one property change. Set the ReadOnly property of the control to False. This enables the application to manipulate the counter. (This change was unnecessary for the CounterMonitor Windows Service project because that project only reads the value of the performance counter and does not change it.)

Now double-click btnIncrement to get to its click event. Place the following code in the event:

PerformanceCounter1.Increment()

Double-click the btnDecrement to get to its click event. Place the following code in the event:

PerformanceCounter1.Decrement()

Build and run the program and click the Increment button six times. If the CounterMonitor service is running, then on the sixth click it will begin beeping because the value in the counter has exceeded five. Then click the Decrement button a couple of times, and the beeping will stop.

If you want to monitor the current value of the counter, select Start

Up to this point, you have learned how to do the following:

If these procedures are sufficient to start, stop, and check on the service through the Server Explorer or the Service Control Manager, and there is no need for any other communication with the service, then this is all you have to do. However, it is often helpful to create a specialized application to manipulate your service. This application will typically be able to start and stop a service, and check on its status. The application may also need to communicate with the service to change its configuration. Such an application is often referred to as a control panel for the service, even though it does not necessarily reside in the operating system's Control Panel. A commonly used example of such an application is the SQL Server Service Manager, whose icon appears in the tray on the taskbar (normally in the lower-right section of the screen) if you have SQL Server installed.

Such an application needs a way to communicate with the service. The .NET Framework base class that is used for such communication is ServiceController. It is in the System.ServiceProcess namespace. You need to add a reference to System.ServiceProcess.dll (which contains this namespace) before a project can use the ServiceController class.

The ServiceController class provides an interface to the Service Control Manager, which coordinates all communication with Windows Services. However, you do not have to know anything about the Service Control Manager to use the ServiceController class. You just manipulate the properties and methods of the ServiceController class, and any necessary communication with the Service Control Manager is accomplished on your behalf behind the scenes.

It is a good idea to use exactly one instance of the ServiceController class for each service you are controlling. Multiple instances of ServiceController that are communicating with the same service can have timing conflicts. Typically, that means using a module-level object variable to hold the reference to the active ServiceController, and instantiating the ServiceController during the initialization logic for the application. The following example uses this technique.

Dim sStatus As String
myController.Refresh()
sStatus = myController.Status.ToString

MsgBox(myController.ServiceName & " is in state: " & sStatus)

Try
    myController.Start()
Catch exp As Exception
    MsgBox("Could not start service or the service is already running")
End Try

If myController.CanStop Then
    myController.Stop()
Else
    MsgBox("Service cannot be stopped or the service is already stopped")
End If

Some services need additional operations besides starting and stopping. For example, for the CounterMonitor Windows Service, you might want to set the threshold value of the performance counter that causes the service to begin beeping, or you might want to change the interval between beeps.

With most components, you would implement such functionality through a public interface. That is, you would put public properties and methods on the component. However, you cannot do this with a Windows Service because it has no public interface that you can access from outside the service.

To deal with this need, the interface for a Windows Service contains a special event called OnCustomCommand. The event arguments include a numeric code that can serve as a command sent to the Windows Service. The code can be any number in the range 128 to 255. (The numbers under 128 are reserved for use by the operating system.)

To fire the event and send a custom command to a service, the ExecuteCommand method of the ServiceController is used. The ExecuteCommand method takes the numeric code that needs to be sent to the service as a parameter. When this method is accessed, the ServiceController class tells the Service Control Manager to fire the OnCustomCommand event in the service, and to pass it the numeric code.

The next example demonstrates this process in action. Suppose you want to be able to change the interval between beeps for the CounterMonitor service. You cannot directly send the beep interval that you want, but you can pick various values of the interval, and associate a custom command numeric code with each.

For example, assume you want to be able to set intervals of 1 second, 3 seconds (the default), or 10 seconds. You could set up the following correspondence:

The correspondences in the table are completely arbitrary. You could use any codes between 128 and 255 to associate with the beep intervals. These were chosen because they are easy to remember.

First, you need to change the CounterMonitor service so that it is able to accept the custom commands for the beep interval. To do that, first make sure the CounterMonitor service is uninstalled from any previous installs. Then open the Visual Studio 2008 project for the CounterMonitor service.

Create an OnCustomCommand event in the service: Open the code window for CounterMonitor.vb and type Protected Overrides OnCustomCommand. By this point, IntelliSense will kick in and you can press the Tab key to autocomplete the shell event. Notice how it only accepts a single Integer as a parameter:

Protected Overrides Sub OnCustomCommand(ByVal command As Integer)

End Sub

In the OnCustomCommand event, place the following code:

Timer1.Enabled = False
Select Case command
    Case 201
        Timer1.Interval = 1000
    Case 203
        Timer1.Interval = 3000
    Case 210
        Timer1.Interval = 10000
End Select
Timer1.Enabled = True

Build the countermonitor service, reinstall it, and start it.

Now you can enhance the CounterTest application created earlier to set the interval. To enable users to pick the interval, you will use radio buttons. On the CounterTest program Form1 (which currently contains five buttons), place three radio buttons. Set their text labels as follows:

RadioButton1 - 1 second
RadioButton2 - 3 seconds
RadioButton3 - 10 seconds

Place a button directly under these option buttons. Name it btnSetInterval and set its text to Set Interval. In the click event for this button, place the following code:

Dim nIntervalCommand As Integer = 203
If RadioButton1.Checked Then
    nIntervalCommand = 201
End If
If RadioButton2.Checked Then
    nIntervalCommand = 203
End If
If RadioButton3.Checked Then
    nIntervalCommand = 210
End If
myController.ExecuteCommand(nIntervalCommand)

At this point, Form1 should look something like the screen shown in Figure 33-8.

Figure 33.8. Figure 33-8

Start the CounterTest control program and test the capability to change the beep interval. Make sure the performance counter is high enough that the CounterMonitor service beeps, and remember that every time you stop and restart the service, it resets the beep interval to three seconds.

Because the OnCustomCommand event only takes numeric codes as input parameters, you cannot directly pass strings to the service. For example, if you wanted to reconfigure a directory name for a service, you could not just send the directory name over. Instead, it would be necessary to place the information to be passed to the service in a file in some known location on disk. Then a custom command for the service could instruct it to look at the standard file location and read the information in the file. What the service did with the contents of the file would, of course, be customized for the service.

Now let's step through another example to illustrate what a Windows Service can do and how to construct one. You will build a service that monitors a particular directory and reacts when a new or changed file is placed in the directory. The example Windows Service application waits for those files, extracts information from them, and then logs an event to a system log to record the file change.

As before, create a Windows Service from the built-in template named Windows Service in the New Project screen. Name the new project FileWatcherService and click OK. This creates a new service class called Service1.vb. Rename this to FileWatcherService.vb. Right-click the design surface, select Properties, and set the ServiceName property to FileWatcherService.

As in the first example, set the application type to Windows Service and reset the project's start object to FileWatcherService. All of this is illustrated earlier in this chapter.

Writing events using an Event Log

The way to ensure that the service is doing its job is by having it write events to a system Event Log. Event Logs are available under the Windows operating system. As with many other system-level features, the use of Event Logs is simplified in .NET because a .NET Framework base class does most of the work for you.

There are three Event Logs on the system: Application, Security, and System. Normally, your applications should only write to the Application log. A property of a log entry called Source identifies the application writing the message. This property does not have to be the same as the executable name of the application, but it is often given that name to make it easy to identify the source of the message.

You can look at the events in the Event Log by using the Event Viewer. Select Control Panel

It was mentioned earlier in the chapter that the AutoLog property of the ServiceBase class determines whether the service automatically writes events to the Application log. The AutoLog property instructs the service to use the Application Event Log to report command failures, as well as information for OnStart, OnStop, OnPause, and OnContinue events on the service. What is actually logged to the Event Log is an entry indicating whether the service started successfully and stopped successfully, and any errors that might have occurred. If you look in the Application Event Log now, these events are logged for the CounterMonitor Windows Service that you created and ran earlier in the chapter.

You can turn off Event Log reporting by setting the AutoLog property to False in the Properties window for the service, but leave it set to True for this example. That means some events will be logged automatically (without you including any code for them). Then, you add some code to the service to log additional events not covered by the AutoLog property. First, though, you need to implement a file monitoring control in the project.

Creating a FileSystemWatcher

For performance reasons, you should do all of your work on a separate thread to your main application thread. You want to leave your main application free to accept any requests from the user or the operating system. You can do this by using some of the different components that create their own threads when they are launched. The Timer component and the FileSystemWatcher component are two examples. When the Timer component fires its Elapsed event, a thread is spawned and any code placed within that event will work on that newly created thread. The same thing happens when the events for the FileSystemWatcher component fire.

You can learn more about threading in .NET in Chapter 26.

The FileSystemWatcher Component

The FileSystemWatcher component is used to monitor a particular directory. The component implements Created, Changed, Deleted, and Renamed events, which are fired when files are placed in the directory, changed, deleted, or renamed, respectively.

The operation that takes place when one of these events is fired is determined by the application developer. Most often, logic is included to read and process the new or changed files. However, you are just going to write a message to a log file.

To implement the component in the project, drag and drop a FileSystemWatcher control from the Components tab of the Toolbox onto the designer surface of FileWatcherService.vb. This control is automatically called FileSystemWatcher1.

The EnableRaisingEvents Property

The FileSystemWatcher control should not generate any events until the service is initialized and ready to handle them. To prevent this, set the EnableRaisingEvents property to False. This prevents the control from firing any events. You will enable it during the OnStart event in the service. These events fired by the FileSystemWatcher are controlled using the NotifyFilter property, discussed later.

The Path Property

The path that you want to monitor is the TEMP directory on the C: drive, so set the Path property to C:TEMP (be sure to confirm that there is a TEMP directory on your C: drive). Of course, this path can be changed to monitor any directory depending on your system, including any network or removable drives.

The NotifyFilter Property

You only want to monitor when a file is freshly created or the last modified value of a file has changed. To do this, set the NotifyFilter property to FileName, LastWrite. You could also watch for other changes such as attributes, security, size, and directory name changes as well, just by changing the NotifyFilter property. Note that you can specify multiple changes to monitor by including a comma-separated list.

The Filter Property

The types of files that you will look for are text files, so set the Filter property to .txt. Note that if you were going to watch for all file types, then the value of the Filter property would be set to *.*.

The IncludeSubdirectories Property

If you wanted to watch subdirectories, you would set the IncludeSubdirectories property to True. This example leaves it as False, which is the default value. Figure 33-9 shows how the properties should be set.

Figure 33.9. Figure 33-9

Adding FileSystemWatcher Code to OnStart and OnStop

Now that some properties are set, let's add some code to the OnStart event. You want to start the FileSystemWatcher1 component so it will start triggering events when files are created or copied into the directory you are monitoring, so set the EnableRaisingEvents property to True:

Protected Overrides Sub OnStart(ByVal args() As String)
    ' Start monitoring for files
    FileSystemWatcher1.EnableRaisingEvents = True
End Sub

After the file monitoring properties are initialized, you are ready to start the monitoring. When the service stops, you need to stop the file monitoring process. Add the following code to the OnStop event:

Protected Overrides Sub OnStop()
    ' Stop monitoring for files
     FileSystemWatcher1.EnableRaisingEvents = False
End Sub

The EventLog Component

Now you are ready to place an EventLog component in the service to facilitate logging of events. Drag and drop an EventLog control from the Components tab of the Toolbox onto the designer surface of FileWatcherService.vb. This control is automatically called EventLog1.

Set the Log property for Eventlog1 to Application, and set the Source property to FileWatcherService.

The Created Event

Next, you will place some logic in the Created event of the FileSystemWatcher component to log when a file has been created. This event fires when a file has been placed or created in the directory that you are monitoring. It fires because the information last modified on the file has changed.

Select FileSystemWatcher1 from the Class Name drop-down list and select Created from the Method Name drop-down list. The Created event will be added to your code. Add code to the Created event as follows:

Public Sub FileSystemWatcher1_Created(ByVal sender As Object, _
           ByVal e As System.IO.FileSystemEventArgs) _
           Handles FileSystemWatcher1.Created

     Dim sMessage As String
     sMessage = "File created in directory - file name is " + e.Name
     EventLog1.WriteEntry(sMessage)
End Sub

Notice that the event argument's object (the object named "e" in the event parameters) includes a property called Name. This property holds the name of the file that generated the event.

At this point, you could add the other events for FileSystemWatcher (Changed, Deleted, Renamed) in a similar way and create corresponding log messages for those events. To keep the example simple, you will just use the Created event in this service.

You need to add an Installer class to this project to install the application. This is done as it was in the CounterMonitor example, by right-clicking the design surface for the service and selecting Add Installer or by clicking the Add Installer link in the Properties window of Visual Studio 2008. Don't forget to change the Account property to LocalSystem, or set it to User and fill in the Username and Password properties.

As before, you must install the service using InstallUtil.exe. Then, start it with the Server Explorer or the Service Manager. Upon successful compilation of these steps, you will get a message logged for any file with a .txt extension that you copy or create in the monitored directory. After dropping some sample text files into the monitored directory, you can use the Event Viewer to ensure that the events are present.

Figure 33-10 shows the Event Viewer with several example messages created by the service. If you right-click one of the events for FileWatcherService, you will see a detail screen. Notice that the message corresponds to the Event Log message you constructed in the Created event of the FileSystemWatcher control in the service, as shown in Figure 33-11.

Figure 33.10. Figure 33-10

Because a service must be run from within the context of the Service Control Manager, rather than from within Visual Studio 2008, debugging a service is not as straightforward as debugging other Visual Studio 2008 application types. To debug a service, you must start the service and then attach a debugger to the process in which it is running. You can then debug the application using all of the standard debugging functionality of Visual Studio 2008.

Figure 33.11. Figure 33-11

To avoid going through this extra effort, you may want to test most of the code in your service in a standard Windows Forms application. This test-bed application can have the same components (FileSystemWatchers, EventLogs, Timers, and so on) as the Windows Service, and thus will be able to run the same logic in events. Once you have checked out the logic in this context, you can just copy and paste it into a Windows Service application.

However, sometimes the service itself needs to be debugged directly, so it is important to understand how to attach to the service's process and do direct debugging. You can only debug a service when it is running. When you attach the debugger to the service, you are interrupting it. The service is suspended for a short period while you attach to it. It is also interrupted when you place breakpoints and step through your code.

Attaching to the service's process enables you to debug most, but not all, of the service's code. For instance, because the service has already been started, you cannot debug the code in the service's OnStart method this way, or the code in the Main method that is used to load the service. To debug the OnStart event or any of the Visual Studio 2008 designer code, you have to add a dummy service and start that service first. In the dummy service, you would create an instance of the service that you want to debug. You can place some code in a Timer object and create the new instance of the object that you want to debug after 30 seconds or so. Allow enough time to attach to the debugger before the new instance is created. Meanwhile, place breakpoints in your startup code to debug those events, if desired.

Follow these steps to debug a service:

Let's go through an actual scenario, using your earlier CounterMonitor example. Bring up both the CounterMonitor project and the CounterTest project in separate instances of the Visual Studio 2008 IDE. Make sure that the CounterMonitor service has been started. It is best if you hear it beeping — that way you know it is working. If necessary, increment the performance counter to make it beep.

In the CounterMonitor project, select Debug

You will then get a dialog box asking you what program types you are interested in debugging. Because you are working solely within .NET, check the box next to Common Language Runtime and leave the rest unchecked. Click the OK button, and then click the Close button on the Processes dialog box. You are now attached to the process running CounterMonitor in the background.

Place a breakpoint on the first line of the OnCustomCommand event:

Timer1.Enabled = False

Now you are ready to check debugging. Bring up the CounterTest program and start it. Press one of the radio buttons to change the beep interval. You will hear the beeping stop because CounterMonitor.exe has entered debugging mode. Switch back to the CounterMonitor project. The cursor will be on the breakpoint line in OnCustomCommand. You can use the normal commands at this point to step through the code.

This chapter presented a general overview of what a Windows Service is and how to create one with Visual Basic. The techniques in this chapter can be used for many different types of background service, including the following:

While Visual Basic cannot be used to create every type of Windows Service, it is effective at creating many of the most useful ones. The .NET Framework classes for Windows Services make this creation relatively straightforward. The designers generate much of the routine code needed, enabling you, as a developer, to concentrate on the code that is specific to your particular Windows Service.