Software Architect / Microsoft MVP (AI) and Technical Author

Architecture, ASP.NET Core, C#, Tooling

Implementing Long running Tasks in Azure

A few months ago, I had to build functionality that invoked a background process from an ASP.NET Core web application.

This had the responsibility of ingesting data from the web that was then surfaced during chatbot conversations.

In the past I would have written a Windows Service to do this and then installed it on an interface server (or something to that effect). Or, if I was REALLY pushed for time, quickly write a console application then house this in Tophelf (shock horror!)

With everything moving to the Cloud, provisioning a new VM that would only have this job on it seemed like overkill!

After a bit of research and looking around, I narrowed my options down to the following:

  • .NET Core Worker Service
  • Azure Function
  • Web Job

I had a few constraints, one of which was the business also needed a way of logging into the ASP.NET Core Web App to quickly check the status of the background process in dashboard.


It’s at this point that I discovered Hangfire and the more I looked into it, Hangfire became a viable option to help me quickly implement the background threading and UI that I needed.  It turned out to be an ideal solution for my specific requirements.

It was easy to install, had no other dependencies on additional services and background jobs were persisted in a storage mechanism of your choice.

(image source

Installation and Setup

Installing and setting up Hangfire is straightforward. You can download it as  NuGet package and make a few tweaks to your ASP.NET Core web app. Literally a few tweaks.

If you want to leverage the dashboard (more on that in a bit), you only need to add a few lines of code for that as well.

It’s one of the smoothest installations I’ve had when you consider all the functionality that’s on offer.

Key Features

I won’t go into all the features, but some include:

  • Dashboards to visualise performance, queued work, failed jobs
  • Detailed screen to drill down into the background job details
  • Calling methods in the background
  • Calling methods with a delay
  • Passing arguments to background methods
  • Passing dependencies
  • Using IoC Containers

You can find out more about the key features that ship with Hangfire here.

Invoking Hangfire from ASP.NET Core

I was looking to invoke a background thread that accepted a parameter (customer id) in the constructor.

To that end, I had a class within an API which contained a method to get the chatbots data.

The constructor for this class required the customer id parameter.

This caused me a few headaches with Hangfire but after a little reading on the documentation site, it turns out that all you need to do is to implement a custom Job Activator.


Well, out of the box, Hangfire uses a classes default constructor.  i.e. the constructor that has no parameter. Doh! After sorting out that issue I was good to go.

In terms of invoking a background job, it’s as simple as writing something like:

var jobId = BackgroundJob.Enqueue(
    () => Console.WriteLine("Fire-and-forget!"));

The Verdict

This tool saved me quite a bit of work a few months ago.  I didn’t have to be concerned about managed background threads and could leverage existing APIs I had built. Hangfire also gave business users an easy to understand dashboard to keep them up to date with chatbot data processing.

I have some other data processing middleware that I need to migrate soon that applies Azure Cognitive Services to social data.  For this I’ll most likely use a Web Job or Azure Function as I don’t need much of an interface.

What are you using to invoke and manage background threads in Azure?

Get the latest content and code from the blog posts!
I respect your privacy. No spam. Ever.

Leave a Reply