Compile-time DI guardrails
Catch DI scope leaks, captive dependencies, BuildServiceProvider misuse, and unresolvable services before they become runtime bugs, flaky tests, or production-only failures.
Why teams install it
Latest release
IServiceProvider.GetService(typeof(T)) and GetRequiredService(typeof(T)) requests made through a scope or provider captured outside the handler. Literal typeof(T) is required, direct-static ordinal recovery is restricted to exact framework extension containers, and concrete provider implementations bind the requested type by semantic parameter type rather than parameter spelling. Provider-origin tracing preserves built-in identity, reference, and boxing conversions so existing generic/keyed resolution through captured value-type and IServiceProvider-constrained providers remains covered; constraint traversal is cycle-safe for temporarily invalid editor code. Runtime Type values, user-defined conversions on either the requested type or provider receiver, user-defined same-named helpers, and scopes created inside the handler remain silent.Featured diagnostics
DI003
singleton services capturing scoped or transient dependencies, including constructor injection, `IEnumerable<T>` collection captures, known scoped framework services such as `IOptionsSnapshot<T>`, EF Core contexts and `DbContextOptions<TContext>` registrations from `AddDbContext(...)`, `AddDbContextFactory(...)`, `AddDbContextPool(...)`, and `AddPooledDbContextFactory(...)` including service/implementation overload self-registrations, and high-confidence factory paths such as inline delegates, stable local delegate factories, method-group factories, `GetServices<T>()`, keyed resolutions, and `ActivatorUtilities.CreateInstance(...)` calls where DI still resolves a scoped or transient constructor parameter.
DI015
registered services with direct or transitive constructor/factory dependencies that are not registered (including keyed and open-generic paths).
DI016
`BuildServiceProvider()` calls while composing registrations (for example in `ConfigureServices`, `IServiceCollection` extension registration methods, registration lambdas, or builder-style `.Services` helper flows), whether written as reduced extension syntax (`services.BuildServiceProvider()`) or as a direct static call (`ServiceCollectionContainerBuilderExtensions.BuildServiceProvider(builder.Services)`).
DI007
resolving dependencies via `IServiceProvider` inside app logic.
DI001
`IServiceScope` instances created with `CreateScope()` or `CreateAsyncScope()` that are never disposed, including scopes whose only disposal call is hidden behind a conditional branch, switch section, loop, catch block, or after a branch exit that can bypass shared cleanup. DI001 recognizes predeclared nullable scope locals assigned conditionally when a later conditional-access, non-null-guarded, same-branch pre-exit, or `finally` disposal reliably closes ownership, and it treats directly returned scopes as caller-owned even through simple casts or conditional return arms. Reassignment leaks and loop-created scopes that need per-iteration disposal still report.
DI014
root providers from `BuildServiceProvider()` that are never disposed, including local providers whose only manual disposal is conditional, catch-only, after reassignment to another provider, or after repeated creation inside a loop. Straight-line explicit disposal, standard `Dispose()` to `Dispose(true)` cleanup, and caller-owned return flows are accepted even when the `BuildServiceProvider()` result is parenthesized, same-instance cast, null-forgiven, selected by a ternary arm, or supplied by a null-coalescing operand; user-defined conversions remain reportable because they may produce a different instance.
Search-targeted pages
Problem guide
These diagnostics catch the most common scope-lifetime mistakes that lead to disposed-service failures in background jobs, middleware, and startup code.
Problem guide
This page is for teams searching for captive dependency detection in ASP.NET Core, worker services, and generic-host apps.
Problem guide
Use these rules when you want to stop BuildServiceProvider misuse during registration while still allowing intentional provider factory methods.
Problem guide
These diagnostics focus on missing registrations, factory paths, keyed lookups, and incompatible implementation types.
Problem guide
Use these diagnostics when you want a stronger constructor-injection culture across app code and shared libraries.
Problem guide
This rule is useful when teams are diagnosing resource leaks caused by transient disposables that look harmless in reviews.
Problem guide
This rule is intentionally softer than runtime-failure diagnostics, but it is useful for preventing DI-heavy classes from becoming maintenance hotspots.
Problem guide
This page targets teams debugging confusing registration order issues and silent overrides in service composition code.
Problem guide
Use this rule when background services, async handlers, or hosted-service workflows are mixing sync scopes into async disposal paths.
Adoption
Start with the default severities, promote high-confidence rules to errors, and use the sample-driven rule pages to explain the policy to the team.
Compare
Use the comparison matrix when someone asks why this belongs in the build instead of code review or startup smoke tests.