Creating a Windows Service in Visual Basic

Here is a summary description of the necessary tasks to create a Windows Service. These tasks are demonstrated later in a detailed example:

1. Create a new project of the type Windows Service. By default, the service will be in a module named Service1.vb, but it can be renamed, like any other .NET module. The class automatically placed in Service1.vb is named Service1 by default, and it inherits from the ServiceBase class.
2. Place any logic that needs to run when the service is started in the OnStart event of the service class. You can find the code listing for the Service1.vb file by double-clicking this file's design surface.
3. Add any additional logic that the service needs to carry out its operation. Logic can be placed in the class for the service, or in any other class module in the project. Such logic is typically called via some event that is generated by the operating system and passed to the service, such as a file changing in a directory, or a timer tick.
4. Add an installer to the project. This module provides the interface to the Windows operating system to install the module as a Windows Service. The installer is a class that inherits from System.Configuration.Install.Installer, and it contains instances of the ServiceProcessInstaller and ServiceInstaller classes.
5. Set the properties of the installer modules as necessary. The most common settings needed are the account under which the service will run and the name the service will display in the Service Control Manager.
6. Build the project. This results in an .exe file. For example, if the service were named WindowsService1, then the executable file would be named WindowsService1.exe.
7. Install the Windows Service with a command-line utility named InstallUtil.exe. (As previously mentioned, a service cannot be started by just running the .exe file.)
8. Start the Windows Service with the Service Control Manager or with the Server Explorer in Visual Studio.

You can also start a service from the command console if the proper paths to .NET are set. The command is as follows:

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; if it has no actual defects, it usually succeeds the second time.

Note
Steps 2 through 5 can be done in any order. It doesn't matter whether the installer is added and configured before or after the logic that does the processing for the service is added.

At this point, a service is installed and running. The Service Control Manager 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 as follows:

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.

Developing a Windows Service project is similar to most other Visual Basic projects. There are a few important differences, however:

  • Even though the result of the development is an .exe file, you should not include any message boxes or other visual elements in the code. A Windows Service executable is more like a component library in that sense, and should not have a visual interface. If you include visual elements such as message boxes, the results can vary. In some cases, the UI code will have no effect. In other cases, the service may hang when attempting to write to the user interface.
  • You cannot debug the project in the environment as you normally would with any other Visual Basic program. Most important, it is possible to run your application code interactively in a test harness prior to deployment. However, to fully test the service it must be installed and started as a service. In that scenario the debugger is automatically available. To debug a running service you need to attach to the process of the service to do debugging. Details about this are included in the section “Debugging the Service.”
  • Finally, be especially careful to handle all errors within the program. The program is not running in a user context, so a runtime error has no place to report itself visually. Handle all errors with structured exception handling, and use a Trace file, Event Log, or other persistent storage to record runtime errors.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset