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