Quartz.NET vs Windows Scheduled Tasks. How different are they?

Question

I'm looking for some comparison between Quartz.NET and Windows Scheduled Tasks?

How different are they? What are the pros and cons of each one? How do I choose which one to use?

TIA,

Silvasilvain

Answer 1

With Quartz.NET I could contrast some of the earlier points:

1. Code to write - You can express your intent in .NET language, write unit tests and debug the logic
2. Integration with event log, you have Common.Logging that allows to write even to db..
3. Robust and reliable too
4. Even richer API

It's mostly a question about what you need. Windows Scheduled tasks might give you all you need. But if you need clustering (distributed workers), fine-grained control over triggering or misfire handling rules, you might like to check what Quartz.NET has to offer on these areas.

Take the simplest that fills your requirements, but abstract enough to allow change.

Structuralism

+1 If you don't know either the Windows Scheduler API or Quartz.Net API, then I think you will be faster on your tracks with Quartz.Net – Matchlock

@Marko, Quartz.Net might affect webiste performnace. Because in case of windows scheduler it runs in different thread. Please suggest. – Alcahest

You might confuse threads and processes here. Windows scheduler is indeed in its own process. As long as they both sit on the same box they will be eating resources from the machine. You can always host your scheduler under windows service, either on same box or completely different one. – Structuralism

quartz-scheduler.net as the existing link to quartznet.sourceforge.net is no longer working. – Executory

@MarkoLahma I think Quartz.NET is really very useful and smart. On the other hand, I cannot create a weekly schedule. Could you please have a look at this question? – Subliminal

Answer 2

My gut reaction would be to try and get the integral WinScheduler to work with your needs first before installing yet another scheduler - reasoning:

1. no installation required - installed and enabled by default
2. no code to write - jobs expressed as metadata
3. integration with event log etc.
4. robust and reliable - good enough for MSFT, Google etc.
5. reasonably rich API - create jobs, check status etc.
6. integrated with remote management tools
7. security integration - run jobs in different credentials
8. monitoring tooling

Then reach for Quartz if it doesn't meet your needs. Quartz certainly has many of these features too, but resist adding yet another service to own and manage if you can.

Noe

I make kind of the same reasoning: Why use some 3rd party when Windows fills your needs? I wanted to make sure though that I'm not missing any boat. – Silvasilvain

@Reader: It may seem obvious but... if you choose to use the Windows Task Scheduler you are in effect exposing part of your application to the outside world. Anyone with the appropriate permissions can modify (or even delete) your application's task. This may, or may not be an issue for you. – Asthenosphere

@Asthenosphere Forgive me for commenting on such an old post, but isn't that what in-line tests are for? Pseudo example: if (task.Exists) do nothing else (task.Create)? – Barabbas

@Wolfish: The point I was trying to make is that if you are relying on an external service (e.g. the Windows Task Scheduler) then your application will be exposed to external events that are beyond your control (e.g. task deleted unexpectedly). On the other hand, if your application manages the scheduling internally... then having defensive code is less of an issue. My preference would be to keep the scheduling internal to the application. With that said, there are projects where that simply won't make sense. en.wikipedia.org/wiki/Defensive_programming – Asthenosphere

@Asthenosphere Ah, but aren't we always fighting the users of our code? Heh. I see your point, however. – Barabbas

I believe this discussion is very debatable. For me, I want the implementer to be able to configure Jobs easily. Deployment process is automated in my company. I really like the way of killing the whole exe or the job when it's done. I may give this job task to any dev who might forget to handle resources. The UI for TaskScheduler is easier than this bugsquash.blogspot.com/2010/06/… for sure :) at least for the Non-Dev guy perspective. Having "abstract enough to allow change" as @Marko Said is important so we will refactor existing code to get this. – Subchloride

Answer 3

One important distinction, for me, that is not included in the other answers is what gets executed by the scheduler.

Windows Task Scheduler can only run executable programs and scripts. The code written for use within Quartz can directly interact with your project's .NET components.

With Task Scheduler, you'll have to write a shell executable or script. Inside of that shell, you can interact with your project's components. While writing this shell code is not a difficult process, you do have to consider deploying the extra files.

If you anticipate adding more scheduled tasks over the lifetime of the project, you may end up needing to create additional executable shells or script files, which requires updates to the deployment process. With Quartz, you don't need these files, which reduces the total effort needed to create and deploy additional tasks.

Suzisuzie

Answer 4

Unfortunately, Quartz.NET job assemblies can't be updated without restarting the process/host/service. That's a pretty big one for some folks (including myself).

It's entirely possible to build a framework for jobs running under Task Scheduler. MEF-based assemblies can be called by a single console app, with everything managed via a configuration UI. Here's a popular managed wrapper:

• https://github.com/dahall/taskscheduler
• https://www.nuget.org/packages/TaskScheduler

I did enjoy my brief time of working with Quart.NET, but the restart requirement was too big a problem to overcome. Marko has done a great job with it over the years, and he's always been helpful and responsive. Perhaps someday the project will get multiple AppDomain support, which would address this. (That said, it promises to be a lot of work. Kudos to he and his contributors if they decide to take it on.)

To paraphrase Marko, if you need:

1. Clustering (distributed workers)
2. Fine-grained control over triggering or misfire handling rules

...then Quartz.NET will be your requirement.

Pomiculture