//TODONT: Use a Windows Service just to run a scheduled process
A common requirement in business application is a scheduled process - call a webservice, process the data, and FTP the results to a business partner, for instance. Developers kick around possible solutions - BizTalk's overkill, DTS won't handle it well, what to do?
Invariably, someone suggests a Windows Service with a timer. Just as invariably, when you try to talk them out of it, they'll condescendingly tell you that Windows Services are easy to write in .NET. "Trust me, it's not hard - we'll write a simple service with a timer which will do a simple time check..."
A Windows Service is the wrong solution to scheduling one-off custom processes. The right solution for scheduling simple processes is the Windows Task Scheduler.
Let's look at what Windows Services are designed for. From the Windows Help documentation:
Service
A program, routine, or process that performs a specific system function to support other programs, particularly at a low (close to the hardware) level. When services are provided over a network, they can be published in Active Directory, facilitating service-centric administration and usage. Some examples of services are the Security Accounts Manager service, File Replication service, and Routing and Remote Access service.
Web servers qualify as services, databases qualify as services, and the above Windows system features qualify as services. The Task Scheduler qualifies as a service. Possibly, custom server applications may qualify as a service if it needs to run round the clock and is written with the greatest sobriety, responsibility, and respect. Your scheduled file FTP doesn't qualify as a service.
A Windows Service which runs a timer needs to run Automatically, which means it will start up before you can log onto the machine and churn away until the machine is shut down. If they hang or have a slow memory leak, they'll continue to be a drag on the system until the service is restarted (or they crash the machine). I can't tell how many times I've heard the following in production meetings: "The cause of the outage was the WhamoInhouse Service. The resolution was to restart the service." Or, worse, application servers need to be restarted regularly because they're hosting poorly written services, but the IT shop blames the operating system.
Windows Services do offer sophisticated Recovery actions (on first, second, and subsequent failures you can specify that a program to be executed, or that the service or computer be restarted), but they're geared towards hard failures of the executable rather than business process failures, and they don't respond to things like memory leaks or hanging network connections. They offer absolutely no scheduling, because services are designed to run all the time. On the other hand, Windows Scheduled Tasks have advanced scheduling features which can be accessed administratively. If the business requirements for my scheduled FTP task change two years down the road so the FTP should happen twice a day every Monday, Wednesday, and Friday, the change can be made by an administrator. The task schedule has been tested across leap years, daylight savings time, and clock changes; most custom timer routines I've seen haven't.
Scheduled console applications are easier to design, build, test, deploy, and install - especially compared to a professional service which can run reliably for weeks end. This wouldn't by itself be a compelling argument if a Windows Service were the right solution by other criteria, but since it's not, this is another nail in the coffin. Consider, then, that your extra time spent building a service is wasted development time. Maybe fun "I am a bigtime coder now" development time, but not of any business value.
Scheduled console applications are easier to run in an ad hoc manner when necessary. Let's say the webservice vendor calls three hours after our process ran to inform us that he had a data corruption problem which has been corrected and we should re-run our process. In the case of a Windows Service with a timer, we'd be scratching our heads; with our console application we can run it manually whenever we want.
Finally, running separate Windows Services with their own timers is just plain inefficient with server resources. Ignore for the second the fact that we're hogging CPU and memory space 24/7 for a process that runs occasionally; multiple independant timers which check the time every few seconds is dumb.
If I kept writing Windows Services with timers, eventually I'd start to think about writing a single host system with a timer. Then I'd want to add in some more advanced scheduling features; perhaps even some logging. Eventually, I'd have a Windows Service that handles scheduling of child processes, and if I devoted years to enhancements and testing, I'd eventually arrive at... the Windows Task Scheduler.
If you're writing a Windows Service that runs a timer, you should re-evaluate your solution.