StrictConfig 1.0.1

StrictConfig

Strict configuration binding for .NET.

Use it when you want configuration errors to be obvious instead of permissive.

Why use it

StrictConfig is built to solve the parts of configuration binding that usually hurt in production:

• unknown keys being silently ignored
• invalid values surfacing too late
• nested validation being inconsistent
• reloads switching an app into a bad state

Quick start

using StrictConfig;

public sealed class AppSettings
{
    public required string Name { get; set; }
    public int Port { get; set; }
    public DatabaseSettings Database { get; set; } = new();
}

public sealed class DatabaseSettings
{
    public required string ConnectionString { get; set; }
}

AppSettings settings = configuration.GetSection("App").GetStrict<AppSettings>();

If binding fails, GetStrict<T>() throws a StrictBindException with all collected errors.

Non-throwing binding

if (!configuration.GetSection("App").TryBindStrict<AppSettings>(out var settings, out var errors))
{
    foreach (var error in errors)
    {
        Console.WriteLine($"{error.Code} at {error.Path}: {error.Message}");
    }
}

Existing-instance binding

var settings = new AppSettings { Name = "existing" };
configuration.GetSection("App").GetStrict(settings);

Split binding and validation options

var result = configuration.GetSection("App").BindStrict<AppSettings>(
    binding => binding.ErrorOnUnknownKeys = false,
    validation => validation.ValidateDataAnnotations = false);

DI and reload-aware options

builder.Services.AddStrictOptions<AppSettings>("App", builder.Configuration.GetSection("App"));

using var provider = builder.Services.BuildServiceProvider();
var monitor = provider.GetRequiredService<IStrictOptionsMonitor<AppSettings>>();

using var subscription = monitor.OnStrictReloadError("App", failure =>
    Console.WriteLine($"{failure.Name} rejected: {failure.Errors[0].Code}"));

Strict reload behavior means:

• last known good values stay current
• invalid reloads are rejected
• failures are observable

Trimmed and NativeAOT apps

StrictConfig ships a built-in source generator.

using StrictConfig;

[StrictConfigSerializable(typeof(AppSettings))]
public partial class AppSettingsContext : StrictConfigContext
{
}

AppSettings settings = configuration
    .GetSection("App")
    .GetStrict<AppSettings>(AppSettingsContext.Default);

Use generated contexts when you need warning-clean trimmed or NativeAOT publishing.

What it supports

• scalars, enums, nullable values, arrays, lists, sets, and nested objects
• runtime-type binding
• constructor binding
• existing-instance updates
• immutable, concurrent, and read-only collections
• non-string-key dictionaries
• DataAnnotations, IValidatableObject, and custom validators
• custom converters and factories
• alias and ignore attributes
• exact Code, Path, Message, and AttemptedValue diagnostics

Verification snapshot

• 75 tests passing on net8.0
• 75 tests passing on net10.0
• about 74.92% line coverage
• about 74.53% branch coverage
• packaged consumer verification passes
• warning-clean trimmed publish verified
• warning-clean NativeAOT publish verified