views:

1221

answers:

10

If we need to write a program that works periodically, which way do we prefer? Writing a windows service or writing a console application which works as scheduled task?

+10  A: 

Depends on just how regular you need it to run.

If its something that needs to run every 60 seconds all day, I'd go with a Windows Service.

If its something that only needs to run once a day, I'd go with Scheduled Task

Anything in the middle... use your judgement :)

Eoin Campbell
+1  A: 

It depends on what you mean with periodically? Each second, Each minute, each hour, each day?

I would say the more frequent a task is to be running, the more a Windows Service is preferred.

Michael
+1  A: 

"It depends", but I usually prefer scheduled tasks, for simplicity:

  • You do not need to add any boilerplate service code to you program.
  • Your program can be run from the command line for troubleshooting (you would have to use command line switches in your service program to accomplish this).

If this is a more or less a one off, and something that you will install and controll yourself, a scheduled task is probably a good idea.

For something that should have the feel of a finished product, and the customer should install themselves, I would go with a Windows Service.

And the schedule is also an issue. The minimum schedule for a scheduled task is one minute. Anything below that, you either need to use a windows service, or build a loop into your job.

codeape
+1  A: 

If it truly is "periodically" then I'd go with Scheduled Task. These can be set up to run at any desired frequency.

Services are (in my experience) more for programs that have to respond to essentially random events, such as files arriving via FTP, or ones that have to monitor the state of the file system or database.

ChrisF
+11  A: 

I would suggest running the process as a scheduled task if you can, and writing a service only if you need to. Services are quite a bit more difficult to write (correctly), and if you're running your process on a schedule of any sort, you're much better off using the windows scheduler than attempting to build a scheduler of your own (within the servce).

  • The windows task scheduler is more efficient than your home-made scheduler will be
  • The windows task scheduler offers a number of options that you almost certainly won't attempt to replicate, but may find useful later on
  • If you build a service, you'd have to recompile the program if you want to change the logic that determines what conditions to run the task under. If you use the scheduler, you just flip some options and are done with it.

If you're trying to decide between the two, then obviously using the Task Scheduler is a viable option. And if using the Task Scheduler is a viable option, then building a service is almost certainly the wrong choice.

tylerl
But how do you prevent a Scheduled Task from interacting with the desktop? I've never figured out how to run in in the background, and lots of console windows popping up every five minutes (even minimised) are annoying.
Junto
+2  A: 

Alternatively have a look at quartz.net if you want something to run periodically. It's a pre-built framework that allows you to schedule tasks and saves you writing the service part yourself.

Matthew Steeples
+1  A: 

Avoid a service unless you must use it.

It is a process - which means it runs all the time. Gratitious use of system resources is bad practise.

I personally find it insulting that other people have their process executing 24/7 on MY computer when it is entirely unnecessary. It's MY performance they're using up. I disable all non-necessary background services.

Blank Xavier
+4  A: 

Start with a console app. Seperate the logic which would sit inside your loop-process-sleep loop, then you can actually switch between them easily - even in the same EXE.

I've done this. We could call:

ourservice.exe -console

and it'd just run. Or

ourservice.exe -install

and it'll install as a service :)

I'd go scheduled task in 99% of cases. If you need to run all the time, listen on ports, watch a folder (maybe - can be done every 10 seconds without a problem): then do it in a service. If all you do is wake up, do some processing (or not), and then go back to sleep: use the scheduler. It's easier, cleaner (memory management, esp if you are using COM objects, and REALLY if you are using MAPI), and the options (weekly, but not on tuesdays at 5pm) with the MS scheduler are better than you can write in the time..... which is NO time, as it already exists and is free

Oh, and it's easier to debug a console app (scheduler) than a service.... :) Or have someone "just run it".

Nic Wise
+1  A: 

I would think it would also depend on if you can leave the computer logged in or not. I've found that a Windows Scheduled Task cannot run unless the person that set up the task is logged in. If the computer cannot stay logged into, the program must be run as a service vice Scheduled Task.

+1  A: 

I think a service might be useful if you want to use WCF or .NET Remoting and have client applications communicating with some host service; otherwise I agree that a scheduled task is preferable to a service if the more complicated service adds nothing new.

And @Tom, his statement about having to stay logged into a computer for a scheduled task to run is false. I just tested myself, and confirmed that a Windows schedule task will still run even if you're not logged in (unless of course you select the option that the task only runs while you're logged on).

Hythloth