Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A static code graph can connect a C# handler to the backend endpoint it serves and to React call sites that target that endpoint. In Mahmoud Nabil’s account of building slnmap, that connection turns “which screens might be affected?” into a traceable path through indexed code—not a guarantee about what will run in production.
What the graph answers—and what it does not
The useful question is not simply whether a frontend file contains a matching URL string. It is whether a frontend HTTP call can be resolved to a backend route, and whether that route is connected to the C# handler under consideration. Nabil describes slnmap as building those relationships across the .NET and TypeScript portions of a repository. The project account presents the result as a way to inspect possible change impact.
An edge in this graph means the tool resolved a static relationship in the indexed code. It does not prove a screen will execute that call under every runtime condition, nor does it establish that every screen-level effect has been found. The graph is evidence for investigation, not a substitute for tests or runtime tracing.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
How the cross-language path is built
Resolve .NET endpoints and handlers
On the backend, Nabil says slnmap uses Roslyn to analyze C# and model HTTP endpoints. Its route resolution accounts for patterns including route groups, controller tokens, constants and overloads. That gives the graph a route template associated with an endpoint, rather than relying only on a textual search for a path.
#1 Best Overall
Extract TypeScript HTTP calls
The frontend component, slnmap-ts, uses the TypeScript Compiler API and type checker to find HTTP call sites and resolve route expressions. According to the author, this includes cases where a route literal is reached through an imported constant. The tool can therefore connect some calls even when the URL is not written directly at the request site.
Link routes, verbs and call sites
A linker matches frontend and backend endpoint templates using HTTP verbs and precedence rules. When the relationships resolve, the impact path can be followed from a C# command handler to its endpoint and on to frontend call sites. In the author’s example, one endpoint connects to two call sites, one of them a shared hook. Showing that hook as a caller with multiple targets preserves the relationship without pretending it belongs to only one route.
The author’s stated principle is: “if the tool can’t resolve something statically, it counts it and says so. It never guesses.” That is a design claim from the project’s maintainer, not independent proof that every result is correct or complete.
What the reported coverage figures mean
Nabil reports results from a reference codebase: 743 frontend call sites, with 91% resolved to exact route templates; 716 of the 743 were linked deterministically, while the other 27 were disclosed with a reason. These are the author’s figures for one codebase. They are not an independently audited benchmark, and they should not be read as a general accuracy rate for other repositories.
Rank #3
The author also refers to an earlier experiment that resolved 96.6% of frontend HTTP calls to backend route templates. Its year and measurement method are not established in the available article result, so it is not a directly comparable or independently verified measure.
A verb mismatch can matter as much as a missing path
Nabil recounts a production dialog that sent POST to /organizationusers while the backend exposed GET at that path. He says this mismatch prompted a first-class orphan-call check that distinguishes a missing backend path from a path present under a different HTTP verb. The incident is the author’s account, but the distinction is useful when reviewing graph output: a familiar URL alone does not establish that the frontend call matches the backend operation.
Rank #4
Where the described analysis stops
The project account identifies several boundaries that matter when interpreting an impact path or an apparent absence of one:
Recommended Free Tools
- Blazor and Razor Pages are detected and disclosed, but are not yet modeled.
- MediatR
sender.Senddispatch is not traced, so a chain can stop at the handler rather than continuing through that dispatch. - Angular and Vue are detected, but their calls are mostly unresolved in the described implementation.
- Monorepo TypeScript configurations need per-package targeting.
These are disclosed limitations, not evidence that the repository has no relevant relationship. Before relying on a graph to scope a change, check which frameworks and project configurations it actually analyzed and inspect unresolved relationships.
Best Value
Try the workflow on a repository
Nabil describes slnmap as free and MIT licensed. The project account provides this command sequence for installing the .NET tool, analyzing backend and frontend code, linking graph data, and serving MCP tools:
-
Install the .NET tool:
dotnet tool install --global slnmap -
Analyze the solution:
slnmap analyze path/to/YourSolution.sln -
Analyze the frontend project:
slnmap-ts analyze path/to/frontend -
Link the backend and frontend graph data:
slnmap link -
Serve the MCP tools:
slnmap serve
Use the project’s own documentation to confirm command syntax and prerequisites for the version you install; the sequence above is the one supplied in the author’s account, not a guarantee that every release or repository layout uses identical options. Once analysis completes, start with the handler or endpoint of interest, follow the linked call sites, and review unresolved counts and framework coverage before treating the result as a change checklist. Verify consequential paths with the repository’s tests and, where appropriate, runtime behavior.
How to judge whether this approach fits your team
A cross-language graph is most useful when it can explain how it reached a link and expose what it could not resolve. When evaluating this workflow or another static-analysis approach, check:
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minute- Language and framework coverage: Does it model the backend and frontend technologies actually used in the repository?
- Route resolution: Can it handle the project’s route groups, constants, overloads and imported frontend constants?
- Matching rules: Does it account for HTTP verbs and ambiguous or overlapping route templates?
- Unresolved reporting: Are gaps counted and explained, rather than silently omitted or guessed?
- Repository integration: Can the workflow fit the team’s package layout and MCP tooling?
- Verification: Can developers check the static paths against tests or observed runtime behavior?
The account does not provide a head-to-head evaluation against other tools, so it supports trying the method on your codebase, not a claim that slnmap is superior to alternatives.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
