scale the background processing workload independently of your Website and you need control over the machine

There's lots of great articles and videos on how to use Azure WebJobs, and lots of documentation on how Worker Roles in scalable Azure Cloud Services work, but not a lot about how your hosted ASP.NET application and easily have a background service. Here's a few.

As it says "WebBackgrounder is a proof-of-concept of a web-farm friendly background task manager meant to just work with a vanilla ASP.NET web application." Its code hasn't been touched in years, BUT the WebBackgrounder NuGet package has been downloaded almost a half-million times.

The goal of this project is to handle one task only, manage a recurring task on an interval in the background for a web app.

If your ASP.NET application just needs one background task to runs an a basic scheduled interval, than perhaps you just need the basics of WebBackgrounder.

QBWI schedules a task which can run in the background, independent of any request. This differs from a normal ThreadPool work item in that ASP.NET automatically keeps track of how many work items registered through this API are currently running, and the ASP.NET runtime will try to delay AppDomain shutdown until these work items have finished executing.

It can try to delay an AppDomain for as long as 90 seconds in order to allow your task to complete. If you can't finish in 90 seconds, then you'll need a different (and more robust, meaning, out of process) technique.

The API is pretty straightforward, taking Func<CancellationToken, Task>. Here's an example that kicks of a background work item from an MVC action:

Quartz.NET is a .NET port of the popular Java job scheduling framework of the (almost) same name. It's very actively developed. Quartz has an IJob interface with just one method, Execute, to implement.

And last but definitely not least, the most polished (IMHO) of the group, Hangfire by @odinserj. It's a fantastic framework for background jobs in ASP.NET. It's even optionally backed by Redis, SQL Server, SQL Azure, MSMQ, or RabbitMQ for reliability.

There's a rich ecosystem out there ready to help you with your background tasks. All these libraries are excellent, are open source, and are available as NuGet Packages.

Did I miss your favorite? Sound off in the comments!

Sponsor: Many thanks to my friends at Raygun for sponsoring the feed this week. I *love* Raygun and use it myself. It's amazing. Get notified of your software’s bugs as they happen! Raygun.io has error tracking solutions for every major programming language and platform - Start a free trial in under a minute!

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

I was wondering if these are limited to tasks which are due to run or repeat in the very near future, or can they span over days? Could I schedule a task to run once every evening for an indefinite time? Do all the libraries you've presented support this, or just some of them?

Is running background tasks in your ASP.NET process the wrong aproach? I would always be very uncomfortable doing this. Off loading tasks to a worker role type process is a much more scalable solution. What happens if you want to load balance your ASP.NET process. Who then becomes responsible for maintaining the background tasks?

Is running background tasks in your ASP.NET process the wrong approach? I would always be very uncomfortable doing this.

Yes, there are different problems related to background processing in ASP.NET application itself, some of them described in the given article written by Phil Haack. But almost all of them can be solved by framework itself by using different compensation techniques. Here are the ways how Hangfire solves them (disclaimer: I'm the author).

App domain unloads. This is the most complex thing. In case of graceful termination all jobs are being returned to their queues programmatically. In case of unexpected termination they are being returned after some interval (this interval can be eliminated by using MSMQ or RabbitMQ) – Hangfire guarantees that every queued background job will be processed anyway when there is at least one running Hangfire Server.

Who then becomes responsible for maintaining the background tasks?

As I said earlier, there are automatic retries with increasing intervals, but their number is limited (10 by default, but you can set the number manually). After retry attempts were exceeded, the responsibility for background tasks move to a system administrator (with logging enabled, you will receive notifications about failed jobs) – she can do this task through integrated web interface with ease.

The issue in the passed that i've had, is the app pool gets recycled and the background task code doesn't run until someone visits the websites and starts the process (obviously only really an issue on small infrequently visited websites).

James.

James

Tuesday, 26 August 2014 12:04:05 UTC

+1 for quartz.net. I'm using it for scheduled jobs and for long running background tasks submitted from asp.net on demand. http://www.cronmaker.com/ is great for creating those obtuse cron expressions.

ira

Tuesday, 26 August 2014 12:10:13 UTC

I am extensively using windows service for most of my healthcare related work. Still looking for elegant distributed architecture, something similar to Celery backed by Queue, AKKA in scala etc., perhaps, Akka.Net may solve this, but need to wait till then windows service with sql server is promising solution for asp.net(I am not considering Azure here).

These are really useful for cache management tasks. Especially if you want to consolidate cache expiry handlers into a single action. This is something the other worker types (azure jobs) and the like cannot handle because they aren't executing in the context of the web application itself.

Mike J

Tuesday, 26 August 2014 13:27:51 UTC

Good article. Using Quartz for building windows service based job scheduler, and its perfectly working. Cron expression are very handy while configuring jobs.

Gourav Saini

Tuesday, 26 August 2014 13:30:14 UTC

I lean towards Webjobs, myself. :) Though I have recommended Hangfire to others.

All the libraries here are schedulers for running recurring/periodic background tasks within ASP.NET. There's another category of "background tasks" in ASP.NET that I find people ask for a lot: the ability to "return early" from a request and then have the server do a bit more work.

So, I think HostingEnvironment.QueueBackgroundWorkItem could get an honorable mention. It's a whole level of abstraction beneath these libraries, though; it doesn't do any kind of scheduling or retries, and it's not aware of web farms. It catches (and ignores) errors, and does register the work with ASP.NET, so it's a step above Task.Run without going full-fledged background service.

I found solution which works best for me for applications installed on own server (not shared hosting). I use c# wrapper for Windows Task Scheduler. Application publishes tasks with default settings into Task Scheduler. UI for configure (for admins) just is there :)

Tasks run specified job to do by executing some REST API within my application: ITaskJob { Execute(); }.

Best regards

dariol

Tuesday, 26 August 2014 13:43:46 UTC

What are peoples' thoughts on HostingEnvironment.QueueBackgroundWorkItem? I've been using this successfully for quite some time now.

Ryan Besko

Tuesday, 26 August 2014 13:49:23 UTC

The approach I've used to this problem is to do my background processing in a Windows service, and then use polling or a message queue to find out about tasks. To my surprise, that didn't even make the list.

Is there a reason why a service is undesirable?

Blair Learn

Tuesday, 26 August 2014 14:15:37 UTC

.NET 4.5.2 introduces HostingEnvironment.QueueBackgroundWorkItem to help run background tasks in an asp.net app domain. The method registers the task with asp.net so that the runtime will know about it during recycles or app shutdowns, and it gives you a CancellationToken that will cancel whenever an event like this is triggered.

The method mitigates many of the risks of trying to run a background task in-process in an asp.net app domain, but if you want fancy scheduling, repetition or durability you're still better off using a helper library like Hangfire.

Someone once asked me, "Well what happens if the app shuts down due to inactivity?" To which I responded, "Then there isn't any work for the background stuff to do." :)

I've already done some work to run this in an Azure worker role (code is already in the repo, sans any instrumentation), but the original intent of this was to serve people with cheap hosting who couldn't run anything outside of the context of the site, because they had no access.

Thank you very much for this article. I was struggling with this for quite a while. My plan was to create a Windows Service that runs a specific action on the website to avoid complications. How are these solutions better/different than creating a Windows Service? Any thoughts?

Nice summary of the options. I'm leaning towards WebJobs these days, but Hangfire does look interesting. One issue I had with Quartz scheduling in ASP.NET was that I did not take into consideration a web farm scenario. I published to Azure Websites (before WebJobs was out), and it took me a bit to realize my background scheduled tasks were running three places. Even though I had a single instance of the Website running, apparently MS keeps one or two running off to the side. For queue processing, this was desirable. But in some cases- database cleanup for example- you want to guarantee only one instance of a job is going to run.

Just an example of one of those nuances a naive approach like mine may overlook...

Hangfire depend on Microsoft.Owin.Host.SystemWeb 2.1, then I have other library depend on Microsoft.Owin.Host.SystemWeb 1.0 and cannot switch out for specific reason. Start to hate Owin implementation lately because of dependency on Katana project.

Whenever I see a new library come out with Owin implementation, it can be pretty much ignored or try my best to avoid using it.

Jason

Tuesday, 26 August 2014 22:48:28 UTC

James and FJ - Yes, none of the libraries actually give a *guarantee* that the tasks will complete. Also, since ASP.NET 4.5.1 has the ability to suspend all threads in an AppDomain, there is no guarantee that background tasks will complete unless a request comes in to wake up the suspended thread. This is per Levi on our team.

Scott Hanselman

Wednesday, 27 August 2014 09:25:38 UTC

Hangfire has really good documentation, build with Sphinx and hosted on ReadTheDocs.org (I sort of know it's going to be good when I see this combination).

Tomas

Wednesday, 27 August 2014 12:35:33 UTC

If the Hangfire Highlighter Tutorial was calling HighlightSource method in IIS-hosted WCF service in a new thread (say using just new Thread(HighlightSource)) should it still use Hangfire instead of new Thread to make sure that job will finish before app domain is shut down?

What about WCF

Wednesday, 27 August 2014 20:47:37 UTC

Hangfire looks awesome. I've generally set up a queue in SQL Server and have a console app pick up and perform whatever task I wanted, but that's kind of a pain and not the most elegant.

Why would you even want to run a task in the process of the website?This seems like a last resort if you don't have access or aren't able to run console/service-like process that can process a queue. The risk seems to great to me to use this just so it's all in the same project.

As someone who's spent years building apps using good old system.threading.tasks, Hangfire is one of those annoying (in a good way) frameworks that make you scream 'Why didn't I see this months ago?' :-)

I'm usually not a fan of shoe-horning things into where they shouldn't be, but I can see a genuine need for this.

I intended to just skim the documentation, but ended up reading it all as it was so well written.

Great idea, I will be using it myself and will report back.

Will

Thursday, 28 August 2014 21:25:34 UTC

Thanks for another great article Scott. I sure will check Hangfire next time.

p.s. Can you 'fix' the second paragraph after the WEBBACKGROUNDER h3?

John

Friday, 29 August 2014 07:59:34 UTC

Work or Task Queues are a common pattern for handing off long running work to a separate process. Most of the 'BUS' implementations out there NServiceBUS, FubuBUS, ReBUS, and Mass Transit can be used in this way. Outside the .NET space Celery is a Python library that has similar characteristics. Some support 'scheduled' or 'delayed' jobs, others don't.

My own OSS project Brighter is not only a Command Processor/Dispatcher, it also supports Work Queues over .NET, using RabbitMQ today, although I am looking at an experimentat RESTMS application layer support as well. Always happy for feedback: http://iancooper.github.io/Paramore/Introduction.html

Question - In Hangfire or any of the libraries, can I queue a call to a service method that uses TPL. I am trying to re-use existing service methods that use async await but I also want to perform that work in a background thread in some cases.

Example - /* question - guess this wont be using the async await feature and will just queue the service call as a blocking sync call on the background thread and that thread wont be avail other work whilst its waiting on I/O in the service method? */

BackgroundJob.Enqueue<Task>(() => BusinessService.DoWorkAsync(user));

thanksJatin

Jatin

Tuesday, 02 September 2014 14:53:49 UTC

What about simple windows service? It is not the best one, but I think many people use it for the background tasks implementation.

Alexander Skogorev

Friday, 10 October 2014 19:38:10 UTC

Hi Scott

You said:--------------------------------James and FJ - Yes, none of the libraries actually give a *guarantee* that the tasks will complete. Also, since ASP.NET 4.5.1 has the ability to suspend all threads in an AppDomain, there is no guarantee that background tasks will complete unless a request comes in to wake up the suspended thread. This is per Levi on our team.--------------------------------First. What does "This is per Levi on our team?". 'm Not American and do not know this expression

And is there any date, any experança so we can have some feature in asp.net to ensure that the tasks actually execute.

I need it, but without having to change any settings in IIS. An optical solution would only put in one web.config "alwaysRuning = true" setting and ready

Please tell me that we will have news this direction

penihel

Saturday, 25 October 2014 12:56:13 UTC

You da MAN, Hanselman!! x

Nadz

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.