Slnmap 0.12.2

dotnet tool install --global Slnmap --version 0.12.2
                    
This package contains a .NET tool you can call from the shell/command line.
dotnet new tool-manifest
                    
if you are setting up this repo
dotnet tool install --local Slnmap --version 0.12.2
                    
This package contains a .NET tool you can call from the shell/command line.
#tool dotnet:?package=Slnmap&version=0.12.2
                    
nuke :add-package Slnmap --version 0.12.2
                    

Slnmap

Slnmap (sln-map) — a semantic map of your .sln for AI coding agents.

Open source under the MIT license. Source, issues, and full docs: github.com/EMahmoudNabil/slnmap

Your AI agent can't refactor .NET code it can't see. Ask an agent "what breaks if I change this interface?" and it guesses from the files in its context — missing callers in other projects and files it never opened. Slnmap gives the agent a precise, compiler-accurate map of your whole solution, so it answers correctly: every caller, every implementation, across every project. It runs locally and serves the map to your agent or editor over MCP.

Quickstart

1. Install (requires the .NET SDK 9.0+):

dotnet tool install --global Slnmap

2. Analyze your solution (builds slnmap.db in the current folder):

slnmap analyze path/to/YourSolution.sln

3. Connect your MCP client. For Claude Code, add this to .mcp.json, using an absolute path to the slnmap.db you just built:

{
  "mcpServers": {
    "slnmap": {
      "command": "slnmap",
      "args": ["serve", "--db", "C:/path/to/your/project/slnmap.db"]
    }
  }
}

The tools

The server exposes fifteen read-only tools — find_symbol, get_dependencies, impact_analysis, get_architecture_overview, find_usages, find_implementations, get_type_hierarchy, find_tests_for_symbol, get_project_dependencies, find_circular_dependencies, get_symbol_source, list_endpoints, find_endpoint, find_orphan_calls, and list_frontend_callsites (full descriptions in the README). For an interface, impact_analysis follows both the interface's callers and its concrete implementations/overrides — across projects, in files nobody has open. HTTP endpoints are first-class graph nodes — from ASP.NET Core Minimal APIs (v0.7.0) and attribute-routed controllers (v0.8.0): ask "which endpoint serves /api/vendors/42?" or "what breaks if I change this handler?" and get the actual route back.

There's also slnmap viz: exports the graph as a single self-contained, interactive HTML file — no server, no CDN, works offline. And slnmap watch (v0.10.0): analyze once, keep the workspace warm, and re-analyze on every file save — a one-file change lands in the database in about a second on a 10-project solution, and a slnmap serve running beside it keeps answering from the same file, so your agent's answers stay fresh while you type.

And slnmap analyze-ts (v0.11.0): adds TypeScript/React frontend HTTP call sites to the same graph — resolved route templates and an honestly-labeled unresolved bucket, six named reasons, never a guess. Requires Node 18+; the extractor itself is fetched via npx automatically.

And slnmap link (v0.12.0): joins those frontend call sites to the C# endpoints they actually hit, deterministically — after which impact_analysis on a handler surfaces the exact frontend call sites that break, and find_orphan_calls names every one that doesn't match anything, by exact reason, never a guess.

Privacy

100% local — and now you can verify it. No telemetry, no cloud service; analyze/watch/ serve/viz/status/doctor make no network calls at all. One documented exception: analyze-ts fetches its extractor from the public npm registry via npx (skip it to stay fully offline). Now that the CLI and MCP server are open source, the claim is auditable.

License & support

Slnmap is open source under the MIT license. The CLI and MCP server are MIT-licensed and will stay that way. Future hosted or team-oriented features may be commercial.

For questions or to report an issue, open a GitHub issue or contact hello@slnmap.dev.

Product Compatible and additional computed target framework versions.
.NET net9.0 is compatible.  net9.0-android was computed.  net9.0-browser was computed.  net9.0-ios was computed.  net9.0-maccatalyst was computed.  net9.0-macos was computed.  net9.0-tvos was computed.  net9.0-windows was computed.  net10.0 was computed.  net10.0-android was computed.  net10.0-browser was computed.  net10.0-ios was computed.  net10.0-maccatalyst was computed.  net10.0-macos was computed.  net10.0-tvos was computed.  net10.0-windows was computed. 
Compatible target framework(s)
Included target framework(s) (in package)
Learn more about Target Frameworks and .NET Standard.

This package has no dependencies.

Version Downloads Last Updated
0.12.2 0 8/24/2026
0.12.1 27 8/24/2026
0.12.0 52 8/22/2026
0.11.0 50 8/22/2026
0.10.0 53 8/21/2026
0.9.0 51 8/21/2026
0.8.2 106 8/14/2026
0.8.1 85 8/14/2026
0.8.0 93 8/12/2026
0.7.0 94 8/12/2026
0.6.1 89 8/8/2026
0.6.0 93 8/8/2026
0.5.0 103 8/7/2026
0.4.0 121 7/23/2026
0.3.0 107 7/22/2026
0.2.1 114 7/19/2026
0.2.0 104 7/18/2026
0.1.9 99 7/18/2026
0.1.8 112 7/18/2026
0.1.7 99 7/18/2026
Loading failed

Fix: two real cross-stack-linker/TS-extractor bugs, caught by the same
pre-launch discipline that found v0.12.1's linker bug -- a foreign-pattern trial deliberately
outside the tool's usual React+.NET test corpus. Neither reaches OSSUS_Frontend or the published
RealWorld sample; both are confirmed exact-match (reported call sites == persisted graph nodes)
on both before and after this fix. (1) A fluent method chain (two HTTP-verb-named calls on one
statement, e.g. an Express app.use(...).get(A).get(B) route-registration idiom) reported
byte-identical position data for every link, silently collapsing the second call site into the
first downstream -- fixed by anchoring each link's position to its own callee name instead of the
whole chain's start. (2) A +-built URL argument on an unrecognized HTTP-client receiver (e.g.
Angular's this.http.post('/x/' + id + '/y', ...)) was silently dropped instead of disclosed
whenever it didn't fully constant-fold -- the same free pass a template literal already got, now
extended to string concatenation; a new string-concatenation unresolved category covers the
equivalent case on a recognized client. Disclosure only, by design -- a non-constant
concatenation operand is still never resolved to a template.
Also: analyze now detects and discloses two previously-silent gaps instead of reporting a clean
"0 skipped" -- .razor files present on disk (Blazor component markup is not analyzed) and Razor
Pages (route by file location, a different routing system, disclosed the same way
conventionally-routed MVC controllers already are). Neither is modeled; both are now honestly
counted. See CHANGELOG.md for details.
Source: https://github.com/EMahmoudNabil/slnmap