Table of Contents

Application Configuration Setup

The Tlabs Library provides a notion of the common Application’s Setup given with the ApplicationSetup object. The Setup of an application is reflecting some core infrastructure services frequently needed across all parts and modules of an application.

The current state of the ApplicationSetup is represented by the Tlabs.App.Setup object which is available throughout the entire lifetime of the application. Immediately on program start (or with the scope of a unit-test) the ApplicationSetup provides some reasonable defaults that usually get upgraded during the startup phase (e.g. by setting up an application host - see Hosted Application Setup).

The ApplicationSetup object represents these common setup properties:

  • ContentRoot (path)
    Filesystem based resources should be relative to this path.
    (Defaults to the applications base directory where the application’s executable file is located.)

  • Configuration
    Application’s configuration values obtained from different sources (also see Configuration below)
    (Defaults to an empty configuration.)

  • LogFactory
    ILoggerFactory object to provide ILogger<> instances.
    (Defaults to provide a standard console output logger.)

  • ServiceProv
    IServiceProvider for all application services.
    (Defaults to an empty service provider.)

  • TimeInfo
    Application’s time info to be used to get consistent (OS unrelated) time data (also during testing)
    (Defaults to UTC based application time.)

Hosted Application Setup

By setting up an application in a so called hosted context (see generic host) the ApplicationSetup is more specifically being adjusted. The hosted application setup gets coordinated with the Hosted(Web)AppBuilder that supports to drive the (hosted) application setup completely from configuration.

NOTE: This is in significant contrast to the “ASP.NET App start up” procedure mandated for beginners, where the setup applied from the preconfigured defaults of WebApplication.CreateBuilder() and the setup of the HTTP request pipeline is performed essentially hardcoded and would require a change of the applications code (with rebuild) for being adjusted!!!

When building a hosted application with Hosted(Web)AppBuilder.Build() the resulting ApplicationSetup would be specifically adjusted to:

Configuration

The configuration is represented as structured key/value pairs. (Structured because a value could represent a subsection of again structure key/value pairs.) The configuration is being setup from multiple sources where a later source could optionally override values previously read from a former source.

  1. appsetings.json (from ContentRoot)

  2. appsetings.{asp.net-hosting-environment}.json (optional)

  3. further json files defined in section configExtensions

  4. Environment variables (filtered with prefix)

  5. Command line arguments

Log Factory

The default Log factory can optionally be replaced with the logging providers configured from the configuration section logging.

Service Provider

Once the application setup has been completed (i.e. the application IHost has been constructed with IAppBuilder.Build()) the service provider is the central source of service objects (with fully resolved dependencies),
The service provided is being mainly constructed from application services listed in the configuration from the section applicationServices.

TimeInfo

This IAppTime object represents a notion of the application time.
All Tlabs Library functions that are dealing with time are using this object to coordinate time values between the application time and UTC. The application time (returned from IAppTime.Now) could be configured to be a time from any time-zone (default is UTC).

NOTE:

  • Time values stored in the persistent store should be assumed as in application time.

  • Do NOT use DateTime.Now, use App.TimeInfo.Now instead to get the current application time!

  • Do NOT use TimeZoneInfo.LOCAL use App.TimeInfo.TZInfo instead to get application time TimeZoneInfo

  • The application time is not necessarily equal to the local time of the operating system.
    (In some environments you might also do not have any control about the local time of a virtual (cloud) operating system.)

  • Beware of the DateTime.Kind property.
    With the Tlabs application time it has following meanings:

    • DateTimeKind.Unspecified means DateTime value is in application time which is not TimeZoneInfo.LOCAL

    • DateTimeKind.Local means DateTime value is in TimeZoneInfo.LOCAL
      (e.g. it has been obtained with DateTime.Now)

    • DateTimeKind.Utc only DateTime values of this kind are assumed in UTC.