microsoft-extensions-configuration

Configuration patterns using Microsoft.Extensions.Configuration. Covers configuration providers, binding, validation, and best practices for .NET applications. Use when setting up configuration in .NET applications, implementing configuration validation with IValidateOptions, or managing settings ac

By wshaddix · 514 installs

npx skills add wshaddix/dotnet-skills --skill microsoft-extensions-configuration

Source repository · Upstream listing

Microsoft.Extensions Configuration Patterns When to Use This Skill Use this skill when: Binding configuration from appsettings.json to strongly typed classes Validating configuration at application startup (fail fast) Implementing complex validation logic for settings Designing configuration classes that are testable and maintainable Understanding IOptions<T , IOptionsSnapshot<T , and IOptionsMonitor<T Why Configuration Validation Matters The Problem: Applications often fail at runtime due to misconfiguration missing connection strings, invalid URLs, out of range values. These failures happen deep in business logic, far from where configuration is loaded, making debugging difficult. The Solution: Validate configuration at startup. If configuration is invalid, the application fails immediately with a clear error message. This is the "fail fast" principle. Pattern 1: Basic Options Binding Define a Settings Class Bind from Configuration Consume in Services Pattern 2: Data Annotations Validation For simple validation rules, use Data Annotations: Enable Data Annotations Validation Key Point: .ValidateOnStart() is critical. Without it, validation only runs when the options are first accessed, which could be minutes or hours into application runtime. Pattern 3: IValidateOptions<T for Complex Validation Data Annotations work for simple rules, but complex validation requires IValidateOptions<T : When to Use IValidateOptions Scenario Data Annotations IValidateOptions Required field ✅ ✅ Range check ✅ ✅ Regex pattern ✅ ✅ Cross property validation ❌ ✅ Conditional validation ❌ ✅ External service checks ❌ ✅ Custom error messages with context Limited ✅ Dependency injection in validator ❌ ✅ Implementing IValidateOptions Register the Validator Order matters: Data Annotations run first, then IValidateOptions validators. All failures are collected and reported together. Pattern 4: Validators with Dependencies IValidateOptions validators are resolved from DI, so they can have dependencies: Pattern 5: Named Options When you have multiple instances of the same settings type (e.g., multiple database connections): Named Options Validator Pattern 6: Options Lifetime Understanding the three options interfaces: Interface Lifetime Reloads on Change Use Case IOptions<T Singleton No Static config, read once IOptionsSnapshot<T Scoped Yes (per request) Web apps needing fresh config IOptionsMonitor<T Singleton Yes (with callback) Background services, real time updates IOptionsMonitor for Background Services Pattern 7: Post Configuration Modify options after binding but before validation: PostConfigure with Dependencies Pattern 8: Complete Example Production Settings Class Anti Patterns to Avoid 1. Manual Configuration Access 2. Validation in Constructor 3. Forgetting ValidateOnStart 4. Throwing in IValidateOptions Testing Configuration Validators Summary Principle Implementation Fail fast .ValidateOnStart() Strongly typed Bind to POCO classes Simple validation Data Annotations Complex validation IValidateOptions<T Cross property rules IValidateOptions<T Environment aware Inject IHostEnvironment Testable Validators are plain classes