Visual Studio and the .NET framework make it really easy to create Windows Services. All you have to do is create a new project, select ‘Windows Service’ as your project type and you’re all set. However, debugging Windows Services in Visual Studio can be a big pain. The recommended way is to use InstallUtil to install them, and then restart the service and attach the debugger everytime you want to debug it. I wanted Windows Live! Bot to be available as a Windows Service, but I also wanted to be able to debug it without the hassle, so here’s what I came up with:
using
System;
using
System.ServiceProcess;
public
partial
class
DemoService : ServiceBase
{
static
void
Main(
string
[] args)
{
DemoService service
=
new
DemoService();
if
(Environment.UserInteractive)
{
service.OnStart(args);
Console.WriteLine(
"
Press any key to stop program
"
);
Console.Read();
service.OnStop();
}
else
{
ServiceBase.Run(service);
}
}
public
DemoService()
{
InitializeComponent();
}
protected
override
void
OnStart(
string
[] args)
{
//
TODO: Add code here to start your service.
}
protected
override
void
OnStop()
{
//
TODO: Add code here to perform any tear-down
//
necessary to stop your service.
}
}
This will allow you to use your program as either a normal console program or a windows service, with no special builds, #DEBUG directives, command line parameters or anything like that. What it does is in the Main method it checks the ‘Environment.UserInteractive’ property. This will be true when it is run from Visual Studio, or when you just click on the .exe file, but false if it’s being run as a service. When it’s run from Visual Studio or as a standalone program it will keep running until you press a key, then it will call your OnStop method and then terminate.
Two things to watch out for:
Reader Anderson Imes (who has a rather nice debugging solution of his own) pointed out some things to fix. One thing is that a Windows Service can run many services in the same process, the ServiceBase.Run method can take an array of ServiceBase objects. I still think that the code above is the best way to do it if you have just a single service, just keep the Main method in the service class. But if you’ve got multiple service objects then that doesn’t make sense anymore, we want to put our Main method somewhere else. And then we have the problem of not being able to call OnStart in the service objects, since it’s a protected method. We could define a public StartConsole method in all of them that calls the OnStart method like I described above, but that will get tiresome if you have many objects. Well, there is another way to do it with Reflection which I´ve written here below. The new code is basically the same as the first version, except that it has an array of ServiceBase objects, called servicesToRun, and loops through it, calling each object’s OnStart method through some neat Reflection tricks. When the user presses a button it will stop all services by calling their Stop method, which in turn calls the OnStop method that all Services must define.
using
System.ServiceProcess;
using
System;
using
System.Reflection;
static
class
Program
{
static
void
Main(
string
[] args)
{
ServiceBase[] servicesToRun
=
new
ServiceBase[] {
new
Service1()
,
new
Service2()
,
new
Service3()};
if
(Environment.UserInteractive)
{
Type type
=
typeof
(ServiceBase);
BindingFlags flags
=
BindingFlags.Instance
|
BindingFlags.NonPublic;
MethodInfo method
=
type.GetMethod(
"
OnStart
"
, flags);
foreach
(ServiceBase service
in
servicesToRun)
{
method.Invoke(service,
new
object
[] { args });
}
Console.WriteLine(
"
Press any key to exit
"
);
Console.Read();
foreach
(ServiceBase service
in
servicesToRun)
{
service.Stop();
}
}
else
{
ServiceBase.Run(servicesToRun);
}
}
}
While using this trick has worked perfectly well for my services, which have all been pretty simple, it might not work for everyone. I’m sure there are a few things different between Windows Services and console programs that I don’t know about, and might make the console version of the program behave strangely in some cases. Imes also pointed out that there was no way to test pause-and-resume in the console version. The best way I could think of to mimic service events like these would be to read in keypresses in the main thread and do the appropriate action depending on the key pressed. For instance, instead of the “Press any key to exit” message, we might have “Press p to pause, r to resume, s to stop” and then the result of Console.Read() could be used to determine which action to take and which methods to call on the Service objects. However, I don’t have the time and interest to do it right now, so implementing it is left as an exercise for the reader .
from:http://tech.einaregilsson.com/2007/08/15/run-windows-service-as-a-console-program/