.NET dependency injection conventions: lifetimes, scopes and the captive-dependency trap

What it is

The .NET documentation describes a built-in container: services are added to an IServiceCollection at start-up (AddTransient, AddScoped, AddSingleton, or keyed variants), BuildServiceProvider or the generic host creates the IServiceProvider, and consumers receive dependencies through a public constructor. Transient services are created each time they are requested; scoped services once per scope, which in ASP.NET Core is the request; singletons once for the container's lifetime. The container disposes what it created: transient and scoped instances at the end of their scope, singletons at shutdown. When a type has several constructors, the one with the most DI-resolvable parameters is chosen, and ambiguity throws.

Why it matters

Engineers from Spring (singleton by default) or from frameworks without a container tend to register everything as singleton or resolve services by hand. The guidelines page names the resulting bug a captive dependency: a longer-lived service holds a shorter-lived one, so a "per request" DbContext captured by a singleton is silently shared by every request. The lifetimes page states that a scoped service must not be resolved from a singleton, by constructor injection or through IServiceProvider; the documented fix is to create an explicit scope with IServiceScopeFactory.

How to apply

• Default to transient for stateless services, scoped for per-request state (DbContext, unit of work), singleton only for shared, thread-safe, expensive state; the guidelines say singletons must be thread-safe and warn about coupling and memory.
• Depend on interfaces in constructors and keep constructors free of work beyond assignment.
• Never call Dispose on an injected service, and do not register IDisposable types as transient when they may be resolved from the root provider; the guidelines say such instances are held until the container is disposed.
• Do not call BuildServiceProvider while configuring services and do not use GetService as a service locator; both are listed as anti-patterns.
• Keep scope validation on: the development host checks that scoped services are neither resolved from the root nor injected into singletons, and validateScopes: true on BuildServiceProvider does the same elsewhere.
• In hosted or background services, inject IServiceScopeFactory and create a scope per unit of work.

Pitfalls

Static access to the provider (a captured ApplicationServices) is listed as something to avoid: the guidelines say the benefits of DI are lost when it is mixed with static object access. Storing configuration or user data in the container instead of using the options pattern. Keyed services need [FromKeyedServices("key")] on the parameter. Registering a service twice is legal and easy to miss.