LoomKit.Workflows.Abstractions 10.0.1

dotnet add package LoomKit.Workflows.Abstractions --version 10.0.1
                    
NuGet\Install-Package LoomKit.Workflows.Abstractions -Version 10.0.1
                    
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="LoomKit.Workflows.Abstractions" Version="10.0.1" />
                    
For projects that support PackageReference, copy this XML node into the project file to reference the package.
<PackageVersion Include="LoomKit.Workflows.Abstractions" Version="10.0.1" />
                    
Directory.Packages.props
<PackageReference Include="LoomKit.Workflows.Abstractions" />
                    
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 LoomKit.Workflows.Abstractions --version 10.0.1
                    
#r "nuget: LoomKit.Workflows.Abstractions, 10.0.1"
                    
#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 LoomKit.Workflows.Abstractions@10.0.1
                    
#: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=LoomKit.Workflows.Abstractions&version=10.0.1
                    
Install as a Cake Addin
#tool nuget:?package=LoomKit.Workflows.Abstractions&version=10.0.1
                    
Install as a Cake Tool

LoomKit.Workflows.Abstractions

The interfaces, abstract base types, and models behind LoomKit.Workflows, split into their own lightweight package with no dependency on the concrete workflow manager implementation.

Status: early stage. The public API may still change between versions — pin a commit/tag if you depend on it.

Why a separate package

LoomKit.Workflows ships the whole orchestrator: the in-process queue, the consumer pipeline, retry middleware, DI registration helpers, telemetry, etc. A project that only needs to define activities, handlers, and workflow contexts — typically a domain/DDD class library that shouldn't know how those activities get queued or consumed — doesn't need any of that.

This package holds only:

  • The marker/contract interfaces: IActivity, IActivity<TWorkflowContext>, IActivityHandler<TActivity, TWorkflowContext>, IActivityQueue, IActivityConsumer, IWorkflowManager, IWorkflowManagerSeeder, IWorkflowContext, and the step interfaces (IWorkflowStep<,>, IWorkflowNextStep, IWorkflowForkStep, IWorkflowForkBranch, IWorkflowJoinWaitStep).
  • The models every consumer touches: ActivitySchedule, ActivityStatus, ResumeToken, JoinArrival, and the WorkflowStep<,> hierarchy (WorkflowContinue, WorkflowPause, WorkflowEnd, WorkflowFail, WorkflowFork, WorkflowJoin, WorkflowJoinWait, ForkBranch<>).
  • The event args types raised by a workflow manager: ActivityScheduledEventArgs, ActivityStartedEventArgs, ActivityEndedEventArgs, ActivityExceptionEventArgs.
  • The abstract base types meant to be extended: Activity<TWorkflowContext>, WorkflowContext, ActivityMiddleware<TActivity, TWorkflowContext>, WorkflowManager<TOptions>, WorkflowManagerOptions, WorkflowManagerOptionsBuilder<TOptions>, plus the concrete-but-implementation-free ActivityQueueOptions(Builder) and ActivityConsumerOptions(Builder).

Reference this package from a layer that should only depend on shapes (a domain project defining activities, handlers, and workflow contexts, a library authoring a custom IWorkflowManager/IActivityQueue/ActivityMiddleware, a contracts-only shared project). Reference LoomKit.Workflows — which itself depends on this package — from your application/composition-root layer, where the concrete manager, its DI wiring, and the built-in retry middleware actually get used.

Installation

dotnet add package LoomKit.Workflows.Abstractions

Available on nuget.org — a package version is published automatically for every vX.Y.Z tag pushed to this repo.

If you're building the full orchestrator (queuing and consuming activities, not just defining them), install LoomKit.Workflows instead — it brings this package in transitively.

Contents

Type Kind Purpose
IActivity / IActivity<TWorkflowContext> interface Marker for a workflow activity; the generic form pins its context type.
IActivityHandler<TActivity, TWorkflowContext> interface Implement one per activity type — where the actual logic lives, returning the next IWorkflowStep.
IActivityQueue interface A named queue an activity schedule is enqueued onto and awaited from, including fork/join and resume-token support.
IActivityConsumer interface Pulls activity schedules off a queue and runs them through the handler/middleware pipeline.
IWorkflowManager interface The entry point application code calls: enqueue, list, and remove activity schedules across all queues/consumers.
IWorkflowManagerSeeder interface Implement to seed workflows at manager startup.
IWorkflowContext interface Marker for the state a workflow instance carries between activities.
ActivitySchedule / ActivityStatus model A scheduled occurrence of an activity and its lifecycle timestamps.
WorkflowStep<,> hierarchy model What a handler returns: continue, pause on resume tokens, end, fail, fork, join, or wait for more join arrivals.
ResumeToken / JoinArrival model An externally-triggerable resume point, and one branch's contribution to a fork's join point.
ActivityScheduledEventArgs / ActivityStartedEventArgs / ActivityEndedEventArgs / ActivityExceptionEventArgs model Event args raised by an IWorkflowManager at each lifecycle point.
Activity<TWorkflowContext> / WorkflowContext abstract class Convenience base records that pre-fill the boilerplate members of IActivity/IWorkflowContext.
ActivityMiddleware<TActivity, TWorkflowContext> abstract class Base type for cross-cutting pipeline behavior around a handler.
WorkflowManager<TOptions> abstract class Base type for a custom IWorkflowManager implementation.
WorkflowManagerOptions / WorkflowManagerOptionsBuilder<TOptions> abstract class Base type for a manager's configured options (queues, consumers, seeders) and its fluent builder.
ActivityQueueOptions / ActivityQueueOptionsBuilder class Configured options for a single queue (retry budget, poll interval) and its builder.
ActivityConsumerOptions / ActivityConsumerOptionsBuilder class Configured options for a single consumer (middleware pipeline, DI scope) and its builder, with the open-generic middleware-type validation built in.

None of these types do anything by themselves — see LoomKit.Workflows for the default, ready-to-use implementation (DefaultWorkflowManager, InProcessActivityQueue, ActivityConsumer, AddDefaultWorkflowManager, the built-in retry middleware, tracing, ...) and for usage examples.

License

MIT

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 (1)

Showing the top 1 NuGet packages that depend on LoomKit.Workflows.Abstractions:

Package Downloads
LoomKit.Workflows

A workflow orchestration library for .NET built around a job-queue model: workflows are sequences of activities executed through named queues and consumers, with support for branching, fork/re-join, resume-token-based pausing, retry middleware, and a fully extensible handler pipeline.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last Updated
10.0.1 154 8/25/2026