Universal.Operative.Sdk.Scheduling 1.2.0

There is a newer version of this package available.
See the version list below for details.
dotnet add package Universal.Operative.Sdk.Scheduling --version 1.2.0
                    
NuGet\Install-Package Universal.Operative.Sdk.Scheduling -Version 1.2.0
                    
This command is intended to be used within the Package Manager Console in Visual Studio, as it uses the NuGet module's version of Install-Package.
<PackageReference Include="Universal.Operative.Sdk.Scheduling" Version="1.2.0" />
                    
For projects that support PackageReference, copy this XML node into the project file to reference the package.
<PackageVersion Include="Universal.Operative.Sdk.Scheduling" Version="1.2.0" />
                    
Directory.Packages.props
<PackageReference Include="Universal.Operative.Sdk.Scheduling" />
                    
Project file
For projects that support Central Package Management (CPM), copy this XML node into the solution Directory.Packages.props file to version the package.
paket add Universal.Operative.Sdk.Scheduling --version 1.2.0
                    
#r "nuget: Universal.Operative.Sdk.Scheduling, 1.2.0"
                    
#r directive can be used in F# Interactive and Polyglot Notebooks. Copy this into the interactive tool or source code of the script to reference the package.
#:package Universal.Operative.Sdk.Scheduling@1.2.0
                    
#:package directive can be used in C# file-based apps starting in .NET 10 preview 4. Copy this into a .cs file before any lines of code to reference the package.
#addin nuget:?package=Universal.Operative.Sdk.Scheduling&version=1.2.0
                    
Install as a Cake Addin
#tool nuget:?package=Universal.Operative.Sdk.Scheduling&version=1.2.0
                    
Install as a Cake Tool

About

Universal.Operative.Sdk.Scheduling schedules a prompt to be enqueued into an Universal.Operative.Sdk IOperative at a future time, either once or on a recurring cron schedule, whether or not the host process is running when it fires.

  • ScheduleCreateTool / ScheduleListTool / ScheduleCancelTool (SchedulerTools.Create) — the model-facing surface. Backed by a shared IScheduleStore.
  • InMemoryScheduleStore / FileScheduleStore + SchedulerRuntime — the common case: schedules that only need to survive while this process (or one already supervised to restart, e.g. a systemd service or Windows Service) is running. SchedulerRuntime ticks the store and fires due schedules through an IScheduleTrigger.
  • ScheduleTriggerHandler — turns a fired schedule into a submitted IOperative message. The same seam both the in-process runtime and any out-of-process trigger (an OS-scheduled task hitting a host's loopback HTTP endpoint) resolve to.
  • IDurableScheduleBackend (WindowsTaskSchedulerBackend, SystemdTimerBackend, CrontabBackend) — for schedules that must survive the host process itself not running at all: registers with the OS's own scheduler. The OS-level entry only ever carries the schedule's opaque id, never its prompt text — the trigger endpoint resolves id → prompt from the store at fire time, so a schedule's content never has to be safe as a shell/command-line/unit-file argument.

How to Use

Installation

dotnet add package Universal.Operative.Sdk.Scheduling

The common case: in-process, no restart needed

using Universal.Operative.Sdk.Scheduling;

var setup = new SchedulingSetup(); // fresh InMemoryScheduleStore; pass a FileScheduleStore(path) to survive a restart

IOperative operative = engineBuilder
    .AddBaselineTools()
    .AddSchedulerTools(setup)
    .BuildOperative(conversation);

SchedulerRuntime runtime = operative.StartScheduler(setup);

Two calls, not one, because of a real chicken/egg: AddSchedulerTools registers the tools before the engine (and so the IOperative) exists, but firing a schedule needs that same IOperative to submit into -- a tool can't close over something built after it. StartScheduler is the second half, wired once the operative is real. Construct one SchedulingSetup and pass that same instance to both calls; StartScheduler checks this and throws immediately if it's ever given a setup AddSchedulerTools never saw, rather than silently watching a store nothing writes to.

Durable, host-not-running-at-all case

IDurableScheduleBackend backend = IDurableScheduleBackend.ForCurrentPlatform(); // Windows/Linux/other -> the matching backend

var setup = new SchedulingSetup(durableBackend: backend);

IOperative operative = engineBuilder.AddSchedulerTools(setup).BuildOperative(conversation);

TriggerCommand trigger = TriggerCommands.Curl(new Uri("http://127.0.0.1:5099/schedule/trigger"), sharedSecret: "...");
await backend.RegisterAsync(schedule, trigger);

The host is responsible for the loopback HTTP endpoint itself and for calling ScheduleTriggerHandler.FireAsync when it receives a hit — this package doesn't take a web-framework dependency to provide one. TriggerCommand isn't curl-specific either: TriggerCommands.Curl(...) is just a convenience factory — construct one directly (any executable + arguments) to fire something else entirely.

Passing a durableBackend on SchedulingSetup gets you, for free:

  • ScheduleCancel unregisters both places — the logical record and the OS-level registration, not just the former.
  • ScheduleList reports durablyRegistered: true/false per schedule, plus an orphanedDurableIds array for OS-level registrations with no matching schedule left in the store (e.g. an InMemoryScheduleStore that didn't survive a restart the OS registration did) — these will still fire, hitting the trigger endpoint with an id nothing can resolve a prompt for.

Every backend's naming is overridable via its constructor (WindowsTaskSchedulerBackend(taskFolder:), SystemdTimerBackend(unitDirectory:, unitPrefix:), CrontabBackend(markerPrefix:)) — set these if more than one app on the same machine uses this package, so their registrations, and their ListAsync results, don't collide. Constructing one directly on the wrong OS throws PlatformNotSupportedException immediately rather than failing later at RegisterAsync.

License

Free for noncommercial use under the Universal.Operative Noncommercial License. Source is closed; commercial use requires a separate license from Andrew Ong.

Product Compatible and additional computed target framework versions.
.NET net10.0 is compatible.  net10.0-android was computed.  net10.0-browser was computed.  net10.0-ios was computed.  net10.0-maccatalyst was computed.  net10.0-macos was computed.  net10.0-tvos was computed.  net10.0-windows was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

NuGet packages

This package is not used by any NuGet packages.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last Updated
2.2.0 83 8/12/2026
2.1.1 111 8/5/2026
2.1.0 103 7/29/2026
2.0.0 102 7/29/2026
1.2.0 91 7/28/2026
1.1.0 90 7/28/2026
1.0.0 99 7/27/2026

1.2.0 — Updated for Universal.Operative.Sdk 4.0.0: ToolDefinition.Parameters is now Universal.Common.Json.JsonSchema instead of JsonElement.