Stratara.Infrastructure 3.1.4

.NET 10.0 This package targets .NET 10.0. The package is compatible with this framework or higher. 
dotnet add package Stratara.Infrastructure --version 3.1.4
                    


                    

                
NuGet\Install-Package Stratara.Infrastructure -Version 3.1.4
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.Infrastructure" Version="3.1.4" />
For projects that support PackageReference, copy this XML node into the project file to reference the package. 
<PackageVersion Include="Stratara.Infrastructure" Version="3.1.4" />
                    


                            Directory.Packages.props
                        

                    

                
<PackageReference Include="Stratara.Infrastructure" />
                    


                            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.Infrastructure --version 3.1.4
                    


                    

                
#r "nuget: Stratara.Infrastructure, 3.1.4"
#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.Infrastructure@3.1.4
#: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.Infrastructure&version=3.1.4
                    


                            Install as a Cake Addin
                        

                    

                
#tool nuget:?package=Stratara.Infrastructure&version=3.1.4
                    


                            Install as a Cake Tool

Stratara.Infrastructure

License: FSL-1.1-MIT (Functional Source License — source-available; converts to MIT after 2 years). Not OSI-approved OSS.

Cross-cutting infrastructure plumbing for the Stratara framework — the Tier-C glue that lets downstream apps wire authorization, DI composition, and worker-stack configuration with a single reference.

Contents

  • Authorization decorators over command-outbox dispatch (AuthorizingCommandOutboxDispatcher).
  • DI composition helpers that wire Mediator, Outbox, Identity, and EFCore into a hosted app.
  • Configuration providers and option binders used by the worker stack.

Dependencies

Transitively depends on Stratara.Contracts, Stratara.EventSourcing.EntityFrameworkCore, Stratara.Mediator, Stratara.Outbox.RabbitMQ, Stratara.Sessions, Stratara.Shared.

Behavioural notes

AddSecurity() — IKeyStore registration (since 3.0.11)

AddSecurity() registers Stratara's security stack including the IKeyStore abstraction. The default is a TryAddSingleton<IKeyStore, DummyKeyStore> fallback — but DummyKeyStore since 3.0.11 throws InvalidOperationException in any environment other than Development (whitelist guard to prevent production data exposure from the demo encryption key). Hosts on Staging, QA, UAT, Preview, or any custom environment must register a real IKeyStore implementation before calling AddSecurity():

// Recommended composition root
if (builder.Environment.IsDevelopment())
{
    builder.Services.AddSecurity();   // DummyKeyStore fallback is fine
}
else
{
    builder.Services.AddSingleton<IKeyStore, AzureKeyVaultKeyStore>();  // or AwsKmsKeyStore, HsmKeyStore, ...
    builder.Services.AddSecurity();
}

KeyStoreStartupProbe logs a Warning (event id LogEvents.KeyManagement.DummyKeyStoreActive = 112_001) at host start when the resolved IKeyStore is DummyKeyStore — even in Development — so an accidental dependency on the dummy is loud rather than silent.

Why the change: Before 3.0.11 the guard only blocked IsProduction(). Hosts in any other environment silently encrypted with the world-known constant pass-phrase "StrataraTestKey" baked into the shipping NuGet — a Staging or QA copy of production data could be decrypted by anyone reading the source. The whitelist guard makes this configuration crash-fast at host build instead of allowing silent data exposure.

AddCaching() — Redis registration

AddCaching() used to delegate to builder.AddRedisClient("redis") from Aspire.StackExchange.Redis. After the Aspire-wrapper removal it registers IConnectionMultiplexer directly via ConnectionMultiplexer.Connect(...) from StackExchange.Redis. The method signature is unchanged, but the Aspire-only side-effects are gone:

  • No automatic Redis health check. Add one explicitly with AddHealthChecks().AddRedis(connectionString) (from AspNetCore.HealthChecks.Redis) if your host exposes /health and you want Redis covered.
  • No automatic OpenTelemetry Redis instrumentation. Add OpenTelemetry.Instrumentation.StackExchangeRedis and .AddRedisInstrumentation() to your TracerProviderBuilder if you want Redis spans in your traces.

The connection-string lookup (ConnectionStrings:redis in configuration) is identical to the pre-cleanup behaviour.

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

Showing the top 2 NuGet packages that depend on Stratara.Infrastructure:

Package Downloads
Stratara.EventSourcing.WorkerDefaults

Worker-host wiring composites for the Stratara event-sourced stack. IHostApplicationBuilder extensions (AddBackendServices, AddCommandWorkerServices, AddEventProjectionWorkerServices, 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.1.4 102 6/15/2026
3.1.3 115 6/10/2026
3.1.2 133 6/5/2026
3.1.1 196 6/1/2026
3.1.0 111 5/30/2026
3.0.23 113 5/28/2026

### Added

- **Command-workload isolation (heavy-command lane)** — long-running commands can now be routed to a
 dedicated worker lane so they cannot starve interactive commands. Mark a command with the new
 `Stratara.Abstractions.Mediator.IHeavyCommand` marker and the `ICommandOutboxDispatcher`
 automatically publishes it to a separate heavy-command topic (`IMessagingIdentifier.HeavyCommandTopic` /
 `HeavyCommandSubscription`, configurable under `Messaging:HeavyCommand`, defaulting to `heavy-command` /
 `heavy-command-subscription`). Run a dedicated heavy-command worker with the new
 `services.AddHeavyCommandWorker(degreeOfParallelism?)` extension, or the
 `builder.AddHeavyCommandWorkerServices(degreeOfParallelism?)` host composite — in the same process as
 the interactive worker (two lanes) or in a separately scaled host. Each worker's degree of parallelism
 is configurable per lane. `IMessagingIdentifier` gains `HeavyCommandTopic`, `HeavyCommandSubscription`,
 and the `GetCommandTopic(Type)` / `GetCommandSubscription(Type)` routing helpers. The interactive lane
 (`AddMediatorWorker()`) is unchanged and remains the default; commands not marked heavy keep their
 existing routing. If a heavy command is dispatched while no heavy worker is bound, the publish is
 rejected and the command is preserved in the outbox until a heavy-command worker comes online — it is
 never dropped. Works over both the RabbitMQ and Azure Service Bus message buses (Azure Service Bus
 requires the heavy-command topic/subscription to be provisioned, like the existing command topic). New
 log-event ID `105_005` (`CommandWorkerLaneStarted`) in `Stratara.Diagnostics`.
- **Observability metrics across the worker pipeline** (`Stratara.Diagnostics`) — the shared
 `Stratara.Service` meter now publishes throughput and latency instruments so operators can see how the
 event-sourcing pipeline is behaving instead of flying blind on a single counter. New instruments:
 `event_source.events.appended` (counter, tagged by `event.type` / `aggregate.type`),
 `outbox.published` (counter, tagged by `outbox.kind` = `command` / `event`), `command.duration`
 (histogram, ms, tagged by `request.type` / `outcome`), `projection.events.processed` (counter) +
 `projection.bundle.duration` (histogram, ms), `saga.events.processed` (counter) +
 `saga.bundle.duration` (histogram, ms), and `saga.inflight` (up/down counter). They are recorded by the
 event source, command worker, projection worker, saga worker, and outbox worker respectively. Because
 projections and sagas are real-time bus subscribers without a persisted checkpoint, these report
 **throughput and latency**, not consumer lag. No configuration is required — point any OpenTelemetry
 metrics exporter at the `Stratara.Service` meter.
- **Operational health checks for the event store and outbox** (`Stratara.EventSourcing.EntityFrameworkCore`) —
 two opt-in readiness checks added to any `IHealthChecksBuilder`: `AddEventStoreHealthCheck()` verifies
 the write-side database is reachable, and `AddOutboxHealthCheck(degradedThreshold?, unhealthyThreshold?)`
 reports the pending outbox backlog (exposed under the `pending` data key) and escalates to
 `Degraded` / `Unhealthy` when the backlog crosses the supplied thresholds. Both are tagged `ready` by
 default (so they map to a readiness endpoint, not liveness) and require the Stratara write store to be
 registered. The write-store DbContext is now also resolvable as a scoped `IWriteDbContext` service to
 support these checks.
- **Polly-backed mediator resilience behavior** (`Stratara.Resilience`) — an opt-in pipeline behavior
 wraps the in-process dispatch of a request marked with the new
 `Stratara.Abstractions.Resilience.IResilientRequest` in the named Polly pipeline the request selects
 (`ResiliencePipelineName`). Register it with the new `AddStrataraResilienceBehavior()` (after
 `AddStrataraValidation()` / `AddStrataraTenantIsolation()` so the retry wraps the handler, not the
 guards); requests without the marker are unaffected. A new built-in pipeline
 `ResilienceNames.ConcurrencyConflict` retries **only** on
 `Stratara.Abstractions.Persistence.ConcurrencyConflictException` (5 attempts, short exponential
 backoff) so a handler that re-reads and re-applies on an optimistic-concurrency clash succeeds without
 bespoke retry loops; it is registered by `AddResiliencePipelines()` alongside the existing message-bus
 and dispatcher pipelines. Only mark handlers that are safe to re-run (idempotent or concurrency-guarded).