14 Apr 2015
edit on github
Hi there! I'm writing just to inform you that Hangfire Blog moved to the official site (long time ago, sorry for the late notification):
I'm not' ready to blog about anything else yet, and it would be very strange to write only about Hangfire in a personal blog. New product blog contains all the required links, has the same header as other parts of official site and thus is more useful.
10 Dec 2014
edit on github
Logging that just works
Logging was a very difficult thing to set-up in previous versions of Hangfire. Even if we omit tricky versioning issues, you had to install a separate logging adapter for your current logging library, with guessing the right one first (i.e. Common.Logging.NLog
or Common.Logging.NLog20
).
Now, the logging just works. If your project already uses Elmah, NLog, Log4Net, EntLib Logging, Serilog or Loupe you are not required to do anything. Thanks to awesome LibLog library by Damian Hickey (@randompunter on Twitter), installed logging library will be used automatically through the reflection.
If your application uses other logging library or a custom one, just implement two simple interfaces:
public interface ILog
{
bool Log(LogLevel logLevel, Func<string> messageFunc,
Exception exception);
}
public interface ILogProvider
{
ILog GetLogger(string name);
}
And yes, Hangfire is no more have Common.Logging
or Common.Logging.Core
dependencies.
Debugging with Symbolsource
SymbolSource is a service which exposes PDB symbols so you can step through Hangfire code while debugging your application. There are a few things to configure before we can begin, see symbolsource.org for more information.
Within Visual Studio:
- Go to Tools → Options → Debugger → General
- Uncheck “Enable Just My Code (Managed only)”
- Uncheck “Enable .NET Framework source stepping”
- Check “Enable source server support”
- Uncheck “Require source files to exactly match the original version”
- Go to Tools → Options → Debugger → Symbols
- Select a folder for the local symbol/source cache
- Add symbol servers under “Symbol file (.pdb) locations”: http://srv.symbolsource.org/pdb/Public
To speed up startup of the debug session, you can specify only the Hangfire dlls to be loaded. Go to Tools → Options → Debugger → Symbols, select "Only specified modules" and enter Hangfire.*.dll
Now you can step into Hangfire code while debugging.
Changes
- Added – Generation of NuGet symbol packages with
*.pdb
and source files.
- Added – Allow to customize serialization settings of Json.NET (by @fpellet).
- Added – Ability to configure
ServerTimeout
option.
- Breaking – Use
LibLog
package instead of Common.Logging
for logging.
- Changed –
Hangfire.SqlServer
is now merged with Dapper
package.
- Changed –
Dapper
package updated to 1.38.
- Changed – Use ILMerge instead of ILRepack.
- Changed – Update
Microsoft.Owin.Host.SystemWeb
to the latest version.
- Fixed – Dashboard not crash if a scheduling task is cancelled (by @fpellet).
- Other – Use psake instead of MSBuild for project build automation.
Links
15 Nov 2014
edit on github
As an ASP.NET developer, I always wanted to have something simple to handle scenarios where you need to build a long-running async task and show a loader to a user:
Loading…
Nothing is being loaded here, don't let hypnotize yourself!
But every time I faced Windows Services, message queues and other difficult-to-understand problems and hard-to-maintain solutions, my head exploded into a billion pieces. At the same time I looked at Rails' Sidekiq and wished to have a simple .NET alternative for background job processing. That is why I began to develop Hangfire (yep, just for the loader).
Slightly more than a year passed from the first commit and first version of Hangfire. This was my first open-source project that is being used more than in one organization, and it was an amazing experience for me to grow a project from scratch. I'm glad to see more and more people coming to the project and giving positive ratings and unvaluable feedback.
I want to keep Hangfire project as free as possible, but eliminate the most dangerous risk – the absence of time. There are many things to be done, including problems, new features, documentation, and I want to do them in a reasonable time.
Today, I'm introducing a new stage of Hangfire development – Hangfire Pro. It is a set of paid libraries that extend Hangfire functionality by providing features to improve performance and simplifying maintenance of background job processing in larger applications.
The Destiny of Hangfire.Redis
Bad News
First, I'll start with bad news – Hangfire.Redis package is moved to Hangfire Pro. This means that it became available only for Pro users and will be removed from public NuGet Gallery soon.
I understand that this step breaks your expectations, and I'm sorry for this. The source code will be available at Hangfire.Redis repository, but there will be no updates and official support.
Other existing parts of Hangfire will not be moved to the Pro version ever. Moreover, I'll try to do the vice versa, by open-sourcing paid extensions in the future, when the project will be more stable.
Good News
Most wanted features were implemented in the next version of Hangfire.Redis package. It now includes:
- Compatibility with ServiceStack 4.0 libraries. It still uses ServiceStack v3 libraries, but
ILMerge /internalize
utility is being used to merge them into Hangfire.Redis assembly. So, you can use either Service v3 or v4 in your projects.
- Configurable prefix for keys. You can use now the same database for different environments by setting corresponding prefix for keys in the
RedisStorageOptions.Prefix
property.
Hangfire Pro Today
Hangfire Pro already includes previously mentioned new version of Hangfire Redis package and a completely new Hangfire.PerformanceCounters package. The latter pushes internal metrics to Windows Performance Counters to proactively monitor issues with background job processing:

Hangfire Pro is available through the subscriptions you can buy at the official site. After purchasing a subscription, you will be able to do the following things:
- Access to Hangfire Pro package binaries and sources on the private GitHub repository.
- Access to priority and private support by dedicated e-mail (public forum discussions will be always free).
- Use Hangfire under EULA for organizations that don't want to use open-source licenses.
Hangfire Pro Roadmap
As I already said, Hangfire Pro will solve performance/usability/monitoring issues for larger web applications. Further work will be made in the following directions.
Batch Jobs
Batch jobs will help to build more complex workflows with Hangfire. They will give you the power of parallel processing and continuations, you can look at this code snippet:
BatchJob
.Create(x =>
{
x.Enqueue(() => Console.Write("Messy"));
x.Enqueue(() => Console.Write("Output"));
x.Enqueue(() => Console.Write("With"));
})
.ContinueWith(() => Console.WriteLine("Predictable continuation"));
Three first tasks will be executed in parallel, end the continuation will be invoked only after successful run of the first tasks.
Async Methods Support
As with async controllers in ASP.NET MVC, this feature enables you to improve overall throughput keeping the lowest number of workers in the pool. Instead of waiting for an outstanding I/O operation, they will be able to process other background jobs as well.
public static async Task HighlightAsync(int snippetId)
{
var snippet = await Context.Snippets.SingleOrDefaultAsync(snippetId);
snippet.Code = await RemoteService.HighlightAsync(snippet.Code);
await Context.SaveChangesAsync();
}
What are you waiting for?
Smart people say that content like this should contain a call to action. I have no enough experience to break the rules, so here it is:
30 Jun 2014
edit on github
Hangfire has finally reached the 1.0
milestone! This means that public API is frozen and considered to be stable. Starting from now, the SemVer 2.0 specification will be used for versioning every package (but there may be exceptions, follow the README for each package).
I want to thank everyone who helped me to reach this milestone, without your participation I would not be able to finish the work. Special thanks:
Release Notes
- Added – OWIN implementation for Hangfire Dashboard.
- Added – Custom authorization filters support for dashboard.
- Added – Unified bootstrapper to start Hangfire in web applications.
- Added – Descriptive names for background jobs in Dashboard.
- Added – RabbitMQ support for SQL Server storage.
- Changed – Hangfire now requires .NET Framework 4.5.
- Changed – Namespaces, assemblies and packages now start with
Hangfire
(not HangFire
).
- Changed –
Hangfire.Core
now contains the dashboard. There is no more Hangfire.Web
.
- Changed – Common.Logging dependency package updated to 2.2.0.
- Changed – Default dashboard url is now
/hangfire
(without .axd
suffix).
- Removed – Removed
Enqueue
method overloads with queue parameter.
- Removed – Removed
AspNetBackgroundJobServer
class.
- Fixed – Russian language in Dashboard replaced with English.
- Fixed – Recurring jobs reported to be executed 44 years ago.
Upgrading from 0.x
If you have only Hangfire
package installed, package update is very simple. Just type in your Package Manager Console window:
PM> Update-Package Hangfire
For custom installations, first update each package, and then remove the Hangfire.Web
:
PM> Update-Package Hangfire.Core
PM> Uninstall-Package Hangfire.Web
Breaking Changes
- Target your project to .NET Framework 4.5 or later.
- Replace all occurrences of
HangFire
(case-sensitive) to Hangfire
(lowercased f
letter) in your projects.
- Use the
UseHangfire
extension method for OWIN app builder instead of AspNetBackgroundJobServer
.
- Replace all links to Dashboard from
/hangfire.axd
to /hangfire
.
- Change your authorization rules as described here.
Links
07 Jun 2014
edit on github
Recurring jobs
This version brings incredibly easy method of scheduling and running recurring jobs inside ASP.NET applications. You need to call only a single line of code to perform this task:
RecurringJob.AddOrUpdate(() => Console.Write("Easy!"), Cron.Daily);
The Cron
class provides different easy to use methods and overloads to set up recurring jobs on a minutely, hourly, weekly, monthly and yearly basis. It is also possible to use more complex CRON expressions, since the NCrontab
library is being used to perform scheduling logic.
RecurringJob.AddOrUpdate(
() => Console.Write("Powerful!"),
"0 12 * */2");
HangFire will check the schedule each minute and enqueue recurring jobs as regular background jobs, so you receive all power of HangFire, including the full transparency, free of charge.
HangFire Monitor was also updated and allows you to see and manage your recurring jobs:

So, HangFire now supports all kinds of background jobs: fire-and-forget, delayed and recurring, and let you process them with ease!
Changes
- Added – Out-of-the-box support for running recurring jobs.
- Added –
SqlServerStorage
now also accepts connection string names.
- Changed –
IBackgroundJobClient
does not implement the IDisposable
interface anymore.
- Changed –
IMonitoringApi
does not implement the IDisposable
interface anymore.
- Changed – Improve
DateTime
resolution for job arguments by including milliseconds.
- Changed – Removed deprecated
RetryAttribute
class. Please, use AutomaticRetryAttribute
.
- Fixed –
KeyNotFoundException
when accessing job cancellation token with Redis.
- Fixed – Theoretical race condition that makes HangFire Server invisible from Monitor.
Upgrading
Version 0.9 brings some breaking changes. Please, do the following steps to perform the upgrade.
- Replace the
RetryAttribute
with AutomaticRetryAttribute
.
- Remove the calls to
Dispose
method of IBackgroundJobClient
interface (or BackgroundJobClient
class).
- Remove the invocations of
IMonitoringApi.Dispose
method.
Links