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
T → Nullable<T> special case), so implicit numeric conversions and user-defined operators no longer hide registrations Microsoft.Extensions.DependencyInjection cannot bind.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>`, typed HTTP clients registered with `AddHttpClient<TClient>()` / `AddHttpClient<TClient,TImplementation>()`, 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. A factory that creates and provably disposes its own scope (`using var scope = sp.CreateScope();`) stays quiet for resolutions through that scope when only derived values flow into the product — one-time scoped setup is not a captive — while an escaping resolved instance or an undisposed factory scope still reports.
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, including non-generic resolution calls that pass a local `Type` alias initialized from `typeof(...)`.
DI001
`IServiceScope` instances created with `CreateScope()` or `CreateAsyncScope()` that are never disposed, including scopes whose only disposal call is hidden behind a conditional branch, or behind a switch section, loop, or catch block that does not also contain the creation, or after a branch exit that can bypass shared cleanup. Create-and-dispose within the same loop iteration, switch section, or catch clause — the per-message worker shape — stays quiet, but a `continue`/`break` that skips the dispose, or a `yield return`/`yield break` that can strand the scope in a never-resumed iterator, still reports. 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 — including a provider stored in a local and returned later (ownership transfer), and create-and-dispose within the same loop iteration, switch section, or catch clause (a `continue`/`break` that skips the dispose still reports). A `using` declaration or statement proves cleanup only when that same provider instance reaches its resource expression. User-defined conversions remain reportable because they may produce a different instance, including a disposable wrapper selected by a coalesce inside `using`.
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.