Feature Request: Provide a configuration section Type and support for RecurringJobs.AddOrUpdate to load from IConfiguration + SectionName

[bhehe]

As I've worked with Hangfire recently to implement a new project, we've invented our own 'configuration section' type to express the details around a recurring job (display name, cron, etc.) We then have our own helper code that loads the section from a named configuration section/path and then passes the values into the appropriate method arguments for RecurringJobs.AddOrUpdate(..)

It would be nice if there was an "official" configuration section type we could leverage for these needs and a method signature on RecurringJobs.AddOrUpdate that would look something like the following:

RecurringJobs.AddOrUpdate(OfficialHangfireRecurringJobRegistrationType registration, Expression < Action > methodCall) + RecurringJobs.AddOrUpdate(IConfiguration configuration, string configSectionPathName, Expression < Action > methodCall)

Ideally, Hangfire would then know if there's any appropriate handling such as use of Options < T > approaches to handle any refreshing when configuration values change (if changes after startup are even something that could be supported).

I would much rather use something official than something we've built in-house as then it would stay up-to-date with any features or behaviors that were added. I.e. the related Feature Request I created as issue #2018

[andrekiba]

Hello @bhehe, exploring the same problem I would be interested in the way you tried to provide options for each job. Starting from a json ideally I want to schedule all the recurring jobs (each one with it's own config, using IOptions<T> pattern) dynamically (scanning with reflection and eventually registering what I need in the DI container).

[bhehe]

@andrekiba - My approach leans on the use of a 'bootstrap' helper that ensures I have an IConfiguration available BEFORE / WHILE building up the generic host and configuring the services/dependencies. In my case, we implemented a 'BootstrapContext' which is then provided by a 'BootstrapContextBuilder' to encapsulate all of the supporting code.

The context/builder then gives me an initial logger, configuration and even a service collection/provider to let me do some DI as part of the actual bootstrap/startup process and configuring the host. Using the IConfiguration, I then just load a 'RecurringJobConfiguration' from the IConfiguration for each job.

The boostrap DI angle comes into play in that we also created an IRecurringJobRegistration type that is then scanned/discovered by Scrutor and registered with the bootstrap version of the service collection and during the configuration of Hangfire (after the backing storage has been configured) we 'resolve' all instances of that job registration type and invoke a simple RegistrerJob() method that internally calls the AddOrUpdateJob(..) method from Hangfire itself - passing in arguments from the associated configuration section each of the registration helper/components reference.