views:

289

answers:

4

The title says it all, really. I know this is largely an opinion, but I'm interested if you have one and what your reasons are.

Duplicate: How reliable is windows task scheduler for scheduling code to run repeatedly?

+5  A: 

I have many programs like this and I run all of them as a service with a scheduler. The advantage is that it can run without any user being logged on. Plus I can stop/start remotely.

Otávio Décio
http://www.opensymphony.com/quartz/ is a nice .Net scheduler library.
Jason DeFontes
But is that Windows task scheduler, or your own system?
Mark
@Mark: that's my own system, I start the service and it reads scheduling info from the config file, from which it gets the assembly and method to call when the time hits.
Otávio Décio
We run both ways although I've started running everything using a "service task" plug-in architecture we've developed. Can't you can run a scheduled task without a user being logged in? I'm fairly certain we do this all the time but I'm wondering if I'm misunderstanding what you mean.
JohnOpincar
ocdecio: why not use task scheduler, then?
Mark
@Mark - I guess I could, but for me a service seemed to be more flexible and easy to manage remotely.
Otávio Décio
A: 

I had one similar scenario:

It was a legacy EXE, needed to run once a minute with explicit user credentials, only needed to run while a specific application was running (after the user logged in), and needed to be done "yesterday."

Hence, it was easy enough to just use the built-in mechanism to run using a scheduled task. No new code needed to be written and it would not run unless it really needed to.

I would typically rather use the Service approach, though.

Erich Mirabal
A: 

You will use less CPU running it as a service than as a scheduled service (not that it will matter likely). But, I would go with service.

Mike Curry
A: 

If it can be usefully run standalone by multiple users, it's probably best controlled by the task scheduler. If you don't have the source code, there's not much point writing a wrapper that does what the task scheduler does anyway. The only times I've only had scheduled tasks fail is when running off a flaky network (make sure you untick the "only on AC power" option if it will run on a laptop).

However, if you can recompile it, and it look like a service (dependable, needs recovery on failure, will get widely deployed, etc.), you might want to rework it as one. In addition to being more efficient, you could then report status, respond sensibly to start/stop requests, and add intelligent timing.

Mark