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