Thanks for the great answer, Lucas!
In my case, the scheduling is very simple, and I’m not doing any dependency injection. So basically, the easiest way to do it is
- One application running the Dashboard
- One application per job, acting as both client and server, with its own queue. Optionally, one of these applications could run the dashboard.
Yes?
The dashboard just need to be connected to the Hangfire database.
I was under the impression that, in order to manually trigger or retry jobs via the Dashboard, the dashboard application needed to know about the job somehow (like the job’s interface). Is that not the case?
The Dashboard could run on any of those applications, or in all, or even in another one.
In all of them? Wouldn’t that result in each job having its own dashboard, instead of all jobs sharing a single dashboard?
I’ll try it out and report back with my results. Thanks again for the help. 
Edit: Yeah, I have one application acting as Dashboard+Client+Server for job A in queue_a, and another application acting as Client+Server for another job B in queue_b. Job B executes fine, using the right server, but the dashboard says “Cannot find target method” for the name of the job, doesn’t show its arguments, and you can’t manually requeue the job. Looks like the application running the dashboard should know about every job.
I’d guess this should be accomplished by putting each job’s interface in an assembly referenced by the dashboard project, and then I think I need to use IoC containers, don’t I? That seems more complicated than I’d like. At that point would it be easier to have every job compiled into a DLL, and have a single application acting as Dashboard+Client+Server that references them all?