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,
With Quartz.NET I could contrast some of the earlier points:
Code to write - You can express your intent in .NET language, write unit tests and debug the logic
Integration with event log, you have Common.Logging that allows to write even to db..
Robust and reliable too
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.
My gut reaction would be to try and get the integral WinScheduler to work with your needs first before installing yet another scheduler - reasoning:
no installation required - installed and enabled by default
no code to write - jobs expressed as metadata
integration with event log etc.
robust and reliable - good enough for MSFT, Google etc.
reasonably rich API - create jobs, check status etc.
integrated with remote management tools
security integration - run jobs in different credentials
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.
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.
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:
Clustering (distributed workers)
Fine-grained control over triggering or misfire handling rules
...then Quartz.NET will be your requirement.
Related
This is more of a general theory question as I'm stuck on how to proceed since this is my first time developing an application...
I'm developing a reporting application in VS 2015 that requires two types of functionality. It needs to have a GUI so that users can interact with and create reports and those reports need to be scheduled via Windows Task Scheduler. I'm planning on using a Console Application for the scheduling portion. My question is, what would be the best way to implement this? As of right now I have two separate Projects in a single Solution. Is this the best route to take considering my needs or is there a better option that I'm not aware of? I've done some searching online but have not been able to find a valid solution. It's especially difficult since the scheduling portion needs to pull the application settings from the Windows Form Application.
Any help or guidance would be greatly appreciated. Thank you in advance!
The only reason you would need a console application would be if you actually needed a console interface. It doesn't sound like that's the case—the interface will be written in WinForms. Therefore, you don't actually need two separate applications. You can combine all the necessary functionality in a single executable.
The way to do this is by checking for command-line parameters that indicate whether the app should run interactively or headless. Probably, what you'll want to do is make the app run interactively when no command-line parameters are passed. This would be the normal case, the situation the user gets into when they double-click your app to launch it from Explorer.
When it comes time to schedule your app to run a task in the background (with Task Scheduler or anything else), you signal this by passing a special command-line parameter to your app. You can decide what this is, and you may need several of them if your app can do multiple things in the background. If configuration information/parameters need to (or can) be passed to the app to configure how it should perform the background task, you can pass these on the command line, too. Or, as you mention in the question, you could pull these settings from whatever was set/saved by the user the last time they ran the interactive version of the app.
The trick is just checking for these command-line parameters in your application's Main method. In the design I proposed, if there are no command-line parameters specified, then you just go ahead and create the main form like you normally would. If there are command-line parameters, then you need to parse them to see what action is being requested. Once you've parsed them and determined which background task should be run, you just run that background task—without ever creating/showing a form.
There are lots of different solutions for parsing command-line parameters. Using a library would probably be the easiest way, and also give you the most features. But if you just needed something really simple, like a /background mode, then you could easily write the code for this yourself, without taking a dependency on a library or needing to learn how to use it.
So you could do all of this with a single project in a single solution if you wanted to. Or, you could split different aspects of the functionality out into different projects that compile to libraries (e.g., DLLs), but still have only a single executable for simplicity.
Does anyone have better ways of managing / scheduling console apps, without the use of Windows Scheduler?
eg. Console app to pickup records in the database that requires a set of actions.
*** Experience in the past, when number of tasks increase over time, it get's bit messy and difficult to maintain when moving servers.
There are third party apps you could look at, some of which are suggested in Cron-like system for Windows?.
However, if Windows Scheduler does provide the functionality you need, but just not the ideal management, you could look at using the CLI schtasks.exe
You can define all your tasks in an XML schema meaning they will more easily port across machines.
At the company I work, we have a product that for all intents and purposes could be called consultingware. It's a platform for EDI with quite a few moving parts. The back-end is an ESB written in Java SE, the front-end is a Java EE application running on GlassFish, the database is typically on an MSSQL server and RabbitMQ is used as queueing middleware. It's domain-agnostic in the sense that different message models and mappings can be deployed. Setting up a new environment tends to take quite a while, but a lot of it are mundane tasks that could easily be automated by filling in the right parameters and running scripts. T-SQL for the database, asadmin scripts on GlassFish, and the ESB configs are XML, so an XSLT transformation on a template would do the job.
This is never going to become a simple installation, but having an "installer" that does most of the work for you, lists prerequisite steps, presents the user with a convenient way of supplying necessary parameters, generating some scripts and putting things in place would be nice; even if only the devs ever use it, it would make life easier. Although the software is technically platform-independent, it tends to be run on Windows Server.
Just making a Java application that does the above wouldn't be very difficult, but rather than reinvent the wheel (and make a probably very ugly GUI) I'd like to see if any existing solutions fit the bill. InstallShield and Inno Setup look promising. So the question is, which existing tool could provide the following, or alternatively, is making something from scratch worth it?
Call other executables or installers (for GlassFish, for example).
Run shell scripts (for the asadmin setup).
Connect to a (MSSQL) database and run scripts.
Perform XSLT transformations (could be via a Java method call/jar execution).
Set up services.
Maybe have some way of checking if prerequisites are fullfilled (check if GlassFish is installed, RabbitMQ, DB is accessible...)
FWIW, you can do all of those things from an MSI. There are a number of tools out there that make the process easier. I use a free one called MAKEMSI that is excellent: http://dennisbareis.com/makemsi.htm
Hi I would like to know how many of you have used Workflow in your production environment and Was it good idea? I mean we can create the same thing using DB and scheduler service
We use WF in our production enviorments. We have 6 different workflows that can be run. These split into 3 statemachine and 3 sequences. I would use it again in some circumstances, but I would not in others. I would claim that the statemachine part of the workflow was tacked on the end quickly, I'm not sure it a core part of the workflow all the way through design.
I would use workflow again for short running processes like quotes or transforming things before sending them to supliers that kind of thing.
I would not want to do it again for a long running statemachine - mainly because there is not a built in WF upgrade process so we ended up writing our own. There are also a lot of concepts to get your head around (affectionalty known as gypsy curses with in our development team).
I would also be slightly concerned about performance: our App server is currently running flat out (ok I am restarting 8000 workflows at the moment). This is especially a problem if you integrate it directly into WCF using the (.NET 3.5) send and recieve activities - there are some properly crazy config settings you have to set to allow it run multiple workflows at once.
Anyway, as I said: it is useful, I would use it again, but not for another statemachine.
Also see Please confirm: Is Windows Workflow Foundation a good horse to be backing right now?
We use Sharepoint, which uses WF for its workflows. It works pretty well and is fairly easy to customize. If you need an advanced workflow, WF can support it but it will take some training to learn the ins and outs.
You could roll your own workflow, but why reinvent the wheel? WF is built into the .NET 3.0+ framework and is pretty robust, so you might as well take advantage of it.
Most people say all the good things about Workflows but I have observed that they introduce unnecessary code complexity and maintenance problems. They are suitable for a particular class of problems. other then that they need a lot of code plumbing and maintenance nightmares.
I work in a very small shop (2 people), and since I started a few months back we have been relying on Windows Scheduled tasks. Finally, I've decided I've had enough grief with some of its inabilities such as
No logs that I can find except on a domain level (inaccessible to machine admins who aren't domain admins)
No alerting mechanism (e-mail, for one) when the job fails.
Once again, we are a small shop. I'm looking to do the analogous scheduling system upgrade than I'm doing with source control (VSS --> Subversion). I'm looking for suggestions of systems that
Are able to do the two things outlined above
Have been community-tested. I'd love to be a guinae pig for exciting software, but job scheduling is not my day job.
Ability to remotely manage jobs a plus
Free a plus. Cheap is okay, but I have very little interest in going through a full blown sales pitch with 7 power point presentations.
Built-in ability to run common tasks besides .EXE's a (minor) plus (run an assembly by name, run an Excel macro by name a plus, run a database stored procedure, etc.).
I think you can look at :
http://www.visualcron.com/
Consider Cygwin and its version of "cron". It meets requirements #1 thru 4 (though without a nice UI for #3.)
Apologize for kicking up the dust here on a very old thread. But I couldn't disagree more with what's been presented here.
Scheduled tasks in Windows are AWESOME (a %^#% load better than writing services I might add). Yes, not without limitations. But still extremely powerful. I rely on them in earnest for a variety of different things.
If you even have a slight grasp on c# you can write as custom "task" (essentially a console application) to do, well, virtually anything. If persistent/accessible logging is what you're after, why not something like Serilog or NLog? Even at the time of writing, it had a very robust feature set. This tool in and of itself, in conjunction with some c#, could've solved both your problems very easily.
Perhaps I'm missing the point, but it seems to me that this isn't really a problem. At least not anymore...
If you're looking for a free tool there is plenty of implementations for the popular Cron tool for Windows, for example CRONw. It's pretty easy to configure and maintain. You could easily write add custom WSH scripts to send your emails and add log entries.
If you're going commercial way BMC Control-M is arguably one of the best but I don't believe that it is particularly cheap.
You may also consider some upcoming packages like JobScheduler
Pretty old question, but we use Jenkins. Yes its main purpose is for CI\CD, but its also a really nice UI for CRON with a ton of plugins and integrations.