cs0618-hunter

cs0618-hunter — compiler ground-truth for obsolete API usage

⚡ Prefer the MCP tool. The maf-autopilot MCP server exposes MafRunCs0618Hunt(projectPath) — it shells dotnet build, parses every CS0618 / CS0246 diagnostic, joins each one to its canonical fix in the obsolete-API registry, and returns a structured report. The procedural walkthrough below is preserved for when you need to run the steps manually (offline, debugging the tool itself, etc.).

Why the compiler stays authoritative

[email protected] was the first release to surface [Obsolete] in member listings (PR #318 closes issue #316); this repository pins 0.9.1. That's an excellent pre-build static check, but three classes of obsoletion remain compiler-only:

1. Transitive obsoletions — the API your code calls isn't obsolete, but it forwards to one that is.
2. Overload-resolution surprises — a more-specific overload was added in a minor release and your literal types now bind to it.
3. Project-local [Obsolete] — types your team marked obsolete in this solution. Static inspection of NuGet packages can't see those.

For all three, dotnet build | Select-String "warning CS0618" is the only authoritative answer.

Manual fallback workflow

When MafRunCs0618Hunt is unavailable:

# Step 1: get the baseline
dotnet build 2>&1 | Select-String "warning CS0618"

# Step 2: for each warning, look up the canonical fix in the registry
# (the LLM should call MafRegistryLookup with the matching entry ID,
#  or open .github/skills/maf-obsolete-api-registry/registry.yaml)

# Step 3: apply the fix; re-run the build; confirm the warning is gone

# Step 4: move on to the next warning. Never batch.

# Step 5: declare done only when:
dotnet build 2>&1 | Select-String "warning CS0618" | Measure-Object | Select-Object -ExpandProperty Count
# returns 0.