Hangfire has received a lot of attention lately as a replacement technology for background processing and workers in the .Net stack. Hangfire has some great out-of-the-box features such as it's dashboard. It is also pretty easy to set up and implement simple tasks like an email worker.

What hangfire doesn't do so well is argument and dependency resolution for workers. For example; it is best practice to make the workers reentrant with simple primitive object arguments. This is so that a task can be easily retried on error or can be run in parallel. A common work around for workers to be reentrant with complex arguments is to serialize the complex object in to a string, i.e. JSON.

Fixing the dependency resolution requires a bit more work. Hangfire has some documentation and thirdy party Nuget packages to help with the dependency resolution, but these are not always maintained and don't fit in with our typical enterprise project structures.

The fix is to implement Hangfire's JobActivator class for your chosen IoC container of choice. We'll use Unity as an example.

So starting off where Hangfire's Quick Start guide ends; you should have an OWIN bootstrapper start up class as part of your web project, something like this:

using Hangfire;
//..
public class Startup
{
  public void Configuration(IAppBuilder app)
  {
    GlobalConfiguration.Configuration.UseSqlServerStorage("");
    
    app.UseHangfireDashboard();
    app.UseHangfireServer();
  }
}

You'll then need to implement a custom JobActivator class shown below:

public class UnityJobActivator : JobActivator
{
  private readonly IUnityContainer hangfireContainer;
  
  public UnityJobActivator(IUnityContainer hangfireContainer)
  {
    this.hangfireContainer = hangfireContainer;
    this.hangfireContainer
       	.RegisterType(new PerResolveLifetimeManager());
      //don't forget to register child dependencies as well
  }
  
  public override object ActivateJob(Type type)
  {
    return hangfireContainer.Resolve(type);
  }
}

Then modify your OWIN startup class to tell Hangfire to use the custom job activator:

using Hangfire;
//..
public class Startup
{
  public void Configuration(IAppBuilder app)
  {
    GlobalConfiguration.Configuration.UseSqlServerStorage("");
    
    var hangfireContainer = new UnityContainer();
    GlobalConfiguration.Configuration.UseActivator(new UnityJobActivator(hangfireContainer));
    
    app.UseHangfireDashboard();
    app.UseHangfireServer();
  }
}

You can then make use of Hangfire's task scheduling code as normal:

BackgroundJob.Enqueue(myService => myService.method("my JSON object"));

Some things to take note of:

Hangfire can only resolve a concrete implementation when scheduling a worker, note the use of .Enqueue(...), not .Enqueue(...). MyService's dependencies will resolve like normal, allowing the use of interface resolutions.
Hangfire needs to have it's own container with dependencies registered independently of the global UnityContainer. The reason for this is twofold; Hangfire's dependencies need to be registered with the PerResolveLifetimeManager lifetime manager. This is so that you don't get concurrency issues between workers that have resolved a dependency to the same instance. For example; with the normal HierarchicalLifetimeManager, two workers needing the same repository dependency may resolve to the same instance and share a common db context. The workers are meant to each have their own db contexts. Secondly, when the OWIN bootstrapper is run, the global UnityContainer may or may not be initialised yet and Hangfire is unable to take in a reference to the container. So giving Hangfire it's own managed container is a clear separation of purpose and behaviour in how our dependencies are resolved.
You can choose to set up Hangfire without the OWIN startup class and achieve the same dependency injection behaviour, however the functionality is marked by Hangfire as deprecated.