get_di_registrations silently returns 0 on non-Microsoft.Extensions.DI containers (Prism, Autofac, DryIoc)

[namlh-mx]

Summary

get_di_registrations returns Count: 0 on any codebase that uses a DI container other than
Microsoft.Extensions.DependencyInjection — Prism's IContainerRegistry, Autofac, DryIoc, Unity,
Castle Windsor. It reports the same empty result as a project with genuinely no DI, so an agent
reading the response concludes "this project has no dependency injection".

Reproduction

A WPF + Prism 9 solution (13 projects, .NET 10, .slnx), CWM.RoslynNavigator 0.8.0:

get_di_registrations()
→ {"Registrations":[],"Duplicates":[],"CaptiveRisks":[],"Count":0,"TotalFound":0}

The same solution, counted by grep:

35  containerRegistry.RegisterSingleton
14  containerRegistry.Register
 8  containerRegistry.RegisterForNavigation
 4  containerRegistry.RegisterInstance
---
61  registrations found

 0  AddSingleton / AddScoped / AddTransient / TryAdd*   ← nothing the tool looks for

Root cause

Tools/GetDiRegistrationsTool.cs matches against a hard-coded whitelist of 12 method names, all
from Microsoft.Extensions.DependencyInjection:

"AddSingleton", "AddScoped", "AddTransient",
"AddKeyedSingleton", "AddKeyedScoped", "AddKeyedTransient",
"TryAddSingleton", "TryAddScoped", "TryAddTransient",
"TryAddKeyedSingleton", "TryAddKeyedScoped", "TryAddKeyedTransient"
...
if (!RegistrationMethods.Contains(methodName)) return;

Everything else is skipped silently. This is working as written — the tool description does say
Add{Singleton,Scoped,Transient}/AddKeyed*/TryAdd*. The problem is what a zero result means.

Why this is worth fixing rather than documenting

The tool's blind spots are already documented honestly (reflection, Scrutor, extension-method
indirection). But those degrade a partial result, which stays visibly partial. An unsupported
container degrades to 0, and 0 is indistinguishable from "no DI in this codebase" — the exact
failure mode PR #26 identifies for the nine tools it converted to structured errors:

"An agent reading that empty response concludes the code is dead — from a typo."

Note that PR #26's new SymbolNotFound / AmbiguousMatch contracts do not cover this case:
the scan succeeds and genuinely finds zero matches. So 0.10.0 does not close it.

The blast radius is wider than one project — Prism is the dominant DI container in WPF, and this
repo positions itself as a .NET-wide toolkit, not an ASP.NET one.

Two possible fixes

Minimal — make the zero honest. When zero registrations match but the solution does contain
calls that look like DI registration under some other container, say so:

{"Registrations":[],"Count":0,
 "Note":"No Microsoft.Extensions.DependencyInjection registrations found. 61 calls matching
         other container APIs (Prism IContainerRegistry) were seen and not analysed."}

That alone removes the misleading part, without committing to multi-container support.

Fuller — add Prism's IContainerRegistry to the whitelist. It maps cleanly onto the existing
model, since Prism carries the same lifetime concept:

Prism	Lifetime
RegisterSingleton<TFrom, TTo>()	singleton
Register<TFrom, TTo>()	transient
RegisterScoped<TFrom, TTo>()	scoped
RegisterInstance<T>(instance)	singleton
RegisterMany<T>(...)	(multi)

RegisterForNavigation<TView, TViewModel>() is Prism navigation rather than plain DI, so it may
belong out of scope or in a separate bucket.

Duplicate detection and captive-dependency analysis would then work unchanged for Prism codebases
— they are the two analyses that have no cheap grep substitute, and the reason this tool is worth
reaching for at all.

Environment

• CWM.RoslynNavigator 0.8.0 (dotnet global tool), Claude Code on Windows 11
• .NET 10, WPF, Prism 9, Dapper; 13-project .slnx solution mixing net10.0 and net10.0-windows
• Solution loads correctly otherwise — get_type_hierarchy, find_callers, find_implementations
  and get_project_graph all return accurate results on the same workspace