Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Requires: main module.
Settings can be obtained on-demand with configuration provider's Get method.
With prior assignment of sources:
With sources passed on per-call basis:
Always returns the most recent version of settings (updates may happen in background):
Call Get on every settings access for "hot" configuration;
Call Get once and cache the result for "cold" configuration;
First call for a type may block or throw exceptions due to source latency, data unavailability or incorrect data format. This behavior persists until a data update remedies the error;
Once warmed up, subsequent calls never block or throw errors and are extremely cheap due to caching. Future errors are not propagated to the calling code, but can be logged. Get calls return the last seen correct settings object;
With sources passed on per-call basis:
The subscription is not guaranteed to immediately produce a notification. The first notification may be delayed due to data not having been fetched from the source yet. However, once a valid settings instance has been observed, all new observers receive a notification with current actual settings upon subscription. This notification is published on a background thread, so don't count on it being delivered after Subscribe
call completes.
Requires: .
One can subscribe to settings updates for a type with 's Observe method.
With prior :
Temporary subscriptions should be disposed of as they might hold on to resources in :
OnError
and OnCompleted
notifications are never produced. Only successful settings updates are propagated to the observers. This means that there will be no notifications if initial attempt to provide settings and no further data updates are published by the .
The only way to notice errors when using Observe is to .
It's recommended to obtain initial settings instance with Get method before subscribing to updates with Observe. This practice ensures correct error propagation, warms up the and eliminates situations where the settings are not ready yet on access attempt.
Requires: logging module.
See error handling for cases where this logging is useful.
See logging documentation for the log interface required here.
Secret settings should be marked with an attribute to avoid being logged.
Requires: main sources module.
Multiple configuration sources can be combined into a single composite source whose data is produced by merging the settings trees provided by original sources.
Order of the sources is important: settings from sources that come later in the list have greater priority, hence the rightmost source should be the most specific/significant. In other words, merging is performed in a left-to-right fashion.
Updates are pushed to subscribers each time one of the component sources generates new settings.
Requires: main sources module.
A source can be scoped just like settings nodes can. Resulting source's data is exactly base source's data scoped to given path:
Requires: abstractions module.
By default settings are subject to logging, which is generally not appropriate for secrets. This can be fixed either by disabling logging entirely on the configuration provider or by annotating fields and properties of the model with [Secret]
attribute:
A source can only be assigned to a type before any Get or Observe calls are made for that type:
Requires: .
When using , Get and Observe method overloads without parameters require an explicit association of the model type with a .
Requires: main module.
Settings models can be printed in JSON or YAML formats to generate configuration file examples.
Requires: abstractions module.
By default all settings are optional; that is, absence of relevant data in the source results in default values during binding and does not produce errors.
Some parts of configuration may be crucial to the application to the point that it's pointless to start without them being initialized. These fields and properties should be annotated with [Required]
attribute:
Default behavior can be inverted in the scope of a type with [RequiredByDefault]
attribute. Individual fields and properties can then be made optional with [Optional]
attribute:
Requires: .
See for the log interface required here.
Secret settings should be to avoid being logged.