Pick the issues to fix and let NDepend.AI do the rest. The issues to fix can be:
- the issues of one or several rules, or of a saved issue query,
- a quick preset, each one showing how many issues it matches,
- or the issues you describe in plain English.
NDepend.AI then works in fix rounds. In each round, the coding agent fixes a batch of issues,
then NDepend.AI builds the solution, runs the tests and re-analyzes the code.
Each round ends with a clear verdict, like targeted 6 → fixed 6, surviving 0, added 1.
More about AI Fix Issues
- Your coding agent: Claude Code, OpenAI Codex, GitHub Copilot CLI or JetBrains Junie.
A Direct LLM provider (OpenAI or Anthropic API key) is also available to generate code queries, but it cannot edit code.
- Two models per run: a premium model for the hard work and an economy model for the simpler tasks,
each with an optional effort level, like
opus@high.
The list of models is refreshed from ndepend.com, so new models show up without updating NDepend.
- Your own agents: run as one of your Claude Code agents, GitHub Copilot custom agents or Codex profiles, with
-agent-profile.
- NDepend.MCP.Server inside: the coding agent queries the NDepend code model, rules and issues through the integrated
NDepend.MCP.Server.
You can also plug in your own build of this open-source server.
- Your build: NDepend.AI shows the projects being built, with their warnings and errors.
A custom build command can be set with
-build-cmd. When the code doesn't compile, the run stops.
- A complete change log: issues fixed, issues suppressed with
[SuppressMessage], types split, types moved,
and project files edited (like the CODE_ANALYSIS symbol added so that suppressions compile).
- Safe and resilient: Ctrl+C stops the run at a safe point.
When the AI provider is overloaded or the network fails, NDepend.AI waits for it to recover
(
-wait-for-agent, 30 minutes by default) and tries again.
It even recovers when a test run crashes, with a stack overflow for example.
Closing the console also ends the coding agent process.
- Your consent first: commands that share your source code with the agent, or let it edit code, require your explicit approval.
Describe the code you are looking for, and NDepend.AI writes the CQLinq query or rule.
Ready-made examples help you get started, each one showing how many code elements it matches in your code base.
- The generated query opens in the NDepend query editor.
- Refine an existing query in natural language: the console highlights what changed.
- Fix the compilation errors of a query.
- Run it! runs the query right in the console.
- The query editor has a new Generate, Refine or Fix Errors button, depending on the query state.
- Works with a coding agent, or with Direct LLM and your OpenAI or Anthropic API key.
A new AI Assistant menu is available in VisualNDepend and in the Visual Studio extension,
with one-click commands: Fix Vulnerabilities, Fix New Issues (since the baseline) and Fix Code Smells.
An AI Fix Issues button also shows up whenever a code query or a rule matches issues.
It opens the AI Fix Issues dialog: add an optional prompt to steer the agent, check the Before you go notes,
then click Go Fix N Issues. The Command Line and JSON tabs give you the very same run, ready for your CI/CD pipeline.
More about the AI Assistant options
- The new Options > AI Assistant panel sets the AI provider and its models, the log (HTML or text, in a temporary folder or in the project output folder, opened or not at the end of the run),
the language of the AI summary (French, Japanese...) and the NDepend.MCP.Server to use: the default one, your own build, or none.
- These options are shared by VisualNDepend, the Visual Studio extension and NDepend.AI.exe. API keys are stored encrypted.
- Changing the AI provider proposes the provider and models you chose last time.
- When a command needs a coding agent and none is set yet, you are asked to choose one.
- A generated query opens in the NDepend query editor, and the AI provider chosen in the console is also set in VisualNDepend.
To fix the issues of the rule ND1600: Code should be tested,
NDepend.AI asks the agent to write the missing tests. It runs your tests after each fix round, collects the code coverage
and imports it into NDepend to measure the progress.
- Every test written must assert the outcome, as required by the new rule ND1611: Test methods should assert something.
- Change review: when a fix changes the behavior of a method, the review restores its original behavior before the run ends.
The report lists such methods as restored.
- Works with VSTest and Microsoft.Testing.Platform (MTP) test projects, and with the coverlet and Microsoft code coverage collectors.
- A new Generate Tests for Uncovered Code link is available in Project Properties > Code Coverage.
When the agent cannot cover some lines, it must explain why, and sometimes the reason is a bug.
Below, the retry logic of CatalogContextSeed.SeedAsync() rethrows the original exception even after a successful retry.
Instead of writing a test that would lock in this behavior, the agent reports a potential bug.
- The final report counts the potential bugs, and the source file view shows each one on the lines involved, with the agent's explanation.
- A potential bug is the agent's claim, not proven by a test: the report asks you to review it before trusting the green tests.
- The dead branches left in place are reported too.
- The agent also reports the bugs it spots while fixing issues. The Potential bugs row of the final report lists each one once, with a link to its line,
and the AI summary mentions them. A bug is listed only when a real input can reach it, never when only a test could fake the value (since v2027.1.1).
NDepend.AI also fixes architecture issues, such as the ones of the rule
ND1400: Avoid namespaces mutually dependent.
The report shows the dependency graph before and after the fixes.
- When a type moves to another namespace, its source file moves into the matching folder.
- Graphs follow the light or dark theme. Click a graph, then use the mouse wheel to zoom.
- When a class is split into smaller classes, the change log shows the graph of the resulting types.
Each run adds an AI Assistant tab to the NDepend web report.
It also writes a self-contained HTML (or text) log, with collapsible sections and a light/dark switch.
Browse some sample large-scale AI fix reports here.
The final report sums up what really happened, for example 496 / 511 fixed · 6 suppressed · 6 left on purpose · 3 still to fix · 97%,
with the new, unresolved and fixed issues in the whole project (497 fixed · 1 new · 13 unresolved), and the technical debt paid back (10d 6h).
More about the report
- The baseline is pinned at the start of the run: the code diff and the issues shown are about the changes made by the AI only.
- The Fixes by Rule Category and Source File table lists the new, unresolved and fixed issues of each source file.
Rows can be sorted, filtered with a search box and with rule-category chips, and each file links to its code diff.
- Each section shows its duration and its coding agent consumption: the cost in USD with Claude Code, or the tokens used with other agents.
The total duration is broken down, from the agent work to NDepend's own orchestration work.
- The AI summary links to the code elements in the source files, and can be written in your language.
- Expand the AI Thinking sections to see which model handled each task.
- Each report shows the command line of the run, and a command line ready for CI/CD, each one with a copy button.
- The report opens fast even for a very large run: the log of each fix round and the before/after graphs of a split type are loaded only when their section is unfolded (since v2027.1.1).
NDepend.AI.exe is a command-line tool that runs on Windows, Linux (WSL included) and macOS.
Started with no argument, it guides you step by step: the command, the project, the AI provider and the issues to fix.
Its commands are fix-issues, gen-query, refine-query, fix-query-errors and change-ai-provider.
- It works directly on a .sln or .slnx solution: when there is no NDepend project yet, one is created and analyzed.
-no-pause runs without any user interaction. It requires a Build Machine license, and is also available during the evaluation.
-settings reads all the arguments from a JSON file described by a JSON schema.
The LLM key can reference an environment variable, like "llm-key": "$env:NDEPEND_LLM_KEY", so that no secret gets checked in.
-log-file keeps a TXT or HTML log, written even when the run is interrupted, and -label tags a run.
- A run fixes up to 300 issues (30 during the evaluation), the most severe first. Run it again to continue with the rest.
|
- .NET 11 projects can be analyzed: ASP.NET Core, Blazor, Windows Desktop and Console.
- C# 15 runtime async methods have the flag
IMethod.IsAsync set.
- C# 15 union types have the flag
IType.IsUnion set, and the new property IType.UnionCaseTypes returns their case types in declaration order.
NDepend v2027.1 brings 28 new security rules about hard-coded secrets, weak cryptography, insecure deserialization,
injection, web endpoints and logging. Each security rule description now names its CWE,
and the rules are ordered with the most impactful first. A new Rules > Security menu lists them,
and AI Assistant > Fix Vulnerabilities fixes their issues.
See the 28 new security rules
Secrets and credentials
Cryptography and transport
Deserialization and XML
Injection
Web applications
Denial of service, logging and governance
Existing rules improved
The new Search Issues panel finds any set of issues in a few clicks,
and sends them to the AI with the AI Fix Issues button.
- Filter on the rule (name, id or category) and on the location (project, namespace, type or member). Prefix a term with
- to exclude it.
- Choose the issue status: new, unresolved, fixed or suppressed. Keep the top N issues and group them as you like.
- Each change generates a readable CQLinq query, run at once.
- Clicking an issue count in the Dashboard opens the panel with the matching filters.
It is also the first tab shown when a project is opened for the first time.
- A progress bar shows up while issues are being computed.
Test code is now analyzed along with the application code: when referencing a solution, test projects are no longer filtered out.
NDepend recognizes the tests written with xUnit, NUnit, MSTest and TUnit.
- New CQLinq domains
TestCode and ApplicationAndTestCode, and new flags
IsTestCode, IsTestMethod, IsTestClass and IsTestFramework.
- Test code has its own ocher color everywhere: query results, dependency graph, dependency matrix, metric view and project properties.
- Test code stays out of your way by default: the dependency graph has a new Exclude test code elements filter,
the search panel a Search also in test code button, the metric view a button to show test code, and the matrix lists test assemblies first.
- Dashboard figures, trend metrics and quality gates are about the application code. A new trend metric counts the tests.
- In the report, each source file lists the tests that cover its code.
New rules, new quality gates and default rules adapted to test code
- New rule ND1611: Test methods should assert something
in the category Code Coverage, active by default. It matches the test methods that call no assertion API, directly or through test helpers.
It knows NUnit, xUnit, MSTest, TUnit, FluentAssertions, Shouldly, NFluent, Verify, ApprovalTests, Moq, NSubstitute, FakeItEasy, FsCheck and more.
This is the first default rule that reports issues on test code.
- New rule ND1704: Code used only by tests
in the category Dead Code, disabled by default. It matches the application types, methods and fields used only by tests:
dead production code whose tests were left behind, or test helpers living in the application code.
- Three new quality gates measure the coverage of JustMyCode: overall, on new code and on refactored code. They are disabled by default.
- For the dead code rules, code used by tests is still alive.
- The Software Composition Analysis rules and the rule Assemblies Referenced in Multiple Versions also check the packages referenced only by tests.
<RulesExtractedFromCode ExcludeTestCode="True" /> ignores the rules declared in test assemblies.
Two new NDepend.Console switches analyze the code and run the rules
without building a report:
/QualityGateCheck outputs the quality gates status, the rules violated and the issues.
/IssueCheck ["rule or query"] outputs all the issues, or the issues of one rule or of one issue query.
Results are written in JSON (/OutJson, or /OutJson - for the standard output) and in SARIF 2.1.0 (/OutSarif),
ready for GitHub code scanning or the Visual Studio Code SARIF viewer. Both switches work with a Developer license or a Build Machine license,
on Windows, Linux and macOS. They are also a fast way for an AI coding agent to check its changes.
NDepend.Console.exe MyProject.ndproj /QualityGateCheck /OutJson .\qg.json /OutSarif .\qg.sarif
In VisualNDepend and in Visual Studio, the issues matched by a query can also be exported to a SARIF file,
from the menu next to the AI Fix Issues button.
New NDepend.API methods do the same from your own programs: TryExportQualityGatesAndIssues(), TryExportIssues() and TryGetIssues().
- In VisualNDepend, the less frequently used menus are hidden behind the ❯ button.
When the window is wide enough, the whole top bar fits on a single line to save screen space.
- The NDepend menu in Visual Studio is reorganized around the essentials: Dashboard, AI Assistant, Rules, Issues, Quality Gates,
Dependency Graph, Dependency Matrix, Web Report...
- Creating a project now offers two choices: New Project for .NET Solution, created next to the solution file and analyzed at once,
or New Blank Project.
- Project Properties has new Code Coverage and Baseline tabs, each one explaining what it brings, with its status at a glance.
- A new dialog, available from the Rules Explorer, updates your project rules with the new default rules of this version.
- In Search by Maintainability, the metric picker is easier to use, and the metric used to filter is shown in bold.
- Resolving thousands of assemblies from a folder is now 3 to 5 times faster. Application and test assemblies are shown in different colors.
- The Visual Studio extension now installs silently, and tells you when Visual Studio or a build must be closed first.
Coverage files are now found automatically. When you create a project from a solution, or add a solution or assemblies to a project,
NDepend looks for the coverage files written by dotnet test below the solution directory, in the TestResults folders.
It honors the <ResultsDirectory> of your .runsettings file, and also looks in the repository root.
This works from the Start Page, Project Properties, the Visual Studio extension, NDepend.Console.exe /CreateProject and NDepend.AI.
- The Cobertura files written by the Microsoft code coverage collector are now imported: coverlet is no longer required.
- The latest dotCover XML format is supported.
- The coverage settings dialog is simpler.
- A new project setting persists the coverage of each statement, so that the report can also show the coverage of the baseline code.
- The scrollbar shows where code was changed, added or removed, the coverage, and where the issues are. Hover an issue dot to see its tooltip.
- Baseline and current code stay in sync while scrolling. Added and removed code is highlighted in light green and light red.
- Fixed issues now show in the baseline pane, where they belong.
- Line numbers and scrollbars can be placed on either side of each pane, and the room given to each pane can be adjusted. Your choices are remembered.
- A source file now opens scrolled to its first issue.
- A new Tests panel lists the tests that cover the code of the file (100 tests per file by default, configurable in Project Properties > Report).
- Report generation is up to 40% faster on Windows machines where Microsoft Defender is on.
- The menu and scrollbars of SVG graphs show only when the mouse is over the graph.
See it live here, on a source file of the eShopOnWeb sample report.
When a type is moved to another namespace or assembly, renamed, or both, its issues and the issues of its members now remain matched with their baseline counterparts.
They are reported as unresolved issues that travelled with the type, instead of pairs of new and fixed issues.
Likewise, the regression rules no longer match a type moved to another namespace, nor a method moved to another type, nor a method whose code changed
only because of a namespace move or of a renamed dependency.
Many default rules were tuned on real code bases to report fewer false positives.
The rules that were noisy, or that led to risky AI changes, are now disabled by default.
Rule descriptions and how-to-fix texts are shorter: they are sent to the AI, so this lowers the token consumption.
See the rules tuned
- Types and namespaces created by a Roslyn source generator, with no source file on disk and not tagged with
[GeneratedCode], are now notmycode.
- ND3002: Discard generated Types from JustMyCode now also discards the types declared only in
generated source files (.g.cs, .g.vb, .generated.cs, .generated.vb), typically the output of Roslyn source generators.
A partial type with a hand-written part remains in JustMyCode.
- ND1207: Non-static classes should be instantiated or turned to static no longer matches classes created by a framework or a serializer.
- ND1400: Avoid namespaces mutually dependent no longer matches the usage of compiler-generated types (anonymous types, collection expressions).
- ND1700: Potentially Dead Types and
ND1701: Potentially Dead Methods no longer match
[ModuleInitializer] methods,
the types that hold them and everything they reach, nor the types derived from TypeConverter.
Their issue explanation now tells when an element is used only by elements that are potentially dead too, and names them.
- ND1700,
ND1701 and
ND1704: Code used only by tests
no longer match the types and methods the application finds at runtime through one of its own attributes read by reflection (a plugin, a migration, a handler...):
this code is in use, so an AI fix run no longer deletes it (since v2027.1.1).
- ND2012: Avoid having different types with same name no longer matches types declared in the same source file.
- ND2013: Avoid prefixing type name with parent namespace name no longer warns when the fix would give the same name to two or more types.
- ND2016: Methods prefixed with 'Try' should return a boolean now also accepts a value tuple, nullable or not.
- ND2103,
ND2104 and
ND2105, about namespaces and source file locations,
now ignore the source files linked from outside the project directory.
See the rules now disabled by default
See the new API members
ICodeElement.IsTestCode, IMethod.IsTestMethod, IType.IsTestClass, ICodeElement.IsTestFramework,
and the new code base views TestCode and ApplicationAndTestCode.
IType.IsUnion and IType.UnionCaseTypes for C# 15 unions.
TryExportQualityGatesAndIssues(), TryExportIssues() and TryGetIssues() to export issues and quality gates to JSON and SARIF.
IProjectManager.TryProbeCoverageDir() finds the coverage directory of a set of solutions and/or assemblies, with no analysis result needed.
It returns a TryProbeCoverageDirResult and an ICoverageDirScan describing the coverage files found.
IProjectManager.TryApplyCoverageDir() sets the coverage directory of a project, without ever overriding the coverage settings it already has.
IVisualStudioManager.TryResolveVisualStudioSolutionFromAssemblies() infers the solution of a set of analyzed assemblies.
SimpleNameEqualsAny(), SimpleNameContainsAny(), FullNameEqualsAny() and FullNameContainsAny() extension methods.
TryGetNDependProjectFilePathAttachedToVisualStudioSolution() now also reads .slnx solution files.
- The analysis no longer locks the analyzed assemblies: a build running in parallel, such as
dotnet publish, can now overwrite them.
- An assembly is now resolved to its managed .dll even when a native file with the same name, like the apphost .exe, sits next to it.
- For a project with several target frameworks, .NET 5+ assemblies are now preferred over .NET Standard and .NET Framework ones.
- Assemblies built with the .NET SDK artifacts output layout (
UseArtifactsOutput) are now resolved when the project targets several frameworks or declares a runtime identifier.
- Markdown code blocks (
```csharp) can now be used in the <Description> of a rule or query.
- In the Issue Info panel, the How to Fix section now comes before the rule description.
- The SonarQube plugin now shows the explanation of each issue.
|