All 15 Dependency Injection questions
More in Dependency Injection
How do you register multiple implementations of the same interface and resolve all of them together via IEnumerable<T>? How do you use IServiceScopeFactory to manually create a DI scope outside the normal per-request pipeline, such as inside a background service? How do you register a service using a factory delegate instead of a simple type mapping, when construction requires reading configuration or resolving other services conditionally? What is the difference between constructor injection and using IServiceProvider directly to resolve dependencies imperatively (service location)? What does GetService<T>() return compared to GetRequiredService<T>() when a service isn't registered, and which should application code generally prefer? What is the 'captive dependency' problem, and how does ASP.NET Core's DI container help catch it automatically? What are keyed services (introduced in .NET 8), and what problem do they solve compared to injecting IEnumerable<T> when you need one specific implementation? How does the DI container's disposal behavior work for IDisposable services registered as Transient, and why can this cause unexpected memory retention? How does dependency injection integrate with minimal API endpoint handlers versus controller constructors? How would you unit test a service or minimal API handler that depends on multiple injected interfaces, without spinning up the full DI container?
Advertisement
ASP.NET Core › Dependency Injection

How does the Options pattern's IOptions<T>/IOptionsSnapshot<T> relate to and build upon the standard DI container?

Intermediate

Answer

IOptions<T>, IOptionsSnapshot<T>, and IOptionsMonitor<T> are themselves services resolved through the DI container (registered implicitly when you call Configure<T>()), demonstrating that the Options pattern is built entirely on top of standard DI infrastructure rather than being a separate mechanism -- IOptions<T> is registered as Singleton internally, IOptionsSnapshot<T> as Scoped, explaining their respective behavior around configuration change visibility and captive dependency risk.
// Configure<T> implicitly registers the necessary IOptions<T> infrastructure
builder.Services.Configure<SmtpSettings>(builder.Configuration.GetSection("Smtp"));

// Under the hood, this makes IOptions<SmtpSettings>, IOptionsSnapshot<SmtpSettings>,
// and IOptionsMonitor<SmtpSettings> all resolvable via the same DI container
Real-world example Understanding that IOptionsSnapshot<T> is registered as Scoped explains precisely why it can't be safely injected into a Singleton service -- it's the exact same captive dependency problem as any other Scoped service being consumed by a Singleton.

Common follow-ups: Why does IOptionsMonitor<T> avoid the captive dependency problem despite being usable in Singletons?;How would you build a custom pattern following these same DI principles?

Configuration & Options Pattern;Background Tasks & Hosted Services
All 15 Dependency Injection questions