views:

1071

answers:

8

I have a bit of code that needs to sit on a windows server 2003 machine and run every minute.

What is the recommended way of handling this? Is it ok to design it as a console service and just have the task scheduler hit it ever minute? (is that even possible?) Should I just suck it up and write it as a windows service?

+3  A: 

I would say suck it up and write it as a Windows service. I've not found scheduled tasks to be very reliable and when it doesn't run, I have yet to find an easy way to find out why it hasn't.

GregD
The event log should say why it hasn't.
jeffamaphone
@jeffamaphone "should" is the keyword. I've also found scheduled tasks to be unreliable, often leaving no trace of a run attempt in the event log.
Brian Knoblauch
+9  A: 

Since it needs to run every single minute, I would suggest writing a Windows Service. It is not very complicated, and if you never did this before, it would be great for you to learn how it is done.

Calling the scheduled task every minute is not something I would recommend.

Jon
+2  A: 

if you need to have it run every minute, I would build it as a windows service. I wouldn't use the scheduler for anything less than a daily task.

Stephen Wrighton
+1  A: 

I would say that it depends on what it was doing, but in general I am always in favor of having the fewest layers. If you write it as a console service and use the task scheduler then you have two places to maintain going forward.

If you write it as a windows service then you only have one fewer places to check in case something goes wrong.

SQLRockstar
A: 

I agree, it is kind of a waste of effort to create even a console executable and schedule it to be run every minute. I would suggest exploring something like Quartz.Net. That way you can create a simple job and schedule it to run every minute.

Kyle LeNeau
It seems you are against the idea of scheduling a task to run every minute... but are for the idea to do it through Quartz.Net? Am I missing something?
Nathan Palmer
+1  A: 

The only other point to consider, is that if you're job involves some kind of database interaction, consider looking into the integration/scheduling services provided by your database.

For example, creating an SSIS package for your SQL Server related service may seem a bit like overkill, but it can be integrated nicely with the environment and will have its own logging/error checking mechanisms already in place.

Dillie-O
A: 

Windows Scheduled Tasks has been fairly reliable for our purposes and we favor them in almost all cases over Windows Services due to their ease of installing and advanced recovery features. The always on nature of a windows service could end up being a problem if a part of the code that was written ends ups getting locked up or looped in a piece of code that it shouldn't be in. We generally write our code in a fashion similar to this

Init();
Run();
CleanUp();

Then as part of the Scheduled Task we put a time limit on how long the process can run and have it kill the process if it runs for longer. If we do have a piece of code that is having trouble Scheduled Tasks will kill it and the process will start up in the next minute.

Nathan Palmer
A: 

While searching for scheduled service help, i came across to a very good article "http://weblogs.asp.net/jgalloway/archive/2005/10/24/428303.aspx?CommentPosted=true#commentmessage" by Jon Galloway.

There are various diadvantages if a windows service is used for scheduled task. I agreed with it. I would suggest to use Task Scheduled, simple in implementation. Please refer "http://www.codeproject.com/KB/cs/tsnewlib.aspx" to detailed information of implementing the task scheduler. Hope this info helps in finalizing the implementation approach.

Nisha Kamble