Class QuartzAspireSettings

Namespace

Quartz

Assembly

Quartz.Aspire.dll

The settings AddQuartzPersistentStore(IHostApplicationBuilder, string, Action<QuartzAspireSettings>?) reads, bound from Aspire:Quartz and then from Aspire:Quartz:<connection name> over it.

public sealed class QuartzAspireSettings

Inheritance

object

QuartzAspireSettings

Inherited Members

object.Equals(object)

object.Equals(object, object)

object.GetHashCode()

object.GetType()

object.ReferenceEquals(object, object)

object.ToString()

Remarks

The two-section shape is the one every Aspire client integration has: the outer section carries what is true of every connection in the application, and the inner one — named after the connection — overrides it for that connection alone. An application with a single database never writes the inner one.

Everything here is deliberately small. This type is not a second spelling of Quartz's own configuration: Quartz:JobStore, Quartz:Scheduler and the rest still say what they always said, and AddQuartz still reads them. What these settings decide is the handful of things that follow from an Aspire connection — which database it is, and whether the signals that come with it are wired — because that is what a connection name is evidence of.

Properties

Clustered

Whether this scheduler takes part in a cluster with every other scheduler sharing the database.

public bool Clustered { get; set; }

Property Value

bool

Remarks

Aspire makes replicas cheap — WithReplicas(2) is one call — and two schedulers on one database that are not clustered will both fire every trigger. Turning this on turns database locking on with it, as UseClustering() always has.

It also makes the scheduler derive its InstanceId, because a cluster needs distinct ids and a replica set has none of its own to borrow: a node recognises its own check-in row and its own fired triggers by that id, and every replica starts life carrying DefaultInstanceId — NON_CLUSTERED. An application that already set GenerateInstanceId, or that named its nodes by setting InstanceId, keeps what it said; this only fills the gap.

ConnectionString

The connection string reaching the database, when it is not the one Aspire injected.

public string? ConnectionString { get; set; }

Property Value

string

Remarks

Left unset, ConnectionStrings:<connection name> supplies it — which is the environment variable the AppHost's WithReference sets, so an application under Aspire never writes this. It matters for the value that decides the provider: the string is read at configuration time whether or not the store ends up using it, because its shape is what says which database this is.

DisableHealthChecks

Whether the scheduler's health check is left unregistered.

public bool DisableHealthChecks { get; set; }

Property Value

bool

Remarks

The check is AddQuartzHealthChecks() from the core package, registered on the same IHealthChecksBuilder an Aspire ServiceDefaults project put its own self check on, so MapDefaultEndpoints() serves both.

DisableMetrics

Whether Quartz's Meter is left unsubscribed.

public bool DisableMetrics { get; set; }

Property Value

bool

Remarks

Subscribing is AddSource(QuartzInstrumentation.ActivitySourceName) on the application's existing tracer provider. No exporter is added — a ServiceDefaults project already owns that, and UseOtlpExporter() may be called only once.

DisableTracing

Whether Quartz's ActivitySource is left unsubscribed.

public bool DisableTracing { get; set; }

Property Value

bool

Remarks

Subscribing is AddSource(QuartzInstrumentation.ActivitySourceName) on the application's existing tracer provider. No exporter is added — a ServiceDefaults project already owns that, and UseOtlpExporter() may be called only once.

Provider

Which ADO.NET driver reaches the database, as one of the names on DataSourceOptions.Providers.

public string? Provider { get; set; }

Property Value

string

Remarks

Left unset, it is inferred from the connection string's shape. The inference recognises the five shapes Aspire's own database resources produce and throws for anything it cannot place — a guess would choose the driver delegate that writes the SQL, and SQL the database cannot run is a worse outcome than a startup failure that names this property.

Three of the shipped provider names are never inferred, because nothing in a connection string distinguishes them: MySql from MySqlConnector, SQLite from SQLite-Microsoft, and Firebird from a connection string that looks like several others. Naming one here is how an application chooses.

A name Quartz ships no description for is still usable: it selects the generic SQL dialect, and whatever DbMetadataFactory the application registered describes the driver.

SchedulerName

Which scheduler this store belongs to, for an application that registers more than one.

public string? SchedulerName { get; set; }

Property Value

string

Remarks

Left unset, every scheduler in the container gets this store — which is right for the single scheduler an application normally has, and wrong the moment two of them talk to two databases. The name is the one passed to AddQuartz(name, …), because a string means a scheduler everywhere in Quartz.

SchemaProvisioning

What the store does about its schema when the scheduler starts.

public SchemaProvisioning? SchemaProvisioning { get; set; }

Property Value

SchemaProvisioning?

Remarks

The same three-valued decision AdoJobStoreOptions.SchemaProvisioning and IPersistentStoreBuilder.ProvisionSchema() speak, said from the Aspire section instead: one vocabulary for one setting, whichever end an application reaches it from.

Left unset — the default — the environment decides, read from Environment at the AddQuartzPersistentStore call: CreateIfMissing under Development, and nothing said everywhere else. The two halves of that are the same observation from opposite ends — the AppHost's database container comes up empty on every start that has no data volume behind it, so a development scheduler that refuses to start until somebody applies a script is refusing on every first run; and a production account usually cannot run DDL at all, which it is right not to be able to.

Set, it applies in every environment — which is what a deployment that applies its own schema wants to say once, in the shared Aspire:Quartz section, rather than per environment. CreateIfMissing only ever creates: no object is altered and none is dropped, so it cannot turn a mis-typed TablePrefix into data loss, and it is equally not an upgrade — database/migrations/ is still what moves a schema forward. None is the one thing the old bool could not say: skip the startup check entirely.

It fills a gap rather than overruling one. An AdoJobStoreOptions.SchemaProvisioning the application set itself — from ConfigureStore or from Quartz:JobStore:SchemaProvisioning — is a decision made about this store in particular and is kept, so this is read only by a store that was told nothing. That is also why Validate here means "leave it alone": it is what an unconfigured store already holds, so writing it changes nothing, and it is how a Development application declines the creating default.

TablePrefix

The prefix on the Quartz table names, when the schema was created with something other than QRTZ_.

public string? TablePrefix { get; set; }

Property Value

string

Remarks

Left unset, AdoJobStoreOptions.TablePrefix keeps whatever it already had — its own default, or a value Quartz:JobStore:TablePrefix set.