Class QuartzSchedulerBuilder

Namespace

Quartz

Assembly

Quartz.dll

Builds a scheduler without an application-supplied dependency injection container.

public sealed class QuartzSchedulerBuilder

Inheritance

object

QuartzSchedulerBuilder

Inherited Members

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.GetType()

object.ReferenceEquals(object, object)

object.ToString()

Examples

IScheduler scheduler = await QuartzSchedulerBuilder
    .Create(q => q
        .ConfigureScheduler(options => options.InstanceName = "reporting")
        .UseDefaultThreadPool(maxConcurrency: 20)
        .UseInMemoryStore())
    .BuildScheduler();

Remarks

Console applications, tests and anything else without a host use this instead of registering Quartz into their own container. It is not a second configuration API: Create(Action<IQuartzBuilder>?) hands the callback an IQuartzBuilder, the very one AddQuartz(q => …) hands out, over a container it creates itself. The two paths are the same call written around a different receiver, so whatever works under a host works here and they cannot drift apart — there is one set of members to keep in step, and this type re-declares none of them.

What it adds is what a standalone caller needs and a host already has: the terminal methods Build() and BuildScheduler(CancellationToken), and the two ways to say where configuration comes from when it does not come from code — UseProperties(NameValueCollection) and UseConfiguration(IConfiguration).

The builder owns the IServiceProvider it creates and disposes it when the returned factory is disposed, so callers that never dispose behave exactly as they did with the old process-lifetime scheduler.

Methods

Build()

Builds the scheduler factory, along with the container backing it.

public StandaloneSchedulerFactory Build()

Returns

StandaloneSchedulerFactory

Remarks

The returned factory owns that container, so disposing it shuts the scheduler down and disposes everything the container built. See StandaloneSchedulerFactory.

BuildScheduler(CancellationToken)

Builds the scheduler.

public ValueTask<IScheduler> BuildScheduler(CancellationToken cancellationToken = default)

Parameters

cancellationToken CancellationToken

Returns

ValueTask<IScheduler>

Remarks

The factory that owns the container is dropped, so the container outlives every reference to it: shutting this scheduler down is still Shutdown(bool, CancellationToken), but nothing will ever dispose what built it. That is the right trade for a scheduler that lives as long as the process and the wrong one for anything shorter-lived — use Build() and keep the factory there.

Create(Action<IQuartzBuilder>?)

Creates a new builder and configures the scheduler it will build.

public static QuartzSchedulerBuilder Create(Action<IQuartzBuilder>? configure = null)

Parameters

configure Action<IQuartzBuilder>

Configures the scheduler.

Returns

QuartzSchedulerBuilder

Remarks

The callback is the same one AddQuartz takes, and it runs immediately, as it does there. Leaving it out describes a scheduler that is configured entirely by UseProperties(NameValueCollection) or UseConfiguration(IConfiguration) — again as AddQuartz() does — and the defaults answer for anything neither of those mentions.

UseConfiguration(IConfiguration)

Configures the scheduler from a configuration section, the standalone counterpart of AddQuartz(configuration).

public QuartzSchedulerBuilder UseConfiguration(IConfiguration configuration)

Parameters

configuration IConfiguration

The Quartz configuration section, typically configuration.GetSection("Quartz").

Returns

QuartzSchedulerBuilder

Remarks

The section is read exactly as it is under a host: hierarchical sections such as Scheduler and ThreadPool bind onto the typed options, a Schedule section becomes jobs and triggers, and flat quartz.* keys still mean what they always did. There is no flattening step for a caller to write.

Configuration written in code wins, as it does everywhere else: the section is applied before anything Create(Action<IQuartzBuilder>?) was told.

UseProperties(IEnumerable<KeyValuePair<string, string?>>)

Configures the scheduler from flat quartz.* property keys.

public QuartzSchedulerBuilder UseProperties(IEnumerable<KeyValuePair<string, string?>> properties)

Parameters

properties IEnumerable<KeyValuePair<string, string>>

The flat quartz.* properties.

Returns

QuartzSchedulerBuilder

Remarks

This is the code-free path a properties file or an environment-derived bag takes, and the standalone counterpart of AddQuartz(properties). The keys are translated into the same typed options and registrations everything else produces, so a scheduler configured this way is the same scheduler.

The parameter is the shape every dictionary already has, so a Dictionary<TKey, TValue>, an IReadOnlyDictionary<TKey, TValue> and Properties all go in without a conversion step.

Configuration written in code wins, whichever order the two are applied in: values from the properties are applied before anything Create(Action<IQuartzBuilder>?) was told, and implementations they name are registered after — registration being first-wins and configuration last-wins.

Keys are checked against the ones Quartz reads, so a misspelling is reported rather than silently ignored. Set quartz.checkConfiguration to false to allow keys of your own.

UseProperties(NameValueCollection)

Configures the scheduler from flat quartz.* property keys held in a NameValueCollection.

public QuartzSchedulerBuilder UseProperties(NameValueCollection properties)

Parameters

properties NameValueCollection

The flat quartz.* properties.

Returns

QuartzSchedulerBuilder

Remarks

A NameValueCollection is what a caller migrating from 3.x already holds — it is what StdSchedulerFactory took — so it stays a single call. Everything else about it is UseProperties(IEnumerable<KeyValuePair<string, string?>>), which this forwards to.