Hangfire with multiple projects in .net solution

Question

I am looking to implement hangfire into my asp.net web api and asp.net MVC website projects.

The way I have structured my solution is as follows:

Solution - My Solution
1: Model - (Project containing Entity Framework Objects and classes)
2: Services (Where I implement all my> business logic, changes etc.) This is where I will most likely make use of HangFire.

3: Web API (my asp.net api project)
4: Web UI ( mvc 5 Admin interface website)

Both project 3 and 4 make use of the 2:Services project to do work and call services which execute business logic. This is where most tasks will be spun off.

How would I go about implementing hangfire, so that they respective iis sites can both make use of the same "instance" of hangfire. but it will obviously run on the associated app pools?

or maybe it cant work like that and I have to have it running in one place?

What are my options, and furthermore what is the recomendd approach?

Answer 1

The biggest take-away for me was that HangFire will not continue past a work pool shutdown (i.e., idle timeout), which is my core problem anyway, and recommends altering the server configuration to never shut down work pools. If your app is going to be in constant use 24/7, then this shouldn't be an issue for you although your work pool could still be recycled for various reasons, but for an app that will experience peaks and troughs in users then you may want to consider an out-of-process HangFire server.

The approach I'm taking is the later. I'm building a proof-of-concept that has a Windows service (built using Topshelf - highly recommended for this) that hosts the HangFire server (and dashboard), a shared core library, and a client (which will be my WebAPI in production, but is a WPF app for the PoC). The client enqueues a job using a class instance from the shared library, which the HangFire server also has access to.

I'm assuming from your description that the WebAPI controller actions call corresponding methods in class from the service layer? If this is the case, then I would opt for a similar solution to mine, with the HangFire Windows service having access to your services and models as required.

If your app is going to be heavily trafficked and work pool recycles don't bother you, then I'd host the HangFire server in your WebAPI directly.