Quartz.NET: one package, a .NET 10 wall, and docs that stop at install

One package brings the scheduler and its host wiring

Quartz.NET is a job scheduler for .NET, and the packaging is the part worth understanding first. The install section is one line, and the paragraph under it says that dependency injection, hosting, the health check and System.Text.Json serialization all ship in that single package. Optional packages exist, and the project keeps them off this page on purpose: the quick start page on quartz-scheduler.net is where it lists what each one is for. The decision a reader faces is one package for the scheduler itself, then a second round of choices only when the defaults do not fit.

This shape suits a team that already runs a .NET service and needs recurring work on a schedule without adding a second daemon to deploy and watch. It suits that team less if what they want is a cron entry.

4.x refuses every runtime except .NET 10

Quartz.NET 4 targets .NET 10, and nothing else. That sentence is the compatibility policy, and it is the first thing to settle before anything else in this repository. A service on .NET 8, .NET 9 or .NET Framework has no 4.x package to install. The supported path for those runtimes is the 3.x branch, which covers .NET Standard 2.0 and .NET Framework 4.6.2 and later.

Two lines, two runtime floors, and the split is done with branches rather than one source tree. The API reference follows the same split: the 4.x set is regenerated from the XML documentation comments of the shipped packages and rolls forward with every 4.x minor release, while the 3.x set stays parked at /apidoc/3.0. If your runtime moves later, that is an upgrade conversation with two branches in it, and the README carries no migration note between them.

The README stops before the first job fires

Here is where the documentation ends. The README covers runtime compatibility, one install command, where preview builds live, where to ask questions, how to build the source, and the license. It does not show a job class, a trigger, a store configuration key, or a scheduling syntax. The project puts all of that on quartz-scheduler.net, with the 4.x API reference generated from the shipped packages.

For a reader with a real scheduling decision to make, the consequence is concrete. You cannot answer from the repository alone whether job data has to survive serialization end to end, what the defaults do when the host shuts down in the middle of a job, or which store the scheduler reaches for out of the box. An XML comment reference answers shape questions well and policy questions badly. Read the quick start page before committing to the library.

Adding the package, then compiling and testing the source

Installation is the whole command below. The same package brings dependency injection, hosting, the health check and System.Text.Json serialization.

dotnet add package Quartz

The README sends you to the quick start page for the optional packages, and that page, not the repository, is where job registration is documented.

To build the library itself you need the .NET 10 SDK. global.json asks for 10.0.100 and rolls forward to the latest 10.0.x you have installed, so a newer 10.0 patch SDK works.

build.cmd Compile UnitTest

Those two arguments compile and run the unit tests. The integration tests need a running Docker daemon, and CONTRIBUTING.md carries the rest.

./build.sh

On Linux and macOS the same work goes through build.sh. Both scripts restore the Fallout CLI from .config/dotnet-tools.json and hand it your arguments, so nothing has to be installed globally. The argument form is only shown for the Windows script.

Every commit to main publishes a preview package

Beyond the tagged releases on NuGet, preview builds of unreleased main are pushed on every commit and served from the Feedz.io feed at https://f.feedz.io/quartznet/quartznet/nuget/index.json. The released packages sit under the Quartz.NET owner on NuGet.

That feed is useful for one narrow job: pinning to the commit where a fix landed before a tagged release exists. It is also the easiest way to end up on code nobody has versioned, because the README does not say how preview packages are numbered. Treat it as a commit stream rather than a release channel.

On the released side, v4.6.2 was published on 2026-10-26, then v4.6.3 and v4.7.0 on 2026-11-02.

The docs site is a separate VuePress app from the library

The root of the repository holds two projects, and the file names say which is which. package.json is called quartznet-docs, is marked private, and pins a VuePress 2 stack with the bundler-vite and bundler-webpack packages both present. Its scripts cover docs:build, docs:build-webpack, docs:clean, docs:dev, docs:publish, docs:check-links and docs:lint. The docs:publish script initialises a git repository inside docs/.vuepress/dist and force pushes master to the quartznet/quartznet.github.io repository.

The same file ends with apply-patches and a postinstall hook that both run patch-package against a patches/ directory, so patched dependencies land on a contributor's install with no global tool involved. The library side is src/, build/, tools/, Analyzers/, database/ and apidoc/, plus Directory.Packages.props for central versions, Quartz.slnx for the solution, testconfig.json, NuGet.config and quartz.net.snk. The result for a reader: the site you read and the code you clone come out of one tree, so a documentation fix is a pull request here.

Where a timer in your own host would have been enough

This is the case where Quartz.NET is the wrong shape. A job that only has to fire inside one process, on one machine, and can afford to miss a run when the process dies is a few lines in a hosted service, or a task handed to the operating system's own scheduler, with no package, no serialization contract and no API reference to track. Those approaches keep the schedule and the work inside one lifetime, and that is their whole advantage.

Quartz.NET earns its cost when the schedule has to be described as data and outlive the process that registered it. Nothing in the repository documents a rollback or a migration from a hand rolled timer.

Three releases in two days, and an API reference that rolls forward

The repository is not archived and was last pushed on 2026-11-02. The three most recent releases are v4.6.2 on 2026-10-26, then v4.6.3 and v4.7.0 on 2026-11-02. A patch and a minor on the same day is a quick moving line, and the 4.x API reference is generated from the XML documentation comments of the shipped packages and rolls forward with every 4.x minor release instead of being frozen.

Licensing is Apache-2.0, the same terms the license.txt file in the root carries. quartz.net.snk sits beside it, the key file a project uses to strong name sign its assemblies, which matters in shops that enforce signed deployment. No support window per major version appears in the README: the 3.x branch is described neither as deprecated nor as long term.

Editorial conclusion

Adopt Quartz.NET when your scheduled work has to be described as data and survive outside your process, and when your application is already on .NET 10 so the 4.x line is available. Do not adopt it for a single-process timer, and do not count on the README for a migration path: it documents none between the 3.x and 4.x branches. Verify first that your runtime floor clears .NET 10, then read the quick start page on quartz-scheduler.net for the trigger and store settings the README leaves out.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. quartznet/quartznet on GitHub
4. README
5. Releases