Stratara.Projections 4.4.8

Prefix Reserved
There is a newer version of this package available.
See the version list below for details.
dotnet add package Stratara.Projections --version 4.4.8
                    
NuGet\Install-Package Stratara.Projections -Version 4.4.8
                    
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="Stratara.Projections" Version="4.4.8" />
                    
For projects that support PackageReference, copy this XML node into the project file to reference the package.
<PackageVersion Include="Stratara.Projections" Version="4.4.8" />
                    
Directory.Packages.props
<PackageReference Include="Stratara.Projections" />
                    
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 Stratara.Projections --version 4.4.8
                    
#r "nuget: Stratara.Projections, 4.4.8"
                    
#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 Stratara.Projections@4.4.8
                    
#: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=Stratara.Projections&version=4.4.8
                    
Install as a Cake Addin
#tool nuget:?package=Stratara.Projections&version=4.4.8
                    
Install as a Cake Tool

Stratara.Projections

Derived. The behaviour described here is specified under openspec/specs/. Those specifications are the source; this page explains and illustrates them.

License: MIT.

Projection runtime for the Stratara event-sourced stack. Discovers IProjection implementations in the consumer's application assemblies, dispatches event bundles to them, and applies the resulting change sets atomically via the read-model repository layer.

What's in the box

Folder Contents
Services/ The runtime, all internal: ProjectionManager (event-bundle → matching projection-handlers fan-out), ProjectionHandler (invokes a projection's matching methods), ProjectionMethodInvoker (reflection-cached method-pointer dispatch into consumer projections). You implement IProjection; these drive it
Abstractions/ IProjection and its refinements: IRebuildableProjection (can be rebuilt alone on the Orleans execution model) and IForgetsDeletedTenants (a fact recorded for a tenant after its deletion is passed over instead of failing the projection; the record is kept by IForgottenTenantStore, which the read store provides), and IReadModelPreservation (lets a failed replay restore the read models it emptied; the PostgreSQL implementation comes with AddReadModelRestore<TReadContext>())
Multitenancy/ TenantProjection — the framework's own opinionated tenant aggregate projection. Skip the registration if your application has its own tenancy model
Diagnostics/Extensions/ Source-generated LoggerProjectionExtensions, LoggerChangeSetExtensions, LoggerUpdateExtensions — typed [LoggerMessage] surfaces under the Stratara.Projection.* / Stratara.ChangeSet.* / Stratara.Update.* event-ID bands

Quick start

// In your EventProjection worker:
builder.Services
    .AddProjectionWorker(builder.Configuration)                       // the runtime + hosted service
    .AddProjectionsFromAssemblyContaining<MyAppProjectionMarker>();   // your IProjection implementations

Then implement IProjection in your application assembly. The projection manager picks them up automatically.

Both calls are needed: AddProjectionsFromAssemblyContaining<T>() only registers your projections — AddProjectionWorker(IConfiguration) registers the manager, the invoker and the hosted service that consumes the event-bundle subscription. Without it nothing drives your projections. Most hosts get both from the AddEventProjectionWorkerServices() composite in Stratara.EventSourcing.WorkerDefaults.

No checkpoint store. Projections are driven push-wise off the event bus; the framework keeps no per-projection checkpoint, so there is no consumer-lag metric and no built-in resume-from-sequence. Replay is coordinated separately (see Stratara.Outbox.RabbitMQ's replay state).

Dependencies

  • Stratara.Contracts — for EventBundle + IEvent<T>.
  • Stratara.Domain — for the framework's Tenant aggregate (only consumed by TenantProjection).
  • Stratara.Shared — for change-tracking primitives, reflection cache, partitioning helpers, diagnostics base.
  • Microsoft.Extensions.Hosting.Abstractions + Microsoft.Extensions.Options.ConfigurationExtensions — for projection-worker checkpointing options.
  • JetBrains.Annotations — for static-analysis attributes on projection-handler conventions.
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 (3)

Showing the top 3 NuGet packages that depend on Stratara.Projections:

Package Downloads
Stratara.EventSourcing.EntityFrameworkCore

EF Core persistence for the Stratara event-sourced stack on PostgreSQL — write-store, read-store, ASP.NET Identity store — including a shared identity store with its migrations — shared conventions, value generators, and UnitOfWork primitives. Targets Npgsql; maps pgvector types for a model that uses them, and needs no database extension otherwise.

Stratara.EventSourcing.WorkerDefaults

Worker-host wiring composites for the Stratara event-sourced stack. IHostApplicationBuilder extensions (AddBackendServices, AddCommandWorkerServices, AddHeavyCommandWorkerServices, AddEventProjectionWorkerServices, AddEventStreamHashWorkerServices, AddSagaWorkerServices, AddOutboxWorkerServices, and AddCommandServices, AddEventProjectionServices and AddSagaServices without the bus-fed workers) bundle the per-concern DI calls so each worker host opts in with one line.

Stratara.Orleans

The Orleans execution model for the Stratara event-sourced stack — one activation per aggregate across the cluster, commands recorded before the call returns and resumed after a crash, projections and sagas that read the store in commit order from a checkpoint, singleton work, owner-checked durable timers and heavy work bounded across the cluster.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last Updated
4.8.0 168 11/6/2026
4.7.1 139 11/5/2026
4.7.0 596 10/30/2026
4.6.1 164 10/29/2026
4.6.0 230 10/28/2026
4.5.0 320 10/28/2026
4.4.10 266 10/26/2026
4.4.9 172 10/26/2026
4.4.8 319 10/24/2026
4.4.7 172 10/23/2026
4.4.6 279 10/22/2026
4.4.5 365 10/14/2026
4.4.4 347 10/10/2026
4.4.3 181 10/10/2026
4.4.2 443 10/2/2026
4.4.1 432 9/29/2026
4.4.0 186 9/27/2026
4.3.1 191 9/25/2026
4.3.0 353 9/23/2026
4.2.0 230 9/18/2026
Loading failed

A fix for hosts on the Orleans execution model. A store reader that catches up a large backlog and a singleton
work that runs long now answer their keep-alive, so neither leaves reminder errors in the silo's log. A silo that
joins while a singleton work runs long on another silo no longer fails its start. No API change, no schema change
and no migration.

### Fixed

- **A busy store reader or singleton work answers its keep-alive.** On the Orleans execution model, a projection or
 saga reader that caught up a backlog for longer than the runtime's response timeout made its keep-alive tick wait
 behind the catch-up, and Orleans logged `Could not deliver reminder tick` at Error, once per partition and
 keep-alive period. A singleton work whose run outlasted the timeout did the same. Nothing was lost, but a large
 catch-up left dozens of errors on the silo. The keep-alive and the poll now start a catch-up where none is
 running and do not wait for it. A partition is still read by one catch-up at a time, and a commit during a
 catch-up is still applied by it. A singleton work's keep-alive interleaves with its run, and runs still never
 overlap.
- **A silo starts while a singleton work runs long.** A silo that started while a singleton work it registers ran
 longer than the response timeout on another silo waited for that run in its own start. The start then failed
 with a `TimeoutException`. The call a starting silo makes to each singleton work and store reader now
 interleaves, so the start goes on.
- *Operate the Orleans execution model* says that a durable timer whose handler outlasts the response timeout
 still makes Orleans log `Could not deliver reminder tick` for that tick, and that the line says nothing about
 the timer. It also says that, outside a deploy, the line now points to an unreachable store reader or singleton
 work rather than a busy one.