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
IServiceCollection wrapper extensions from real invocation sites instead of treating registrations inside uncalled wrappers as globally available.IServiceCollection flow now suppress DI015 when registration state is uncertain, reducing false positives in layered registration modules.IServiceCollection instance or after a registration do not hide genuine missing-dependency diagnostics.Featured diagnostics
DI003
singleton services capturing scoped or transient dependencies, including constructor injection and high-confidence factory paths such as inline delegates, method-group factories, keyed resolutions, and `ActivatorUtilities.CreateInstance(...)` without explicit constructor arguments.
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, or registration lambdas).
DI007
resolving dependencies via `IServiceProvider` inside app logic.
DI001
`IServiceScope` instances created with `CreateScope()` or `CreateAsyncScope()` that are never disposed.
DI014
root providers from `BuildServiceProvider()` that are never disposed.
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.