I have an EXE that needs to run once per minute. Should I do it as a scheduled EXE or a Windows Service?

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?

From stackoverflow

• 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.

  Jason DeFontes : http://www.opensymphony.com/quartz/ is a nice .Net scheduler library.

  Mark : But is that Windows task scheduler, or your own system?

  Otávio Décio : @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.

  JohnOpincar : 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.

  Mark : ocdecio: why not use task scheduler, then?

  Otávio Décio : @Mark - I guess I could, but for me a service seemed to be more flexible and easy to manage remotely.

• 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.

• 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.

• 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.