Slnmap 0.1.4

Slnmap

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

Give your AI coding agent a map of your .NET codebase. Slnmap builds a local graph of your solution with Roslyn — every type and member as a node, every call / implementation / inheritance / reference / containment as an edge — stores it in SQLite, and serves it to agents and editors over MCP. So before an agent edits code, it can ask "what breaks if I change this interface?" and get a correct answer — including callers in files it hasn't opened.

Quickstart (3 steps)

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

dotnet tool install --global Slnmap

(Prefer building from source? See Build from source.)

2. Analyze your solution (or a single .csproj) — this 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 in your project. Use an absolute path to the slnmap.db you just built — an MCP client's working directory is usually not your project folder, so a relative path can silently resolve to the wrong (or a missing) file:

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

That's it. Ask your agent an architecture question and it will call Slnmap. (Run slnmap doctor first if anything looks off — see Troubleshooting.)

What you can ask

The server exposes five read-only tools. Give them fully qualified names; results are capped and counts-first. (A note the tools also carry: an FQN does not reveal whether a member is an explicit interface implementation.)

For an interface (or interface member), impact_analysis follows both the interface's callers and its concrete implementations/overrides — so the answer includes code that only touches the interface, across projects, in files nobody has open.

CLI

slnmap analyze <solution>   # build or update the code graph (incremental on re-run)
slnmap serve                # serve the graph to MCP clients over stdio
slnmap status               # show node/edge counts and when it was last analyzed
slnmap doctor               # check the environment can run Slnmap

--db <path> selects the database file (default slnmap.db).

Privacy

100% local. Your code never leaves your machine. Slnmap runs on your machine, reads your source with Roslyn, and writes a single local SQLite file. The MCP server reads only that local file. There is no telemetry, no network calls, and no cloud service — analysis works fully offline.

Performance

Measured on eShopOnContainers (dev branch, 30 projects), .NET 9 SDK, 4-core Windows box. Full detail in bench/RESULTS.md.

Honest note on incremental re-analysis. Slnmap re-walks only the changed file and its dependents (1 document, not 661, on the eShop test), but each run still pays a full MSBuildWorkspace load of the solution — about 20 s on a 30-project solution — because the CLI is run-and-exit and does not keep a warm workspace. So re-analysis is fast on graph work but bounded below by the workspace load; it misses the < 5 s goal today. A watch mode that keeps the workspace warm is planned (tracked in docs/BACKLOG.md).

Troubleshooting

Run slnmap doctor first — it checks the three things that actually block analysis and prints a fix for each:

$ slnmap doctor
[ok] .NET SDK: 1 SDK(s) installed; newest: 9.0.314 …
[ok] MSBuild workspace: Roslyn MSBuild workspace initialized …
[ok] Graph directory: Writable: /path/to/cwd

• "No .NET SDKs are installed" / MSBuild fails to load projects. Slnmap analyzes via MSBuildWorkspace, which runs design-time builds using your installed .NET SDK. Install the SDK (not just the runtime) from https://dotnet.microsoft.com/download. On Windows, if projects still fail to load, install the Visual Studio Build Tools (or Visual Studio) so MSBuild and the targeting packs resolve.
• Analysis prints warning: lines but finishes. That is expected and safe: a project that can't be loaded (missing SDK/targeting pack, unsupported project type) is reported as a warning and skipped — Slnmap indexes everything that did load rather than failing the whole run (a partial load).
• The first analysis of a large solution takes a while. Cold analysis compiles every project once (tens of seconds on a 30-project solution). Re-runs are faster on graph work but still reload the workspace — see the performance note above. This is normal; the graph is cached in slnmap.db between runs.
• slnmap: command not found after install. Ensure the .NET global tools directory (~/.dotnet/tools) is on your PATH, then open a new shell.

How it works

Analysis is incremental (only changed files and their dependents are re-walked), runs projects with bounded parallelism, and persists atomically (temp database + swap, WAL mode) so an interrupted run never corrupts the existing graph. The server holds no graph in memory: every tool reads from SQLite per request, and it survives the graph being re-analyzed underneath it.

Build from source

Contributors (or anyone who prefers not to install from NuGet) can build and install the tool locally:

git clone https://github.com/EMahmoudNabil/slnmap && cd slnmap
dotnet pack src/Slnmap.Cli/Slnmap.Cli.csproj -c Release -o ./feed
dotnet tool install --global --add-source ./feed Slnmap

Development

dotnet build
dotnet test

Conventions: .NET 9, nullable enabled, warnings as errors, central package management (Directory.Packages.props). CI builds and tests on every push; releases are tag-driven (see docs/RELEASING.md).