CSealTest 1.0.2

ConfigSeal

Strict startup configuration validation for ASP.NET Core. The FluentValidation for configuration.

The Problem

Configuration errors are silent killers. Your app starts fine, then crashes in production because App:PaymentApiKey was never set, Database:MaxPoolSize is 0, or a developer accidentally committed localhost as the API base URL.

.NET's built-in IOptions<T> binding gives you type safety, but no enforcement. Missing values stay null. Invalid values go unnoticed. Secrets get left as placeholders.

ConfigSeal catches all of this at startup, before your app serves a single request.

What It Looks Like

// Program.cs
var guard = builder.Services.AddConfigSeal(builder.Configuration, builder.Environment);

guard.Bind<AppOptions>("App")
    .Require(x => x.ApiKey)
    .Validate(x => x.Timeout > 0)
    .ValidateEnvironment();

guard.Bind<DatabaseOptions>("Database")
    .Require(x => x.ConnectionString)
    .Validate(x => x.MaxPoolSize is > 0 and <= 500, "MaxPoolSize must be 1–500.");

guard.ValidateAll(); // throws if anything is wrong — app will not start

On failure, instead of a cryptic NullReferenceException at runtime, you get:

╔══════════════════════════════════════════════════════════════╗
║           ConfigSeal: Configuration Sealed — Startup Blocked        ║
╠══════════════════════════════════════════════════════════════╣
║  ✗ [Critical] App.ApiKey
║      → Required configuration value is missing or empty.
║      💡 Generate via: openssl rand -hex 32
║  ✗ [Error] Database.MaxPoolSize
║      → Value 0 is outside the allowed range [1, 500].
╠══════════════════════════════════════════════════════════════╣
║  2 validation error(s) must be resolved before startup.
╚══════════════════════════════════════════════════════════════╝

Features

Attribute-Based Validation

Decorate your options classes — no extra registration needed:

public class AppOptions
{
    [RequiredConfig(Hint = "Generate via: openssl rand -hex 32")]
    [SecretConfig(MinLength = 32)]
    public string? ApiKey { get; set; }

    [RangeConfig(1, 300)]
    public int TimeoutSeconds { get; set; }

    [AllowedValues("Strict", "Relaxed", "Off")]
    public string? CorsPolicy { get; set; }

    [RegexConfig(@"^https://", ErrorMessage = "BaseUrl must use HTTPS.")]
    public string? BaseUrl { get; set; }
}

Fluent Validation

For logic that spans multiple properties or needs runtime context:

guard.Bind<CacheOptions>("Cache")
    .Validate(x => !(x.UseMemoryCache && x.UseRedis),
              "Cannot enable both MemoryCache and Redis simultaneously.")
    .Validate(x => x.ExpiryMinutes,
              v => v is > 0 and <= 1440,
              "Cache expiry must be between 1 minute and 24 hours.");

Environment Safety Checks

.ValidateEnvironment() fails startup if production config contains development defaults: localhost, 127.0.0.1, development, debug, ::1, etc.

Secret Validation

[SecretConfig] catches the most common secrets-in-production mistakes:

• Missing entirely → Critical
• Looks like a placeholder (CHANGEME, your_secret_here, <replace_me>) → Critical
• Too short for the context → Warning

All Failures at Once

ConfigSeal collects every problem before throwing. You see the full picture on the first failed deploy, not one error at a time.

Custom Validators

Plug in reusable cross-cutting validation:

public class ConnectionStringValidator : IConfigValidator
{
    public void Validate(object options, ValidationContext context)
    {
        if (options is DatabaseOptions db)
            if (!db.ConnectionString?.Contains("Encrypt=True") ?? true)
                context.AddWarning("ConnectionString",
                    "Connection string does not enforce encryption.",
                    "Add 'Encrypt=True' for production.");
    }
}

guard.Bind<DatabaseOptions>("Database")
    .WithValidator(new ConnectionStringValidator());

Installation

dotnet add package ConfigSeal

Targets net8.0. Depends only on Microsoft.Extensions.* abstractions — no heavy third-party dependencies.

Publishing a Release

Releases are fully automated via GitHub Actions. The publish job runs only on version tags and requires the build-and-test job to pass first.

One-time setup

Add your NuGet API key as a repository secret:

1. Go to nuget.org → Account → API Keys → Create
2. In your GitHub repo → Settings → Secrets and variables → Actions → New repository secret
3. Name: NUGET_API_KEY, value: your key

Releasing

# Bump the version in src/ConfigSeal/ConfigSeal.csproj first, then:
git tag v1.2.3
git push origin v1.2.3

The CI pipeline will:

1. Build and run all tests (blocks publish on failure)
2. Pack ConfigSeal.1.2.3.nupkg using the tag as the version
3. Push to nuget.org
4. Create a GitHub Release with auto-generated notes and the .nupkg attached

The tag version and the <Version> in the .csproj can differ — the tag always wins at publish time. Keep them in sync to avoid confusion.

Versioning

This project follows Semantic Versioning:

See CHANGELOG.md for the full release history.

Why ConfigSeal?

Every ASP.NET Core app uses configuration. Very few apps validate it rigorously. The ones that do write the same if (string.IsNullOrEmpty(...)) throw boilerplate in every project.

ConfigSeal makes thorough configuration validation the default, not the exception.

License

MIT