Scheduled console app vs Windows service? When is it appropriate to use each

Question

I just read this: What is the benefit of developing the application as a windows service? but I'm still unsure of when to use a windows service.

I have a couple tasks that need to be run at intervals (i.e. every 5 minutes). Which project type should I use? Are there any examples of the types of applications that should be Windows services?

Answer 1

I'm telling you from my experience , one of the main reasons that most of the times I prefer using schedule task rather than a windows service is that it is much more easy-debug and of course on the top of the benefit's list is memory management in scheduled tasks.

Windows service is an always running process while an schedule task runs just when its actually needed, for example say you want to deal with a huge amount of data in your application and it should be triggered every hour, If you use windows service then you should be careful with disposing objects and releasing memory blocks correctly otherwise it could be a huge trouble, But in schedule task when your operation is finished, Your process is disposed and nothing is left behind.

Answer 2

Having had to do write, debug, deploy and support both, I prefer Scheduled Tasks far and away. I don't doubt that there are use cases where this would be the wrong choice. But for any relatively trivial task a console app running as a schedule task works great.

In my experience, scheduled tasks are extremely reliable. I don't recall a single failure and I support about a half dozen different scheduled tasks that run anywhere from daily to every 15 minutes. (Not that there have been no failures but they were all code or config issues. And were logged and notifications were sent. The problem has NEVER been with the Task Scheduling infrastucture.)

Task Scheduler tasks can run under any user context and does not need anyone to be logged in.

My biggest plus is in deployment. For console apps, just publish the EXE to the correct target folder. For windows services you need to stop the service (using net.exe), uninstall the service (using InstallUtil.exe), wait (I have the deployment sleep for 25 seconds), publish the EXE and then do it all in reverse (install, start).

If I were to develop a windows service again I would write it as a console app and then find a way to wrap it into a service to make debugging less of a headache.

Answer 3

For single or narrow purpose applications run on a schedule, running a console application via the Task Scheduler is almost always the correct design.

For long running or complex tasks that may need interaction such as manual start, stop, pausing, continuing, etc. then, in general, a Windows Service is the better option.

Scheduled tasks can be run under any account and do not need a user logged in just like Services. For single purpose tasks such as those you propose external control of the task is usually irrelevant so you have no need of the controllability of a Service.

A big factor also is the Task Scheduler is a very robust and flexible event based scheduler. It is extremely unlikely that you could write a scheduler that was more robust and could handle the vagaries of time and trigger based scheduling. In fact there are a number of questions about using timers for scheduling tasks in services on this site and it is remarkable the number of answers (including some of the 'correct' answers) that are poor quality or outright incorrect.

EDIT: It's also interesting to note that Microsoft policy is shifting away from using services for task based actions. If you check Vista, Win2K8 and Win7 you will notice a growing list of special purpose scheduled tasks that perform system maintenance and many system services.

Answer 4

I would recommend a scheduled task in all cases except programs that need to run at very short intervals, or that run continuously. Programs that start, perform their function, and shutdown have well defined resource lifetimes, perform the appropriate setup and cleanup in a bounded number of steps (and if not, the fact that they don't terminate in the expected time is indication of a bug), and thus are easier to reason about. And you don't need to fiddle about with timers and such.

Scheduled tasks have equivalent operations to the stop and restart commands of services, ie. disable task, enable task. Simple, and it lets any current operations in progress complete instead of trying to abort them, which is inherently correct way to handle this. Doing all of this state/transition management resource lifetimes manually is just error-prone in the presence of refactoring.

Answer 5

I have a number of windows scheduled tasks that run hourly on a production web server. They are not reliable at all. They are running in Windows 2003 Server under a specific machine account. Most of the time they work perfectly, but occasionally they fail to run and sometimes they terminate before they are finished.

Some of this may be due to the fact that they are vbscripts and the way they are written, but I've seen scheduled tasks with WS FTP Pro (commercial FTP software) that behave the same way.

I've converted many of these to windows services and have never had to worry about them again.

I would definitely lean towards windows services. Like some of the other comments, I have been burned by windows scheduled tasks too many times. I don't trust them for enterprise level solutions.

Answer 6

For any scheduled task, I would usually recommend a Windows Service, for the following reasons:

• A Windows Service will run even if a user is not logged into the PC (will run even if the server is sitting at the login prompt) (***Note - this may depend on the version of Windows you are running).
• A service can run as high-authority accounts such as Network Service or Local System, or a User - they have more configurability in that regard
• A service also comes built in with options for starting, stopping, restarting, and pausing while running (sometimes)
• You can also set up failure conditions for services, like if it fails have it auto-restart

As far as other examples of applications that can be windows services, a lot of times they are useful for applications such as remoting - you can have a service run a remoting server that clients connect to. Obviously very useful for data processing tasks that you want to run in the background as well, or processes where you want to send an email on certain conditions, etc.

In general I've always found scheduled tasks to be much more fragile and unreliable. And unless you have them log properly, often harder to debug.

In reference to the bug with the Timer - if you read the bug report on MS's site, you can see that it is caused when you call "Stop" inside the Timer_Elapsed event. The answer to this is simple - don't call stop. Instead, wrap the whole thing in a check for a "IsRunning" boolean and only run if IsRunning is false. Even if there wasn't an issue with the timer, you need to do this anyway because the timer might re-fire during your execution if your execution takes longer than your timer interval.

Anyway, I still think using scheduled tasks is a weak solution and gives me flashbacks of Windows 95.

Answer 7

I would prefer windows service in most cases.
One good thing when using scheduled tasks:
All used resources are released when the scheduled task have finished.

When using windows service (without stopping the service), the process never dies. And you must in your program make sure that resources are released.

Answer 8

That is a typical case for windows service, IMO.