views:

970

answers:

8

I need to create a Windows service that works just like the task scheduler in that I can configure what time it runs and it basically just calls a .NET class at that scheduled time (recurring). What is the recommended way to do this? Also, any information on installing/removing that service would be appreciated!

Update: Using the task scheduler in not an option (customer requirement, something to do with their IT standards). That was my suggestion to them as well, but it's not going to work.

Solution: Thanks to everyone for your answers, the Quartz.Net solution especially looks good, however I found the following which has exactly what I need:

http://www.c-sharpcorner.com/UploadFile/ajifocus/AppScheduler05262006074807AM/AppScheduler.aspx?ArticleID=b52f76da-943f-4807-9675-869f135ef2cd

A: 

Oh there are so many.

I'd start with a standard windows service in .Net and use the Properties\Settings feature to store my scheduled time (this really only works with a single time - a more sophisticated config would be required for more than one time).

I would also include a string to define the assembly/class I wanted to run in that configuration as well and make sure that assembly had a class that either inherited from a base class or implemnented an interface so I could load it up as a known type and Execute a known method called something like Execute().

Or you could defint the method you want to call in the configuration file as well and use reflection to call that method.

Brody
+2  A: 

If you have access to the box, why not just use the windows task scheduler and call functionality from an console exe. Way more easier than re-inventing the wheel.

HTH
Kev

Kev
I agree. Why not just create a wrapper exe that calls your class when it is run, and use the scheduler?
Tim
A: 

I had the same problem before, task scheduler has a bit problem by itself. It can never be a reliable replace to linux's cron. Once I had to write a service to do just that. I had a System.Threading.Timer running in a 1 second loop. Then it checks for events that needed to be fired (external exe) according to the configuration I stored in an xml file.

faulty
The Windows task schedule is a service. How have you find it problematic? It also handles some complex issues well including lunching un-elevated process correctly and using credentials. How confident are you that a home grown solution or something off CodePlex would be as secure or as reliable as the Windows Task service?
Foredecker
+5  A: 

You could embed the Quartz.Net scheduler in a service.

PeeVeeGee
+1 for Quartz.NET within a Windows Service. I just implemented it with a custom config section to define each of the jobs I want to run and used the "cron" syntax to determine the frequency of each of them. It works really well.
jeremcc
A: 

I'm sorry, my response doesn't tell you how to implement this.

Why would your customer forbid using some built-in OS feature, while allowing a home-grown clone of it to be run?

I think it's going to be less work to try to convince your customer that it's a bullshit requirement than it is to recreate the windows scheduler as a stable service. Besides saving time by just using the existing one, you'll probably end up with a better solution. A win-win for everyone :)

Wouter van Nifterick
A: 

Hi Abdullah,

Its most important to realize that creating a windows service is quite complicated to get right. This is especially true on Version 6 and later products because services are isolated form the desktop. Here are a few comments

  • Services are harder to debug than basic user mode program.
  • Services cannot interact with the user on V6 and later operating systems. So you cannot give them a console or have them pop up message boxes directly.
  • Communicating with a services is usually done via Remote Procedure Call or out of process COM. Both can be complicated even for seemingly rival things.
  • Services run essential fervor so they must be significantly more reliable and efficient than other executable.
  • Depending on the security context, it can be difficult to get a service to cause other things to happen in the system.

Instead of service, I would recommend a "deamon". This would be a small program that has a hidden user interface - just run it at startup just like any other app. It will run in the user's context and can do any thing the user can do (which is probably what you want). You could give it a tray icon if you needed, or use a signal from one of your other apps to have it reveal its simple UI.

Foredecker
+1  A: 

You could try the .NET Task Scheduler http://TaskService.Codeplex.com. This project provides the ability to schedule .NET assemblies to run at anytime of the day with different kinds of recurrences like daily, hourly, weekly, every 5 hour or every third day.

Check it out. Joseph Guadagno Microsoft Visual C# MVP http://www.josephguadagno.net

Joseph Guadagno
Why not use the built in Windows Task Scheduler? It seems inefficient to add another service that does the same thing as a built in Windows feature. Does the TaskService on CodePlex do anything significantly different or better than the Windows Task Scheduler?
Foredecker
A: 

If you are creating a scheduling system, you are much better off writing a windows service. Even though they are hard to debug, if you move all the functionality out of the service and into helper and service agent classes, you can easily test the functionality without needing to bother with the service.

You can then expose whatever information you need to provide to a front end via WCF services. They can be hosted in any executable now, so windows service works just fine. The advantage to the windows service tactic is that you don't need a desktop. Scheduled tasks are (or should be) intended to run in the background. Windows services are a good approach to background tasks.

I've looked at after-market 3rd party scheduling systems, open souce schedulers and quartz.net. We have chosen the latter. If you budget can foot the bill, look at scheduling systems like JAMS or others.

Tim