Stratara.EventSourcing.EntityFrameworkCore 3.2.2

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

Stratara.EventSourcing.EntityFrameworkCore

License: MIT.

EF Core persistence for the Stratara event-sourced stack — PostgreSQL flavoured via Npgsql + pgvector. Bundles four previously-separate Stratara projects into one NuGet because they always ship together:

Folder Contents Old csproj
EntityFrameworkCore/ shared EF conventions, value generators, IDbContext / IReadDbContext / IWriteDbContext / ITenantScopedDbContext / IIdentityDbContext, UnitOfWork base, DefaultDbResolver, NpgsqlDbContextServiceCollectionExtensions, DbContextMigrationUtility Stratara.EntityFrameworkCore
WriteStore/ WriteDbContext, WriteUnitOfWork, event-stream/snapshot/event-chain/command-audit/outbox repositories + entity configurations Stratara.EventSourcing.EntityFrameworkCore.WriteStore
ReadStore/ ReadDbContext, ReadUnitOfWork, ProjectionsUnitOfWork, Tenant repository, projection entity configurations Stratara.EventSourcing.EntityFrameworkCore.ReadStore
IdentityStore/ Generic ASP.NET Identity IdentityDbContext + marker Stratara.EventSourcing.EntityFrameworkCore.IdentityStore

Everything lives under Stratara.EventSourcing.EntityFrameworkCore and its sub-namespaces (.WriteStore, .ReadStore, .IdentityStore, .Abstractions, .Conventions, .Extensions, .HealthChecks, .Migration). The DI extensions sit in Microsoft.Extensions.DependencyInjection, per the Microsoft convention, so they resolve without an extra using.

Why folded

WriteStore-without-ReadStore is not a real use case. EF conventions + value generators + UnitOfWork primitives are foundational for every other store. ASP.NET Identity glue follows the same EF Core conventions. Splitting into 4 NuGets that always ship together adds version-management noise (4× <PackageVersion> to keep in sync, transitive-resolution risk) without any consumer benefit.

If your application doesn't use ASP.NET Identity, simply don't reference IdentityDbContext-derived types — the rest of the package works without them.

Quick start

Derive your contexts from the generic base classes — the type argument is the context itself:

using Stratara.EventSourcing.EntityFrameworkCore.WriteStore;
using Stratara.EventSourcing.EntityFrameworkCore.ReadStore;

public sealed class MyAppWriteDbContext(DbContextOptions<MyAppWriteDbContext> options)
    : WriteDbContext<MyAppWriteDbContext>(options);

public sealed class MyAppReadDbContext(DbContextOptions<MyAppReadDbContext> options)
    : ReadDbContext<MyAppReadDbContext>(options);

Then register the Npgsql context factories and the write store:

// In your AppHost / Worker / Web project:
builder.Services
    .AddNpgsqlWriteDbContextFactory<MyAppWriteDbContext>()
    .AddNpgsqlReadDbContextFactory<MyAppReadDbContext>()
    .AddWriteStore(builder.Configuration);                    // binds Stratara:EventSourcing options

Most hosts don't call these directly — the worker composites in Stratara.EventSourcing.WorkerDefaults (AddCommandWorkerServices(), AddEventProjectionWorkerServices(), …) already compose AddWriteStore for you. Reach for the explicit form when you build a host that none of the composites fit.

Renamed in 3.2.0: the write-side factory was AddNpsqlWriteDbContextFactory (missing the g) through 3.1.x. The correctly-spelled AddNpgsqlWriteDbContextFactory is now the canonical name; the old spelling still compiles as an [Obsolete] alias and will be removed in the next major version.

Health checks

Two opt-in readiness checks plug into any IHealthChecksBuilder (they require the write store above to be registered):

builder.Services.AddHealthChecks()
    .AddEventStoreHealthCheck()                                  // write-side DB reachable?
    .AddOutboxHealthCheck(degradedThreshold: 1_000,             // outbox backlog depth
                          unhealthyThreshold: 10_000);
  • AddEventStoreHealthCheck() — probes write-store connectivity; Unhealthy when the database cannot be reached.
  • AddOutboxHealthCheck(degradedThreshold?, unhealthyThreshold?) — reports the pending outbox backlog under the pending data key and escalates to Degraded / Unhealthy when the count crosses the supplied thresholds (omit them to stay healthy while reachable).

Both are tagged ready by default, so they show up on a readiness endpoint rather than the liveness (live) one.

Dependencies

  • Stratara.Projections — for projection types used by ProjectionsUnitOfWork.
  • Stratara.Shared — for diagnostics + abstractions + resilience.
  • Npgsql.EntityFrameworkCore.PostgreSQL, EFCore.NamingConventions, Microsoft.AspNetCore.Identity.EntityFrameworkCore, Microsoft.EntityFrameworkCore, Microsoft.Extensions.Diagnostics.HealthChecks, Pgvector.EntityFrameworkCore.
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.EventSourcing.EntityFrameworkCore:

Package Downloads
Stratara.Infrastructure

Infrastructure glue for the Stratara framework — authorization decorators, configuration providers, and DI composition helpers that wire Mediator, Outbox, Identity, and EF Core into a hosted app.

Stratara.EventSourcing.WorkerDefaults

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

Stratara.Testing.EntityFrameworkCore

Spin up the real Stratara event-sourcing write stack (EventSource, aggregation, snapshots, the EF Core write store) against a shared in-memory SQLite database in one call — production code paths, no Postgres, no Docker. Builds on Stratara.Testing's in-memory doubles.

GitHub repositories

This package is not used by any popular GitHub repositories.

Version Downloads Last Updated
3.2.2 53 8/14/2026
3.2.1 125 8/2/2026
3.2.0 142 7/18/2026
3.1.7 143 7/1/2026
3.1.6 562 6/22/2026
3.1.5 148 6/22/2026
3.1.4 157 6/15/2026
3.1.3 149 6/10/2026
3.1.2 165 6/5/2026
3.1.1 229 6/1/2026
3.1.0 132 5/30/2026
3.0.23 137 5/28/2026

API keys can now be bootstrapped. Issuance always generated the key itself, which does not fit the
setups where server and caller have to share a key *before* either starts — container orchestration,
CI provisioning, self-hosted bundles, end-to-end test hosts. This release adds an import path for a
key the caller already holds, plus the canonical key format as public API so callers generate values
instead of inventing them.

### Added

- **`IApiKeyStore.ImportAsync` — store a machine key whose raw value the caller already holds.**
 Issuance generates the key itself, which is the wrong shape when server and caller must share it
 *before* either boots: container orchestration, CI provisioning, self-hosted bundles, end-to-end
 test hosts. Without this path, consumers bypassed the store and reimplemented its internals (the
 digest format and the machine-key membership row) — a copy that keeps compiling after the store
 changes and fails as a runtime 401. Import is idempotent, so it can run unconditionally on every
 boot: a value that is already stored returns the existing descriptor and the stored key is never
 mutated, so a changed configuration cannot escalate a key's roles or extend its expiry unnoticed.
 Revoked, expired, and foreign-tenant values are rejected rather than silently adopted, and
 concurrent replicas racing the same first import converge on one key. Machine keys only —
 `ApiKeyImportRequest` carries no `UserId`.
- **`ApiKeyFormat` (`Stratara.Abstractions.ApiKeys`) — the canonical raw-key format as public API.**
 `CreateRawKey()` generates `stk_` plus the Base64Url encoding of 32 CSPRNG bytes; `IsWellFormed()`
 checks that shape. `ImportAsync` accepts only well-formed values: the store keeps its stored
 digest unsalted because a generated key carries 256 bits of entropy, and a hand-picked value would
 quietly invalidate that. Generate keys out of band with `CreateRawKey()` and keep them in a secret
 store — the type lives in the abstractions package so host-builder and orchestration projects can
 reach it without referencing the storage implementation.
- **`InMemoryApiKeyStore` (`Stratara.Testing`) — the drop-in double for the API-key store**,
 mirroring issuance, import, fail-closed validation, revocation, and the erasure sweeps, and
 materializing machine keys into a membership store you can share and inspect.

### Changed

- **API-key lifecycle events are now logged** (`Stratara.Diagnostics` event-ID range 116_000):
 import, idempotent repeat, and a repeat that supplied different parameters. Key ids and tenant
 ids only — never the raw key or its digest.
- **For implementers of `IApiKeyStore`:** the interface gained `ImportAsync`. Custom implementations
 need the new member; callers are unaffected.