Compose the service defaults
Telemetry export, liveness and readiness, service discovery, one resilience pipeline and Serilog for a Host, from the service defaults project your solution owns.
What you build
The service defaults are recipes, not a Kit package: a service defaults project in your own solution, shaped like .NET Aspire's, which the templates generate and compose in every Host. You own your copy and change or drop any recipe in it. Each recipe is optional, and none is needed for the Kit to work.
The recipe exports; the Kit emits
The OpenTelemetry recipe exports what the Kit emits, but the Kit emits its Operations' activities and metrics only in a Host that calls AddPouryaKitObservability(). See Observability.
When to use it
In every Host you deploy. A generated Host already composes all three entry points; read this when you change one of them, add a client that needs other limits, or compose a Host by hand.
Steps
Add the defaults to the builder
AddServiceDefaults() adds OpenTelemetry, the health checks, service discovery and one resilience pipeline for every outgoing HttpClient. What each recipe does lists each one.
Map the health endpoints
MapDefaultEndpoints() maps the liveness endpoint in every environment and the full health endpoint in Development only. Liveness and readiness says why readiness outside Development is your platform's.
Opt into Serilog
AddSerilogDefaults() replaces the logging providers with Serilog, when the Host wants it. See Serilog.
Give one client its own limits
Every client takes the defaults' one pipeline, which retries safe methods only. A client that needs other limits removes the default pipeline before adding its own, since two pipelines on one client are refused: see One resilience pipeline.
Composing a Host with them shows the Proving Sample's Inventory.Host, which composes all three.
What the Kit guarantees
| Guarantee | Stated in |
|---|---|
| What each recipe adds, and what leaves the process | What each recipe does |
| One resilience pipeline per client | One resilience pipeline |
| Testing a Host that uses them | Testing a Host with them |
Failure messages
Next steps
Test a Feature
Run a Feature's Operations against the hosted application on a real PostgreSQL, through its Module's Gateway or over HTTP, and assert its Result, its rows and its deliveries.
Prepare a release
Write Wolverine's generated code into the Host before the Release build, publish the Host without a runtime compiler, and migrate before it starts.