Class QuartzAspireHostApplicationBuilderExtensions

Namespace

Quartz

Assembly

Quartz.Aspire.dll

Registers a Quartz persistent job store from an Aspire connection name.

public static class QuartzAspireHostApplicationBuilderExtensions

Inheritance

object

QuartzAspireHostApplicationBuilderExtensions

Inherited Members

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.GetType()

object.MemberwiseClone()

object.ReferenceEquals(object, object)

object.ToString()

Remarks

This is the page how-tos/aspire.md already documented, turned into one call. An Aspire AppHost declares a database and hands the worker its connection string as ConnectionStrings:<name>; everything after that — which driver delegate speaks that database's SQL, whether connections come from a DbDataSource the container holds or from the string itself, whether a development database that came up empty has its tables created, and naming Quartz's two telemetry signals to the pipeline ServiceDefaults built — follows from the name, and is what this does.

It is additive and order-independent. The store is contributed through ConfigureAllQuartzSchedulers, so this may be called before or after AddQuartz and the container comes out the same; the scheduler is still configured by AddQuartz and the Quartz configuration section, and nothing here replaces either. What this call decides is only what an Aspire connection is evidence of.

There is no AddKeyedQuartzPersistentStore, which every other Aspire client integration has. The keyed form exists so that an application can hold two of a thing, and Quartz already has an axis for that which is not the container's: a second scheduler, registered by name with AddQuartz(name, …). SchedulerName is how a second call to this method says which of them it means, so the two databases end up on two schedulers rather than on two keyed copies of one.

Methods

AddQuartzPersistentStore(IHostApplicationBuilder, string, Action<QuartzAspireSettings>?)

Gives every Quartz scheduler in the application a persistent job store on the database Aspire injected under connectionName.

[RequiresUnreferencedCode("The database is chosen from the connection string or from QuartzAspireSettings.Provider, and on the connection-string path Quartz names the driver's connection, command and parameter types as strings, so a trimmed application has no guarantee they survived. Registering a DbDataSource in the container removes that: connections come from it, and only the half of the driver description that names no type is read. Otherwise configure the store directly, with the overload that takes the driver's DbProviderFactory.")]
public static IHostApplicationBuilder AddQuartzPersistentStore(this IHostApplicationBuilder builder, string connectionName, Action<QuartzAspireSettings>? configureSettings = null)

Parameters

builder IHostApplicationBuilder

The host application builder.

connectionName string

The name the AppHost gave the database resource, which is the name its connection string arrives under and the service key a keyed DbDataSource would be registered with.

configureSettings Action<QuartzAspireSettings>

Applied last, over everything configuration said.

Returns

IHostApplicationBuilder

Remarks

The settings are read from Aspire:Quartz, then from Aspire:Quartz:<connectionName> over it, then ConnectionStrings:<connectionName> supplies the connection string when there is one, and configureSettings has the last word.

Where connections come from is decided here, against the services registered so far, so the answer does not depend on when the per-scheduler configuration happens to run. That makes the order of this call and the client integration registering the data source significant, and only that one: register the data source first, as Aspire's own samples do.

Exceptions

SchedulerConfigException

No provider was named and the connection string's shape matches no database, or more than one.