[TOC]

An interactive dependency graph explorer for C# that helps you find cycles, simulate refactorings, and get AI-powered refactoring advice

You can import C++, Python and Java via doxygen, Java also via jdeps, and Dart/Flutter via the Dart analyzer.

This desktop app helps you explore, understand, and manage large C# codebases, especially when you face complex dependencies or architectural challenges.

Watch the YouTube demo → (Cycle analysis)

• Deep Code Analysis – Analyze your entire Visual Studio solution to map out a complete, precise code graph of your dependencies.
• Circular Dependency Detection – Instantly pinpoint component cycles and mutual dependencies that break your clean layering and architectural boundaries.
• AI Refactoring Advisor – Get intelligent refactoring suggestions to break complex cycles, powered by a Large Language Model (LLM).
• Incremental Graph Exploration – Build the exact graph you need to understand a codebase or solve a task. Map out dependencies step by step on demand (e.g., "show all incoming relationships"), and easily filter out unrelated code elements to keep the graph free of visual clutter.
• Sandbox Code Refactoring – Experiment with structural changes and simulate cycle-breaking strategies safely, without touching your actual source code.
• Architectural Guardrails – Define custom dependency rules and metric thresholds to actively validate and enforce a clean codebase.
• Dead Code Detection – Find the types and members nothing references any more, with the cases that only look unused flagged instead of hidden.
• Multi-Format Exports – Share your architecture by exporting diagrams to PlantUML, DGML, PNG, SVG, and more.
• Git History Hotspots – Uncover hidden technical debt by running hotspot or change-coupling analyses directly on your Git repository history.
• Design Structure Matrix (DSM) - Explore the System's dependencies at the type level.

• Windows (x64)
• .NET 10 Runtime (to run the application)
• .NET SDK or Visual Studio (provides MSBuild to load your solution)

The solution you analyze must load with the .NET SDK's MSBuild. SDK-style projects work out of the box; some legacy .NET Framework projects (notably old-style WPF) may fail to load even though they build in Visual Studio. See Supported projects and solutions for the details.

1. Download the latest release from the Releases page
2. Extract the zip and run CSharpCodeAnalyst.exe
3. Go to Home → Import → Import Visual Studio solution

This builds a complete in-memory graph model of your solution including assemblies, namespaces, types, members, and relationships.

Good to know: The tool analyzes the actual code graph, not your file system – meaning the physical directory structure of your source code is completely ignored. Also, external assemblies (like NuGet packages) are excluded by default to keep things fast, but you can enable them in the settings. See Limitations for details.

• Find and break dependency cycles – detect strongly connected components and get AI suggestions to untangle them.
• Explore your codebase interactively –trace method calls, expand inheritance trees, and follow relationships on a visual canvas.
• Export your graph — generate PlantUML, DGML, or PNG/SVG diagrams for your documentation.
• Validate architectural rules — define custom rules (like DENY or ISOLATE) and automatically check them in the app or your CI pipeline.
• Ask an AI assistant about your code – start a local MCP server and let Claude Code or another assistant query the loaded graph.

Besides the dependency graph tools, you can also analyze GIT history with the History Tool.

• Analyze a GIT repository

---

Read why you should look for and manage cycles in your code.

The cycle search always runs on the complete model.

1. Click Cycles in the ribbon
2. The Cycle Groups tab lists all detected cycles with the involved elements
3. Right-click a cycle group → Show in Code Explorer to visualize it as a graph. The Code Explorer (or canvas) is your interactive working area — a whiteboard where you place only the elements you need right now.
4. Optionally, click AI Advisor to get ideas on how to break the cycle

Note: Under the hood, the cycle search looks for "strongly connected components" (SCCs) rather than individual, elementary cycles. In plain English: it groups everything that is mutually reachable. A single group might contain multiple overlapping cycles, which is why they are bundled together in the UI.

The cycle search result is presented in the Cycle Groups Tab.

You can analyze a cycle group further in the Code Explorer.

The Code Explorer now offers a wide range of tools to analyze the cycle. A good strategy is to identify a set of dependencies that seem incorrect to you and focus on them first (see ‘Focus on Incoming Dependencies’, ‘Focus on Outgoing Dependencies’, ‘Focus on Selected Elements’, etc.).

Once you have loaded a cycle group into the Code Explorer, the AI Advisor button in the toolbar sends the cycle to a configured LLM and asks it for ideas on how to resolve or break down the dependency cycle.

To use this feature, open Settings and enter your API endpoint and key. The tool supports any OpenAI-compatible endpoint, including local models (e.g., Ollama) and Anthropic's API.

Take the advice with a grain of salt. The LLM has no idea about your actual business domain, team conventions, or broader system constraints. It might suggest things that are technically incorrect or completely impractical for your specific architecture.

Still, this feature can be very helpful for getting initial ideas when you face a complex cycle and are unsure where to start. The AI often spots structural patterns, like hidden abstractions, circular service dependencies, or missing interfaces, that are worth considering. You can save the advice as a Markdown file for later.

The refactoring simulation feature is simple but helpful. It lets you see how changes to your code structure affect cyclic dependencies without changing your source code. Often, you might find a large cyclic cluster, make changes in the code, and re-import the solution, only to see the cycle still there. This can be repetitive and time-consuming.

To streamline this, the tree view includes a Refactoring context menu that enables basic refactoring directly on the graph, bypassing the need to edit the source code.

You can explore scenarios such as:

• What happens if you remove a code element?
• What happens if you move a class to another namespace?
• What happens if you cut a dependency between two code elements?

After your modifications, you can rerun the cycle search to observe the impact.

Remember, this is a basic feature, and you can't undo changes to the code graph. It's a good idea to save your work before you begin.

Context Menu Options:

• Create code element – Adds a new element to the model.
• Delete from model – Removes the selected element from the model.
• Set as movement parent – Sets the current element as the parent for subsequent move operations.
• Move – Once a movement parent is set, this option moves the selected element and all its children to the chosen parent.

Additionally, in the Code Explorer:

• Delete edge from model – Deletes the relationships between two code elements. If the edge is bundled, multiple relationships get deleted.

---

The Code Explorer is an interactive canvas where you can explore unfamiliar codebases. You can trace calls, expand inheritance trees, and follow relationships step by step.

1. Use the Tree View or Advanced Search tab to search for code elements to add the canvas. The search expression supports type:class, type:method, source:intern, and ReSharper-style camel-case search (e.g. SC finds ShoppingCart).
2. Right-click an element on the canvas to explore its relationships with its neighbors.
3. Use the tool buttons in the Code Explorer to perform operations on multiple selected elements.
4. To keep the graph readable and prevent it from turning into a spaghetti monster, you can use the Hide filters in the ribbon, double-click container nodes to collapse them, or use the context menu to filter down to incoming/outgoing edges.

Here are some general examples of how to use the application to explore a code base.

• Essential concepts
• Find the call origins of a method
• Understand how you could split a large class

If your graph has more than about 200-300 code elements, it may slow down. But seeing that many elements at once usually isn't helpful. You can double-click container elements to collapse or expand them, reducing what's visible. When using Advanced Search to add several code elements, try adding them collapsed to keep things focused and the graph faster.

---

You can export your code graph (canvas) in various formats:

• DGML for further analysis in Visual Studio
• PNG or SVG image
• DSI if you want to import the graph into a dependency structure matrix tool
• Plain text
• PlantUML

When documenting code, a UML class diagram is often more useful than a colored code graph. You can create a UML class diagram from the code elements in your graph. All code elements are included in the diagram, even if they're collapsed or not visible.

Select "Copy to PlantUML class diagram" from the Export menu.

The PlantUML syntax is copied to the clipboard. You can use any online editor to render it.

Plain text might sound boring, but it's actually useful. If you feed a large language model your whole source code for refactoring, you’ll quickly run out of tokens or get garbage results. Instead, just give the LLM your prompt along with this text-based dependency graph. This greatly improves results and saves a massive amount of tokens. The LLM doesn't even need a description of the graph.

Since almost every field is optional, you can also write such a file by hand to create small toy graphs and load them via Import → Import plain text. The format is documented in plain-text-graph-format.md.

---

Codebases tend to decay over time if no one monitors the boundaries. With Architectural Rules, you can define strict guardrails (like "UI must not touch the Data layer") and automatically check your solution for violations.

For a full explanation of the supported rules, features and examples see: Architectual Rules

To set them up, open the Analyzers in the ribbon and click Architectural Rules.

The result of the analysis is shown in the table output for analyzers.

To integrate the tool into a build pipeline, you can call it without a user interface. You can find the syntax of the command-line here:

Command-line arguments

For an example how to use the architectural rules in a GitHub pipeline see: samples/ci-pipeline/

---

A Dependency Structure Matrix (DSM) displays system dependencies in a compact grid. Based on the convention used here, a numbered cell indicates that the element at the top (column) depends on the element on the left (row).

To learn how to read the matrix and spot architectural patterns, you can refer to the DSM Tutorial. Getting used to this view may require a bit of practice.

Note: The matrix does not show the entire raw codebase, but rather the type graph. For example, dependencies between individual methods are lifted to their corresponding types (this is the exact same graph used to calculate our system metrics). This abstraction keeps the DSM focused and clean.

• Ctrl + mouse wheel zooms the whole matrix (0.04 – 4.0). Plain wheel scrolls.
• Plain wheel scrolls up and down, shift + wheel sideways — from anywhere in the matrix, the headers included. Worth knowing because the scroll bars sit inside the scaled grid, so zooming out shrinks them along with everything else until they are too thin to grab.
• Click the arrow in a row header to expand or collapse; hold shift and it works recursively.

---

C# Code Analyst can calculate a few key metrics that matter.

You can read more about the supported metrics here: Metrics

All metrics are accessible via the Analyzer Ribbon, and the results are presented in a table on a separate tab.

C# Code Analyst can list code elements that nothing references anymore.

This is a heuristic only. There are many situations, like Reflection, DI, and XAML Bindings, that are not recognized. Therefore, each finding gets a confidence level.

You can read more about the rules and the limits here: Dead Code

The analysis is accessible via the Analyzer Ribbon, and the result is presented in a table on a separate tab.

C# Code Analyst can open a local MCP server, so an AI assistant like Claude Code can query the graph you currently have loaded.

This answers questions that are hard to get from the source files alone: who calls a method transitively, what breaks if you change a class, how two types are connected. Grep finds text, the graph knows relationships.

It works on whatever you have loaded, imported code included — the tools do not care which language the graph came from.

The server is off by default. You start it via Home → MCP → Start MCP server, and it only runs while the application does. It listens on localhost only, and all tools are read-only.

Here you can read how to set it up and what you can ask: MCP Server.

The tool is built for C# (has its own Roslyn-based parser), but you can also import Java, C++, Python and Dart via external tools.

Here you can read how it works: Other languages.

This gives you a basic visualization of your codebase. But this is more limited than C#.

Static analysis is great, but it misses how code evolves over time. Inspired by Adam Tornhill’s Your Code as a Crime Scene, this tool includes Git history analysis to uncover architectural patterns that no static analyzer can see – like change coupling and hotspots. To read more about these ideas, see also my other repository: https://github.com/ATrefzer/Insight.

Two files are coupled when they often change together. For example, one class encodes a file, and another decodes it. You cannot change one without the other. Such hidden dependencies can be made visible, which fits perfectly into a dependency analyzer tool.

For example, in the first row, 93.1% of commits that contain Item1 or Item2'' committed both items together; therefore, the files may be coupled.

The second analysis is a hotspot analysis. You can see an example in the screenshot below. The size (LOC) of a file is shown by the area of a rectangle, and the number of changes is shown by color. The deeper the color, the more often a file changed over time. Large files that change frequently are called hotspots and are worth keeping an eye on. A file only appears in this analysis if it was committed at least twice.

Finally, you can analyze a developer's contribution to a file.

This isn't related to dependency analysis, but it's helpful if you need to know who to ask for help or which parts to document when someone leaves the team.

The developer who contributed most to a file (based on a simple Git blame) is marked as the main developer, and the file is colored accordingly. This doesn't always mean that person knows the file best, but it's a good starting point.

Please keep these points in mind:

• The Roslyn-based parser covers the vast majority of the latest C# syntax. However, since C# syntax evolves rapidly with new versions, some cutting-edge features or edge cases might not yet map perfectly to the graph.
• The directory structure of the source code is completely ignored, so keep this in mind when searching for cycles. The one exception is the doxygen based C++/Python/Java import, where you can choose to derive the hierarchy from the directories instead of the namespaces (see Other languages).
• Source locations are not extracted for all dependencies; only those that are easily extractable are included.
• You can include external code by setting the "Include External Code" option. Only type dependencies are collected.
• A method defining a lambda expression only has "uses" relationships to types and methods inside the lambda. This is because I cannot track where the lambda is actually called. I think that is a good compromise.
• XAML Bindings are not resolved.
• Projects must be loadable by the .NET SDK's MSBuild. Legacy non-SDK .NET Framework projects — especially old-style WPF (net472) — may fail to load even though they build in Visual Studio. See Supported projects and solutions.

• The beautiful images in the user interface are Images from juicy_fish on Freepik. You can find the direct link to the collection here: Icon-Portfolio des Autors Juicy_fish | Freepik
• The dependency graphs are rendered with Cytoscape.js. The default layout is the fcose extension (built on cose-base / layout-base); additional layered layouts are available via dagre (with cytoscape.js-dagre) and ELK (elkjs with cytoscape.js-elk). Cytoscape.js, fcose, cose-base, layout-base, dagre, cytoscape.js-dagre and cytoscape.js-elk are MIT-licensed; elkjs is licensed under EPL-2.0. https://github.com/cytoscape/cytoscape.js / https://github.com/iVis-at-Bilkent/cytoscape.js-fcose / https://github.com/dagrejs/dagre / https://github.com/kieler/elkjs
• SVG export uses the cytoscape-svg extension by kinimesi, licensed under GPL-3.0 (same as this project). https://github.com/kinimesi/cytoscape-svg
• The minimap (bird's-eye overview) in the web graph view uses the cytoscape.js-navigator extension, licensed under MIT. https://github.com/cytoscape/cytoscape.js-navigator
• Drag and drop functionality is provided by the gong-wpf-dragdrop library. Copyright (c) Jan Karger, Steven Kirk and Contributors. Licensed under BSD-3-Clause. https://github.com/punker76/gong-wpf-dragdrop
• Markdown rendering in the AI Advisor window is powered by Markdig.Wpf and Markdig. Copyright (c) Nicolas Musset and Alexandre Mutel. Licensed under BSD-2-Clause. https://github.com/Kryptos-FR/markdig.wpf / https://github.com/xoofx/markdig
• The optional MCP server, which lets an AI assistant query the loaded code graph, is built on the Model Context Protocol C# SDK (ModelContextProtocol.Core), licensed under Apache-2.0. https://github.com/modelcontextprotocol/csharp-sdk
• The dependency structure matrix on the DSM tab is the viewer from DsmSuite, licensed under GPL-3.0-or-later (same as this project) and originally MIT-licensed by jmuijsenberg. A modified subset of it is vendored under ThirdParty/DsmSuite. https://github.com/ernstaii/dsmsuite.sourcecode / https://github.com/dsmsuite/dsmsuite.sourcecode

For complete third-party license information, see the ThirdPartyNotices folder.

Bug reports, feature ideas, and pull requests are welcome!

This project is licensed under the GPL-3.0 License.

Note: Versions prior to v0.9.0 were released under the MIT License.

• ✅ Use it freely in your projects (even commercial)
• ✅ Modify and improve it
• ⚠️ If you distribute modified versions, share your changes under GPL-3.0
• ℹ️ This is a development tool - it won't affect your analyzed code