Class ProtoInfrastructureExtensions
public static class ProtoInfrastructureExtensions
- Inheritance
-
ProtoInfrastructureExtensions
- Inherited Members
Methods
AddInfrastructure(IProtoHostBuilder, IProtoInfrastructure, params string[])
Registers infrastructure the host starts before the run. Every key in
settings receives the started connection string, so the tests and an
in-process application can read it under their own configuration roots; for a
settings-only piece the keys are the values it will fill, and they decide whether it is needed.
[Obsolete("Use AddInfrastructure(name, chain, keys) with UseConfigured() and a Use(provider) provider instead; the old call keeps its all-configured skip rule in 1.x.")]
public static IProtoHostBuilder AddInfrastructure(this IProtoHostBuilder builder, IProtoInfrastructure infrastructure, params string[] settings)
Parameters
builderIProtoHostBuilderinfrastructureIProtoInfrastructuresettingsstring[]
Returns
Remarks
The piece is not started when every declared key already has a configured value: the
environment provides those addresses, and starting a container or process would shadow them.
Use AddInfrastructureAlways(IProtoHostBuilder, IProtoInfrastructure, params string[]) when a piece must start regardless.
AddInfrastructure(IProtoHostBuilder, string, Action<IProtoProviderChainBuilder>, params string[])
is the replacement: a target's providers in priority order, with
UseConfigured() for the configured-key step-aside and a provider with no condition for a
piece that must start regardless.
AddInfrastructure(IProtoHostBuilder, string, Action<IProtoProviderChainBuilder>, params string[])
Registers a target as an ordered provider chain: while the host is built, the providers are walked in order and the first whose condition holds serves the target. The winner's piece starts with the run and the winner's capabilities are declared; every other provider is recorded skipped with the reason it lost, and a target no provider can serve fails the build naming each candidate.
public static IProtoHostBuilder AddInfrastructure(this IProtoHostBuilder builder, string name, Action<IProtoProviderChainBuilder> configure, params string[] keys)
Parameters
builderIProtoHostBuilderThe host builder.
namestringThe target's identity: unique per host, used in records and error messages.
configureAction<IProtoProviderChainBuilder>Adds the target's providers in priority order.
keysstring[]The configuration keys the target declares once; every provider checks or fills them. An application target derives its address key in
AddApplicationinstead of writing it here.
Returns
AddInfrastructureAlways(IProtoHostBuilder, IProtoInfrastructure, params string[])
Registers infrastructure that starts even when its declared keys are already configured.
public static IProtoHostBuilder AddInfrastructureAlways(this IProtoHostBuilder builder, IProtoInfrastructure infrastructure, params string[] settings)
Parameters
builderIProtoHostBuilderinfrastructureIProtoInfrastructuresettingsstring[]
Returns
AddRunSetup(IProtoHostBuilder, string, Func<ProtoRunSetupContext, ValueTask>)
Registers a run-scoped setup step: an action the host runs once when the run starts, at this registration's position in the infrastructure order. Register it after the pieces whose published settings it reads - a container's connection string, a broker's address - so it sees their started values; the run's cancellation token arrives through CancellationToken.
public static IProtoHostBuilder AddRunSetup(this IProtoHostBuilder builder, string name, Func<ProtoRunSetupContext, ValueTask> setup)
Parameters
builderIProtoHostBuildernamestringsetupFunc<ProtoRunSetupContext, ValueTask>
Returns
Remarks
A step is an action, not a resource: it owns nothing to release, so the run's stop and dispose do not run it again. A step that throws fails the run's start with its own exception, releases what the run had started and leaves the host retryable, exactly like failing infrastructure; a retry runs the step again. Use it for state the whole run shares - a schema for a container database - because a run hook runs before infrastructure starts and cannot see its addresses, and a test hook or test body runs inside the per-test transaction, where its DDL is rolled back with the test.