DependencyInjection.Lifetime.Analyzers.Scan 3.10.1

DI Scan

Scan any .NET solution for Microsoft.Extensions.DependencyInjection lifetime problems without adding a package to it.

dnx DependencyInjection.Lifetime.Analyzers.Scan                 # .NET 10 SDK, no install step
dnx DependencyInjection.Lifetime.Analyzers.Scan -- MyApp.slnx -o results.sarif

dotnet tool install -g DependencyInjection.Lifetime.Analyzers.Scan   # .NET 8 or 9 SDK
di-scan MyApp.slnx

The scanner builds the solution with the DependencyInjection.Lifetime.Analyzers analyzers injected, then prints the rules that fired, how often, where, the surrounding source, and a link to each rule's page. It also writes a SARIF 2.1.0 file for GitHub code scanning. Your project files are not changed.

Use it to try the analyzers on a real codebase before adding the package, compare releases, and review suspected false positives with the surrounding source in the HTML report.

Proof

The scanner and rules are regression-tested against 14 pinned public repositories and 471 findings, including ASP.NET Core apps, framework libraries, workers, open generics, keyed services, and alternate containers. The corpus has already driven precision fixes in DI001, DI006, DI015, and DI019. See the scanner guide and corpus triage notes.

Why teams use it

• Try the analyzer on a real repository before changing its project files.
• Review suspected false positives with code context in the HTML report.
• Fail CI only on new findings with SARIF or text baselines.
• Compare analyzer releases on the same pinned public corpus.

Options

Put the scanner's arguments after -- when using dnx.

False-positive triage

The HTML report is the fastest review surface:

di-scan ./MyApp.slnx --findings all --html di-review.html

It groups findings by rule, shows the message and a few lines of source around every hit, and provides search and severity filters. For a focused review, limit the scan to one rule:

di-scan ./MyApp.slnx --rules DI003 --html di003.html

The text and Markdown reports show the source line, so a suspected false positive can be checked against the exact code path without opening the solution. Suppressed diagnostics are omitted, just as they are in a normal build.

Baselines

A text baseline is one finding per line, exactly what the scanner prints:

# repository: example/App
# commit: 0123456789abcdef0123456789abcdef01234567
# target: App.sln
# exit: 0
DI003 src/App/Startup.cs:42:17

Pass it with --baseline. A SARIF report from an earlier scan works too; the scanner matches its fingerprints, so a finding that moves down a file stays known.