What's new in NDepend v2024.2

Report Improved

  • Dark mode.
    A new button allows users to switch between light and dark mode (see it live here).
    The default mode is now dark mode, but you can set light mode as the default in the NDepend Project Property > Report settings. NDepend-Report-Dark-Mode
  • An enlarge button allows the data grid displaying the list of source files to expand and fill the full width. NDepend-Report-Enlarge
  • The logs tab now includes buttons to select errors, warnings, or messages. NDepend-Report-Log-Filters
  • The code coverage pie chart has been vectorized for better rendering. NDepend-Report-Coverage-Pie
  • NDependReport.html is now compressed, reducing its size by a factor of 7 to 10.
  • Support for the browser's back and forward buttons now works when navigating the report.
  • New trend charts summary. NDepend-Report-Trend-Chart
  • Data grid pagination length is now managed through checkboxes instead of a combo box. It also displays the number of items, which updates when a filter is applied.  NDepend-Report-Pagination

Fewer False Positives

  • The notmycode queries Discard generated Namespaces from JustMyCode and the rules Avoid types initialization cycles and Avoid namespaces mutually dependent now don't match anymore code elements generated by PostSharp.
  • The notmycode query Discard generated Types from JustMyCode now excludes types generated by the compiler for collections with names ending in z__ReadOnlyArray<T>.
  • Unused constructor defined in an internal class implenting one or several interfaces might be used by Dependency Injection and is no longer regarded as dead code.
  • Unused methods are no longer regarded as dead code when tagged with UnityEngine.RuntimeInitializeOnLoadMethodAttribute or UnityEngine.InitializeOnLoadMethodAttribute.
  • Unused methods are no longer regarded as dead code when tagged with UnityEngine.RuntimeInitializeOnLoadMethodAttribute or UnityEngine.InitializeOnLoadMethodAttribute.
  • Unused types are no longer considered dead code when tagged with UnityEngine.RuntimeInitializeOnLoadAttribute and UnityEngine.InitializeOnLoadAttribute.
  • Unused types are no longer seen as dead code when they derive from UnityEditor.AssetPostprocessor.
  • Unused static classes are not classified as dead code if any of their methods are tagged with UnityEditor.MenuItemAttribute.
  • Unused types are not considered dead code if any of their methods or properties are tagged with JetBrains.Annotations.UsedImplicitlyAttribute.
  • Unused methods are not treated as dead code when their parent type is tagged with DebuggerDisplayAttribute, which may use the method in its expression.

Others Improvements

  • NDepend can now resolve an assembly to analyze from a complex expression in .csproj that looks like:
    <AssemblyName>Prefix.$(MSBuildProjectName.Replace(".","").Replace("-","_").Suffix</AssemblyName>
  • Import Roslyn Analyzer's issues with no message, with a default message "no message available".
  • New informational logs now display the number of issues found in each parsed SARIF file.
  • New API method in the class NDepend.Project.ExtensionMethodsProject:
    public static IController
       GetRulesInProjectFileAndInRuleFilesAndDeclaredInSourceCodeAndImported(
          this IProject project, IAnalysisResult analysisResult);

Full .NET 9.0 support

NDepend 2024.2 can analyze .NET 9 code

All .NET 9.0 project types can now be analyzed:

  • ASP.NET Core
  • Windows Desktop
  • Blazor
  • Console
NDepend can analyze all .NET 9.0 projects

C# 13 support

NDepend can now parse new C# 13 language constructs including:

  • New params collections
  • New escape sequence \e.
  • allow ref struct generic constraint
  • Partial properties and indexers

ReSharper Code Inspections' Issues Import

  • Issues emitted by any ReSharper Code Inspections can now be imported by NDepend at analysis time.
    All NDepend features take account of ReSharper Code Inspections' issues imported: Reporting, Quality Gates, diff since a Baseline, Debt Estimation, Trending Charts, LINQ Querying...
    See here the documentation about how to import ReSharper Code Inspections issues.
  • ReSharper Code Inspections are listed in the report Rules tab. See it live here.
    See more sample reports with imported ReSharper Code Inspections: NDepend-Report-ReSharper-Code-Inspections
    • 3 buttons let's select only ReSharper Code Inspections, Roslyn Analyzers or only CQLinq NDepend rules.
    • For each ReSharper Code Inspection we can see the number of new, unresolved and fixed issues since the baseline.
    • Clicking a ReSharper Code Inspections let's jump to its list of issues in the report (see it live here).
      For each inspection a link to its online description is added. If the analyzer embeds its description (which is not always the case) the description is gathered and shown above the list of issues. NDepend-Report-ReSharper-Code-Inspections-Issues-List
    • Clicking a ReSharper Code Inspection issue shows it in the source code section of the report along with its message (see it live here). NDepend-Report-ReSharper-Code-Inspections-Issues-In-Source-Code
  • When comparing against a baseline, NDepend determines which ReSharper Code Inspections' issue is new, unresolved or fixed since the baseline. This helps the team focus its code quality effort on newly written and refactored code.
  • ReSharper Code Inspections are now also listed in the UI Queries and Rules Explorer: NDepend-UI-ReSharper-Code-Inspections
  • A C# LINQ query is generated to list issues imported of a ReSharper Code Inspection. The same way all query generated to list issues (new issues, issues per source file...) now match ReSharper Code Inspections's issues. NDepend-UI-ReSharper-Code-Inspections-Edit

What's new in NDepend v2024.1

Roslyn Analyzers' Issues Import

  • Issues from any Roslyn Analyzer can now be imported by NDepend at analysis time.
    All NDepend features take account of Roslyn Analyzer's issues imported: Reporting, Quality Gates, diff since a Baseline, Debt Estimation, Trending Charts, LINQ Querying...
    See here the documentation about how to import Roslyn Analyzer issues.
  • Roslyn Analyzer's are listed in the report Rules tab. See it live here.
    See more sample reports with imported Roslyn Analyzers here: NDepend-Report-Roslyn-Analyzers
    • Two buttons let's select only Roslyn Analyzers or only CQLinq NDepend rules.
    • For each Roslyn Analyzer we can see the number of new, unresolved and fixed issues since the baseline.
    • Clicking a Roslyn Analyzer let's jump to its list of issues in the report (see it live here).
      For each analyzer a link to its online description is added. If the analyzer embeds its description (which is not always the case) the description is gathered and shown above the list of issues. NDepend-Report-Roslyn-Analyzers-Issues-List
    • Clicking a Roslyn Analyzer issue shows it in the source code section of the report along with its message (see it live here). NDepend-Report-Roslyn-Analyzers-Issues-In-Source-Code
  • When comparing against a baseline, NDepend determines which Roslyn Analyzer's issue is new, unresolved or fixed since the baseline. This helps the team focus its code quality effort on newly written and refactored code.
  • Roslyn Analyzer's are now also listed in the UI Queries and Rules Explorer: NDepend-UI-Roslyn-Analyzers
  • A C# LINQ query is generated to list issues imported of a Roslyn Analyzer. The same way all query generated to list issues (new issues, issues per source file...) now match Roslyn Analyzer's issues. NDepend-UI-Roslyn-Analyzers-Edit

New Projects Tab in the Report

  • The report contains a new Projects tab that lists projects of the analyzed application (see it live here). NDepend-Report-Projects
  • For each project some metrics are displayed:
    • number of new, unresolved or fixed issues (since the baseline)
    • new estimated technical-debt added (since the baseline) and overall estimated technical-debt
    • percentage coverage by tests (if coverage data is imported)
    • number of types and statements in the project
  • Clicking a project in the Project's list let's filter only its source files in the source files datagrid under the Issues tab. Doing so let's focus code review on a particular project. This is achieved by editing the project name in the search box of the source files datagrid.

    The same filtering effect can be achieved by clicking a project name of a source file in the source files datagrid. NDepend-Report-Projects-Sources

Other Improvements

  • Support for the new <UseArtifactsOutput> tag usable in Directory.Build.props files. This way NDepend can automatically resolve assemblies in the directory /artifacts/bin.
  • Rules and Roslyn Analyzers Ids (like ND1234 or CA1234) are now mentionned everywhere when it is relevant, in the report and in the UI.
  • The report's overall usability and design have been enhanced through dozens of minor improvements.
  • New menus have been introduced to simplify the import of Roslyn Analyzers' issues and enhance the ease of working with the Report. Report-Menu
  • Code has been refactored to reduce memory allocation by 30%, potentially leading to substantial performance improvements, especially on machines with limited RAM
  • Anti-aliasing is now applied to the boxes shown in the graph help panel.

What's new in NDepend v2023.2

Report Redesigned for Most Relevant Insights

The aim of this version is to deliver an in-depth .NET code quality management experience via an interactive web report.

The report is seamlessly generated in seconds through a CI/CD task. All DevOps technologies and OS are supported.

See some sample reports obtained on OSS code bases here.

Source files are now listed with a focus on regression since the baseline alongside code coverage ratios and effort-to-fix estimations. The list contains visual cues and can be easily filtered and sorted.

source file listed in ndepend report

For each source file a comprehensive all-in-one view is provided:

ndepend source file all-in-one experience
  • Issue Tracking: Identify new issues introduced since the baseline, as well as the status of unresolved and fixed issues.
  • Clear Explanations: Each issue is accompanied by a plain English description, making it easy to understand, along with a smart technical debt estimation indicating the effort required for resolution.
  • Differential View: If changes have been made, the source file is compared with its baseline version.
  • Coverage Insight: If code coverage data is available during analysis, each C# statement is highlighted in green or red. Changes in coverage since the baseline are given special attention.
  • Flexible Display: Each visual artifact can be enabled/disabled with just a single click.
  • Tools: find in code, go to next/previous, copy to clipboard, zoom in/out, dark theme and additional information (project, path, metrics...) are provided.

The report sections are now shown in tabs to improve the navigation.

ndepend report 2023

The rules summary in report has been improved with debt estimations, visual cues and search & filter tools.

rules ndepend report 2023

The user can easily navigate back and forth between a rule's explanation within the report, list of issues of a rule and for each issue, its location in source code.

rules ndepend report 2023

A new visual cue shows at a glance the quality gates status FAIL, WARN or PASS. The user can easily navigate from the quality gates status to their descriptions and root causes in source code.

quality gate ndepend report 2023

Trend charts are now more accessible thanks to the new Trend tab.

trend ndepend report 2023

Full .NET 8.0 support

NDepend 2023.2 can analyze .NET 8 code

All .NET 8.0 project types can now be analyzed:

  • ASP.NET Core
  • Windows Desktop
  • Blazor
  • Console
NDepend can analyze all .NET 8.0 projects

The NDepend analysis & reporting on Windows / Linux / Mac can now run on net8.0. net7.0 and net6.0 are still supported (since v2023.2.2).

C# 12 support and C# parsing improvements

  • C# 12 new features like primary constructor for class and inline arrays are supported .
  • 100% of code elements declarations in source are resolved, including declarations of fields, enumeration values, abstract methods, delegates, events, record class, record struct and anonymous namespaces.
  • The source declaration line of a concrete method is now the line that contains the method name, and not the line that contains the method body open brace character as it used to be. This makes reporting issues in source file clearer.
  • Locate and parse all **\*.cs files for project from .csproj Visual Studio Project SDK.
  • The Cyclomatic Complexity of a method is reduced by one for every call to a lambda, anonymous method or local function.

More with Less        (actually Much More with Much Less)

Even though more information are packed into the redesigned report, the analysis process for generating it is now 40% quicker. Even for very large code bases with thousands of source files and millions of lines of code scanned, the report generation takes less than a minute on a modern hardware, and just a few seconds for regular code bases (2.000 classes or less).

NDependReport.html report file size is now divided by 2 thanks to new optimizations. It now ranges between one and 5MB ensuring easy sharing and streamlined usability.

Performance Improvements in the UI

  • Loading the actual code base snapshot with the baseline snapshot is now parralelized which leads to 40% faster loading time.
  • All panels are lazy initialized which makes UI instantly responsive once snapshot(s) have been loaded.
  • Panel Project Properties > Code to Analyze is 41% faster to resolve all assemblies

Issue Explanation

In rules C# source code, you can now define a pattern for issue explanations, offering a new level of customization. Such pattern is now integrated into all default rules.

These issue explanations are displayed in both the NDepend UI and within the source code views in the report, enhancing your understanding and analysis capabilities.

ndepend issue explanation

Improvements

  • Support for parsing Jetbrains DotCover ReportType DetailedXml to gather statements coverage highlights in the report.
  • Rider64.exe is now resolved in the new default path which looks like C:\Users\$(usr)\AppData\Local\Programs\Rider\bin\rider64.exe (since v2023.2.2)
  • New properties on the interface ISourceFile: NbLines NbCharacters NbLinesOfComment CodeElements NbILInstructions NbLinesOfCode CoverageDataAvailable PercentageCoverage NbLinesOfCodeCovered NbLinesOfCodeNotCovered
  • New trend metric # Line Feed. Also the Dashboard now lists # Line Feed and # Line Feed delta since the baseline.
  • The Dashboard is now refreshed without flickering thanks to double buffering.
  • In Project Properties > Code to Analyze, assemblies are now resolved from first to last which makes it more convenient for the user to track resolving.
  • A visual cue is now shown on query result cells that are expandable.
  • NDepend: A visual cue is now shown on query result cells that are expandable.

Fewer False Positives

As with every release, reducing the number of false positives remains a top priority for us:

  • If the same element was declared in several assemblies, its issues were duplicated for each occurrence. Not anymore.
  • The notmycode query Discard generated Fields from JustMyCode now matches fields declared in generated source files.
  • Discard generated Namespaces from JustMyCode now also matches AspNetCoreGeneratedDocument, namespaces with names like Microsoft.Maui.Controls that are generated by the MAUI infrastructure, and namespaces and anonymous namespaces that only contains types generated by the compiler.
  • Discard generated Assemblies from JustMyCode now discards empty assemblies with no type, and assemblies with no C#, VB.NET, and F# code.
  • Discard generated and designer Methods from JustMyCode now matches Razor markup methods declared in .cshtml source files.
  • Discard generated Types from JustMyCode now matches Razor markup types declared in .cshtml source files and also matches interop types tagged with System.Runtime.InteropServices.TypeIdentifierAttribute.
  • The rules Code should be tested and New Types and Methods should be tested now aggregate methods within their parent type when the type is 0% covered. This can lead to much fewer issues, and the overall estimated debt (effort to fix) remains constant since it is aggregated into the single issue on the parent type. Also, it doesn't match anymore refactored methods whose signature has been modified.
  • The rule ND1603 doesn't match untested types anymore since they are caught by other rules. It has been renamed Assemblies and Namespaces should be tested.
  • The rule Methods refactored should be tested could report some changes because of internal IL changes. Now it reports only source changes.
  • Coverage-related rules now only report issues on the JustMyCode domain.
  • The rule Namespace name should correspond to file location now emits only a single issue per the concerned namespace.
  • The rule Avoid duplicating a type definition across assemblies now only takes account of types in the JustMyCode domain.
  • Constructors of abstract classes should be declared as protected or private could match constructors declared as private protected.
  • The rule Methods prefixed with 'Try' should return a boolean doesn't warn anymore on async methods that might return a Task.
  • The rule Methods should be declared static if possible doesn't match anymore Razor methods named OnGet, OnPost, OnGetAsync, OnPostAsync.
  • Rule Uri fields should be of type System.Uri now only runs against JustMyCode fields and not all Application fields.
  • The rules Types that could have a lower visibility, Methods that could have a lower visibility, Fields that could have a lower visibility, and Avoid public methods not publicly visible don't match anymore potentially dead elements, candidates for removal.
  • The rule Avoid methods potentially poorly commented has higher thresholds.
  • The rule From now, all methods added should respect basic quality principles has higher thresholds and doesn't match refactored methods whose signature has been modified.
  • The rule From now, all types added should respect basic quality principles now has more drastic criteria to estimate poor-quality new types.
  • The rule Avoid adding methods to a type that already had many methods now has higher thresholds.
  • The rule Avoid partitioning the code base through many small library Assemblies now matches only library assemblies containing 3 or fewer types.
  • The thresholds in the rules Assemblies with poor cohesion (RelationalCohesion) and Namespaces with poor cohesion (RelationalCohesion) has been set to identify only those assemblies that clearly exhibit a deficiency in cohesion.
  • The rule Overrides of Method() should call base.Method() now requires that the base method contains significant code to call from the override method to emit an issue.
  • The rule Avoid prefixing type name with parent namespace name doesn't match types with the same name as a namespace since there is the rule Avoid naming types and namespaces with the same identifier for that.
  • The rule Fields should be declared as private or protected doesn't match anymore fields assigned outside its class since this issue is matched with the rule A field must not be assigned from outside its parent hierarchy types.
  • The rule Types with disposable instance fields must be disposable now only considers disposable fields instantiated at construction time.
  • The rule Avoid types with too many methods now requires at least a non-constant field in the type to match it, because it is ok to have many stateless methods in a class.
  • The rule Do not raise reserved exception type doesn't consider NullReferenceException anymore.
  • The rule Don't assign static fields from instance methods and Avoid non-readonly static fields now operates on JustMyCode.Fields.
  • The rule Enum Storage should be Int32 doesn't warn anymore on enums of type long or ulong.
  • The threshold in rules Avoid methods with name too long and Avoid fields with name too long went from 40 characters to 50.
  • The rule Instances size shouldn't be too big threshold went from 128 bytes to 256 bytes.
  • The rule Avoid types with poor cohesion LCOM threshold went from 0.84 to 0.91.
  • The rule Avoid methods too big, too complex now requires a Cyclomatic-Complexity score higher than 17.
  • The log Assembly {XYZ} doesn't contain any type. is now an info and not a warning anymore.

What's new in NDepend v2023.1

Support for Properties and Events

  • The NDepend code model is now filled with properties and events thanks to the new interfaces IProperty and IEvent. Until now only accessors methods and backing fields were analyzed and some details like attributes tagging properties and events were missing.
  • Those interfaces propose all members needed to query those code elements.
    public interface IProperty : IMember, IUser {
       IMethod GetMethod { get; }
       IMethod SetMethod { get; }  // Null if IsReadOnly
       IField BackingField { get; }
       IEnumerable<IMember> AccessorsAndBackingField { get; }
       bool IsReadOnly { get; }
       bool IsWriteOnly { get; }
       bool IsReadWrite { get; }
       IType PropertyType { get; }
       bool IsIndexer { get; }
       bool IsRequired { get; }
       bool IsExplicitInterfaceImpl { get; }
       bool IsAbstract { get; }
       bool IsNewSlot { get; }
       bool IsFinal { get; }
       bool IsVirtual { get; }
       IEnumerable<IProperty> OverridesDerived { get; }
       IEnumerable<IProperty> OverridesDirectDerived { get; }
       IEnumerable<IProperty> OverriddensBase { get; }
       IEnumerable<IMethod> MethodsUsingMe { get; }
       IEnumerable<IMethod> MethodsReadingMe { get; }
       IEnumerable<IMethod> MethodsWritingMe { get; }
       IEnumerable<IMethod> MethodsCalled { get; }
       IEnumerable<IMember> MembersUsed { get; }
       IEnumerable<IField> FieldsUsed { get; }
       IEnumerable<IField> FieldsAssigned { get; }
    }
    public interface IEvent : IMember, IUser {
       IMethod AddMethod { get; }
       IMethod RemoveMethod { get; }
       IField BackingField { get; }
       IEnumerable<IMember> AccessorsAndBackingField { get; }
       IType EventType { get; }
       bool IsExplicitInterfaceImpl { get; }
       // ... same as IProperty above
    }
  • The API and code querying has been improved to support properties and events with:
  • Several default rules have been improved with this new APIs including
  • Properties and events can now be harnessed from any tool feature including: dependency graph;  dependency matrix;  code querying;  advanced search;  diff since baseline;  Visual Studio code editor and solution explorer extra NDepend menus;  decompilation with ILSpy;  suppressing an issue on a property or an event;  declaring a code rule in source code through a tag on a property or event...
NDepend properties dependency graph

Support for Windows High-Contrast

The NDepend UI now adapts to Windows High-Contrast mode when this mode is enable.

NDepend support-for Windows High Contrast

Improved Class Browser

  • The Class Browser panel has been replaced with a Search Panel Tab. This way there can be multiple Class Browser instances and the user can filter by name or by kind of code element (Assembly, Namespace, Type, Method, Field, Property or Event).
  • Class Browser as a Search Tab is possible thanks to the new search by name setting: Match all when empty string
Class Browser as Search Tab
  • User can choose how a namespace hierarchy is displayed, tree or flat. In previous NDepend versions this global setting only applied to Class Browser and the Dependency Matrix. Since the Class Browser is now a special Search panel, the namespace hierarchy setting now only applies to the matrix. As a consequence it can be set from the matrix toolbar.

Simplified Exploration of Changes since the Baseline

  • When right-clicking a project, an assembly, a namespace or a type, the 6x menus under What was changed have been simplified to a single menu button Diff since the Baseline. This new menu generates a code query that lists all changes within the element.
  • The screenshot below shows such a generated code query and list of changes within the project Nop.Core grouped by source files. Changes can be instead grouped per namespaces and classes.
Simplified Exploration of Changes Since Baseline
  • If the element is declared in a single file, like a class or a method, the source code diff tool is opened instead to compare both versions.
  • In the screenshot above we can also see another v2023.1 improvement: When grouping elements matched by a query through directories and files, now the parent directories are grouped under a root directory (if any) and their paths relative to this root directory is shown (like .\Caching in the screenshot).

Access to Rider and VSCode Most Recently Used (MRU) Solutions

The .NET solution chooser dialog now also lists Rider and VSCode Most Recently Used (MRU) Solutions if these IDEs are installed.

NDepend MRU Solution Rider VSCode

Improved Visual Studio Extension Install Experience

  • When installing the extension in Visual Studio a second time, VSIXIntaller.exe popped-up an annoying message box This extension is already installed to all applicable products. Not anymore.
  • When installing or uninstalling the NDepend VS extension, the installation status is reflected by a check icon instead of showing a message-box about the success of the operation. NDepend Visual Studio Installed Check

Simplified Browsing of Large Query Results

  • In a query result, clicking the Expand or Collapse buttons now expands or collapses just on one grouping level when there are more than 20+ matched items. This simplifies browsing large results with hundreds or thousands of rows.
  • A double click on one of these buttons leads to the behavior expand all or collapse all (recursive) as in previous NDepend versions.

Select Children menu for Project, Assembly, Namespace and Type

New right-click menu Select Children available for projects, assemblies, namespaces and types. This menu generates a code query to browse and search within the concerned code element.
The screenshot below shows such a generated query. The search line has been uncommented to search for elements named like "cu" case-insensitive.

Select Assembly Namespace Type Children

Simplified Query Navigation

When a query is generated from a Search or Query Edition tab, the query generated panel now has a new button to go back to the tab that generated the query.

Back To Tab That Generated A Code Query

Less False Positives

Usability Improvements

  • Go to Method, Field, Property or Event return Type now opens a new search tab to match the type.
  • Global menu Source Diff since the Baseline now lists diff through the Search by Diff panel in a more browsable way.
  • When a query result has only one column - the tree of code elements matched - the width of this column is set to the actual available width. This way no info gets unnecessary hidden because of a too short width.
  • In VisualNDepend, new support for the keys Enter, F8 and Shift+F8 to go through matched code elements or issues within a query result.
  • 2x new options in the dependency graph to eventually make it more readable:
    • to avoid prefixing a type name with its parent namespace name when not grouping types' boxes by namespaces
    • and to avoid prefixing a member name with its parent type name when not grouping members' boxes by types.
  • A new option in the dependency graph lets the user zoom faster on deep graph. Alternatively, to quickly zoom on an element, click the Search button, search an item by name in the graph's items and double click it in the Search result.
  • The Option Form is now larger for a better display.
  • In the Dashboard panel, the trend chart range selected is now persisted across sessions. Also, now the range choices are shown within a popup menu for a clearer UI.
  • In the Query Edition panel, the 3x checkboxes related to which sections of the query result are shown in the report are now grouped under a combo box. This makes the Query Edition panel clearer.
  • In Query Result the statistic row is now hidden when it doesn't bring any value. These situations include when the query result is a scalar, when the query result is just a code element tree with no additional column or when expanding the sub-result view like when searching for types' coupling.

Improvements

What's new in NDepend v2022.2

NDepend GitHub Action

  • Code Quality Reporting from the GitHub Build: This GitHub Action lets run an NDepend analysis after each rebuild and explore results in a shared interactive HTML+js report (see some sample reports here ).
    Reports generated by the GitHub action contain links to code source hosted by GitHub.
  • Try this new action: See the getting started documentation here. See the action on the GitHub marketplace here.
  • Confidentiality: The NDepend GitHub Action runs only on the worker machine and zero data is shared remotely (source code, account settings or anything else) with ndepend.com or any other third-party.
  • Build Fail: This Action can also fail the build upon some Quality Gate(s) failure (documentation link). NDepend Action Build Failure
  • Build Summary: An NDepend summary is available in your build summary to show the Quality Gates and issues status. Quality Gates are explained in the section above. (documentation link). NDepend GitHub Action Build Summary
  • Pull Request Quality Check: When an analysis is done after the creation of a Pull Request, the NDepend action adds a comment to your PR. This comment contains the quality gates status and the number of issues per severity, same presentation as the Build Summary in the screenshot above. And to have more details you can click on the link provided in the comment.
  • Use a Run as Baseline: A previous GitHub run result can be used as a baseline to compare code and code quality against. (documentation link).
  • Import Code Coverage Data: Code coverage data can be imported by the NDepend GitHub action to rule coverage ratios. (documentation link).
  • Download Results from GitHub: With a Developer license, the standalone app VisualNDepend.exe or the NDepend Visual Studio extension can download the NDepend Github Action analysis results locally for further exploration (documentation link).
    The baseline result can also be downloaded from GitHub automatically when analyzing through NDepend.Console.exe if it is not available locally. (documentation link).

Open Source Code Declarations in Rider or VSCode

It is now possible to plug Jetbrains Rider or Visual Studio Code to open source code declarations.

Both IDEs can also be used to diff changes in source code made since the baseline.

This way the standalone executable VisualNDepend.exe can work side-by-side with these IDEs.

Open Source Code Declarations in Rider or VSCode

Default Rule Update and Lightweight Project File

Untouched default queries and rules are now persisted by default through their query ids, or just query names for the ones that don't have ids. The benefits are twofold:

  • NDepend project files weight much less (from 570KB to 70KB roughly)
  • Untouched default rules and queries are automatically updated to their new versions when a new version of NDepend is used.

Any query change - like just adding a space - is enough to consider a default query as touched and thus, not persist it through its id.

Since v2018.2.0 dozens of false positive situations have been fixed in the default rule set. Your existing project will now benefit from these improvements. This is because any NDepend project created with NDepend version 2018.2.0 (released on the 11th September 2018) or higher, will see its untouched default queries updated to their id upon the next query change.

A project setting let's go back to plain-text storage mode for untouched default queries and rules. Notice that when an NDepend rule file (.ndrules extension) shared among several NDepend projects is created or modified, it inherits this setting from the current project setting.

Analysis Result Id

An analysis result can now be identified with a human-readable identifier. Often such identifier will be a build number, a version or a milestone name.

The identifier is shown in the Dashboard for both the current snapshot and the baseline snapshot.

The new NDepend.Console command line argument /AnalysisResultId let's precise an identifier to the analysis result.

The NDepend APIs RunAnalysis() and RunAnalysisAndBuildReport() can now accept an identifier as an optional argument.

An identifier can be manually added to any existing analysis result file (.ndar extension). For example if the file name is NDependAnalysisResult_ProjectName_2022Oct11_13h14.ndar to assign the identifier "v2022.5.6" just rename to NDependAnalysisResult_ProjectName_2022Oct11_13h14_Id_v2022.5.6.ndar. As a consequence an analysis result identifier cannot contain characters that cannot fit in a file name \ / : * ? \" < > |. Also it must have a maximum of 64 characters.

Full .NET 7.0 support

NDepend 2022.2 can analyze .NET 7 code

All .NET 7.0 project's kinds can now be analyzed:

  • ASP.NET Core
  • Windows Desktop
  • Blazor
  • Console
NDepend can analyze all .NET 7.0 projects

C# 11 support

Code containing some C# 11 raw string literals and C# 11 static abstract members can now be analyzed.

New property IType.IsVisibleOnlyInFile to detect when a type is declared with the C#11 keyword file (added with v2022.2.1).

The rules Avoid duplicating a type definition across assemblies, Avoid defining multiple types in a source file and Types that could be declared as private, nested in a parent type have been updated to avoid matching types declared with the C#11 keyword file (added with v2022.2.1).

NDepend can run on .NET 7.0 and .NET 6.0

.\net7.0\NDepend.Console.MultiOS.dll
and
.\net7.0\NDepend.PowerTools.MultiOS.dll
now run on .NET 7.0 on Windows, Linux and MacOS (since v2022.2.1).

.\net6.0\NDepend.Console.MultiOS.dll
and
.\net6.0\NDepend.PowerTools.MultiOS.dll
now run on .NET 6.0 on Windows, Linux and MacOS.

Visual Studio 2022 ARM support

The NDepend extension can now run within Visual Studio 2022 ARM from Visual Studio 2022 version 17.4.0 and onward.

Immutable NDepend Project Files

Before NDepend v2022.2 an NDepend project could be modified when used on a machine different than the one that created it. This is because directories of the local .NET installation (including NuGet package directories) were referenced and these directories could change on a different machine.

Now only the .NET Profile is stored in the project and these directories are inferred from it. This makes the NDepend project immutable, no matter on which machine it is used. This makes it more convenient to store the NDepend project file in the SCM (Source Code Management).

Load the NDepend Project side-by-side with the VS Solution

There are contexts like Unity where the solution file can be re-generated. In such context an NDepend project cannot be attached to such solution.

This is why now per default, when a solution gets loaded in Visual Studio, the NDepend project that is in the same directory and that has the same solution file name (except the file extension) gets loaded even if it is not attached to the solution.

This behavior can be de-activated through a setting in Options > Visual Studio Extension Attach.

Improvements (added with v2022.2.1)

  • New property IType.IsReadOnly to detect when a structure is declared as readonly.
  • New rule Immutable struct should be declared as readonly (ND1914) to detect immutable structures that are not declared as readonly.
  • In the Graph, Matrix and Metric views, the user can now choose if mouse-wheel provokes zooming (default and actual behavior) or vertical scroll in the new Options > Miscellaneous panel. Notice that Ctrl+Mouse-wheel let's perform the other action.
  • A new option in the new Options > Miscellaneous panel now let's discard the ding sound played when showing an NDepend dialog that requires user attention (licensing matters, new version available, when about to close with data unsaved...).
  • A new option in the Options > Miscellaneous panel let's prevent a tooltip to appear when hovering the NDepend circle in the status bar (both in Visual Studio and VisualNDepend).
  • When using Rider to edit and diff source files, rider64.exe is also resolved in ToolBox directory like %AppData%\Local\JetBrains\Toolbox\apps\Rider\ch-0\2022.4167.23\bin\rider64.exe.
  • When the debt settings are stored in a shared .ndsettings file, when changing some debt settings and then save them, there are only persisted in the .ndsettings file, the project file (.ndproj) is left untouched.

Improvements (added with v2022.2.0)

  • Improvement of the heuristic that resolves an assembly path from a
    .csproj
    and
    .sln
    files. For example when a
    Directory.Build.props
    file contains
    <AssemblyName>$(SolutionName).$(MSBuildProjectName)</AssemblyName>
    the proper assembly name is now resolved.
  • Assemblies resolution now also searches in
    Release
    directories if the assembly is not located under a in
    Debug
    like directory.
  • Parsing the source code at analysis time is around 10% faster.
  • Clustering large set of nodes on the dependency graph could create too large clusters. This has been improved to obtain more readable graph in any situation.
  • In the dependency graph, when applying some filters that led to a graph with zero node, filters applied get modified to get at least one node. Now in this situation a message is shown to the user explaining this filter modification.
  • New NDepend API method
    IProjectReport.RebaseSourcePathsInReport(string fromPath, string toPath, string lineSuffix)
    to rebase any file path location to something else like a GitHub source url. For example calling:
    project.Report.RebaseSourcePathsInReport(
        "root", 
        "https://github.com/ndepend/xy/blob/main", 
        "#L$LineNumber$");
    before calling
    project.RunAnalysisAndBuildReport();
    transforms
    C:\a\root\ClassLibrary\test.cs Line 76
    into
    https://github.com/ndepend/xy/blob/main/ClassLibrary/test.cs#L76
    .
  • The rule
    ND1800: Methods that could have a lower visibility
    doesn't match anymore constructors of classes deriving from
    System.ComponentModel.EnumConverter
    , because these classes are instantiated dynamically.
  • Analysis result storage is now rounded to seconds instead of minutes. Hence two analysis results obtained within the same minute can be stored side by side if the project setting Persist Analysis Result Frequency is set to Always.
  • 3x new trend metrics related to code coverage overage on JustMyCode:
       Percentage JustMyCode Coverage
       # Lines of JustMyCode Covered
       # Lines of JustMyCode Not Covered
  • The query
    Quality Gates Evolution
    now produces a more comprehensive result.

What's new in NDepend v2022.1

Report Improvements

  • Some rules and code queries result's cells match several items (like several classes or several issues). A new report setting allows to unfold up to N items in the concerned queries' results' cells. This setting is set by default on new projects with N=5.
  • When the source file declaration(s) of a code element has been resolved at analysis time, per default there is a link to this declaration for each occurrence of the code element in the report. A new project setting is here to choose whether the linked path is absolute or relative to the project file location.
  • Now code element's icon are shown in report by default.
NDepend improved report
  • These new features are enabled by default on new projects and on existing projects.
  • New flags in the enumeration NDepend.Project.ReportOptionsFlags: DontUnfoldMultiItemsCell DontShowCodeElementIcons DontLinkElementToSourceFile LinkElementToRelativeSourceFile
  • In report "View Query Description" is now replaced with "View Quality Gate Description" and "View Trend Metric Description" on this kind of queries.

Query Result Export Improvements

It is now possible to export a query result to JSON and CSV format.

NDepend improved report

New export options to:

  • Unfold or not multi-items cell.
  • Chose to prefix (or not) the exported result with the query body.
  • Chose to suffix (or not) the exported result with the statistics for each column.
  • Prefix code elements names in exported document like with C: for classes, M: for methods...

Right clicking a group in the Queries and Rules explorer panel can be used to export several queries' results to HTML, XML or JSON. When exporting dozens or hundreds of queries the UI remains responsive (instead of freezing as before) and an Abort button is now shown.

Exporting multiple query results

The last chosen export format is stored across session and re-used when opening a new query or search panel. Also for each panel restored from a previous session the export format is remembered.

New API extension method ExtensionMethodsQuery.ExportQueryResult(this IQueryExecutionResult, QueryResultExportDocumentKind) to automate exporting query result to the various formats (HTML, XML, Excel, JSON, CSV, Text).

Coverage Exclusion through .runsettings file

(v2022.1.1 only)

NDepend can now read and process the .runsettings file's coverage exclusion and inclusion rules to obtain coverage statistics similar to the ones provided by other coverage tools. Here is the official Microsoft documentation concerning coverage exclusion through .runsettings file. A .runsettings file can be provided from Project Properties > Analysis > Code Coverage > Settings:

specify a runsettings file from NDepend project

When analyzing an NDepend project that references a .runsettings file, some NDepend analysis logs provide details about the processing of these coverage exclusion and inclusion rules.

runsettings Coverage Exclusion Inclusion Logs

Improvements

  • Code coverage overall ratio computation has been changed and now better reflects the ratio shown by coverage tools.
  • New property INamespace.IsGeneratedByCompiler to be able to filter out namespaces like Microsoft.CodeAnalysis or System.Runtime.CompilerServices that are generated by the compiler. This way such generated namespace doesn't clutter the dependency graph or matrix.
  • New property IAssembly.CompanyName that gets the string value of the attribute System.Reflection.AssemblyCompanyAttribute, or empty string if this assembly hasn't such attribute.
  • New property IAssembly.PublicKeyToken that gets the hexadecimal upper string value of the PublicKeyToken of the assembly, or empty string if this assembly is not signed.
  • The heuristic to resolve an assembly from a .csproj project file now better handle <BaseOutputPath> value.
  • The heuristic to resolve an assembly from a .csproj project file now also investigates child directories named b that might contain binaries.
  • At analysis time, types provided in types and methods' generic parameters' generic constraints are now seen as used by the type (or parent type for generic method).
  • When opening the source file declaration of a class or a method declared in a .razor file, the declaration is now opened at the right line.
  • VisualNDepend or Visual Studio extension startup takes around 0.2 second less thanks to lazy instantiation of theme resources.
  • The rule Class with no descendant should be sealed if possible now references this benchmark that measures performance improvements of using the sealed keyword.
  • Typos fixed in rules description and API documentation.
  • Clustering a large set of nodes on the dependency graph could create too large clusters. This has been improved to obtain more readable graph in any situation.
  • A C#10 file-scoped-namespace now have its source file declaration(s) resolved at NDepend analysis time.
  • NDepend now shows an error message box when executed from a WinRar temporary directory like C:\Users\{user}\AppData\Local\Temp\Rar$anything. This is because WinRar might corrupt the temporary installation anytime by deleting some files.
  • A filter is shown on NDepend project's list (both on Start Page and on Ctrl+O dialog) when there is more than 10 projects. /Start-Project-Most-Recent-Project-Filter

ILSpy Plugin

A new ILSpy plugin is now provided to make NDepend and the free and open-source decompiler ILSpy interact both ways.

From NDepend to ILSpy: Just right click any assembly, namespace, class, method or field in NDepend or Visual Studio (with the NDepend extension installed). There are 3 new menus to:

  • Select the code element in ILSpy
  • Decompile the code element with ILSpy (Target languages: C# and IL)
  • Decompile and Compare: the code element is decompiled from both the baseline assembly and the current assembly and both text files obtained are compared

It is possible to decompile large namespaces or even assemblies. This is especially useful to diff two versions of an assembly. If several classes are decompiled, they are aggregated in the text file in a consitent order, which makes the code review of changes possible.

ILSpy Decompile and Compare with NDepend

ILSpy is a fast decompiler but C# decompilation of dozens or hundreds of classes can take a few seconds or minutes thus a progress dialog is shown with an Abort button.

ILSpy to NDepend Show on Dependency Graph

From ILSpy to NDepend it is possible to:

  • Show any code element on the NDepend dependency graph or matrix
  • Analyze with NDepend one or several assemblies selected
ILSpy to NDepend Show on Dependency Graph

Visual Studio solution picker Improvements

The Visual Studio MRU (Most Recently Used) solutions picker dialog now properly resolves MRU solutions from VS 2022, 2019 and 2017.

Solution Picker Dialog Improvement

New Filtering Capability to better Resolve Coverage Files in Complex Scenarios

It is now possible to provide a wildcard filter string to locate precisely coverage files in the specified directory. This way if coverage files are outputted in child directories randomly, like with Coverlet technology, it is possible to retrieve it.

ndepend coverage file dir filter

Fewer False Positives

  • The notmycode query Discard generated Namespaces from JustMyCode now matches namespaces generated by the Blazor infrastructure. This fixes several issues found on such generated code.
  • The rule Types with disposable instance fields must be disposable now checks that disposable classes of matched fields are instantiated within the parent class to avoid some false positives.
  • The types compiled by the Razor infrastructure are now matched by the notmycode query Discard generated Types from JustMyCode to avoid some false positives on those.
  • Usage of ref struct could lead to violate the rule Don't use obsolete types, methods or fields because the compiler tags ref struct with ObsoleteAttribute to avoid usage from older C# versions.
  • In .NET 6, the class Program generated by top-level-statement could violate the rule Class with no descendant should be sealed if possible.
  • When using record in .NET 6 the rule Do not hide base class methods could warn on the generated method <Clone$>() that is currently not marked by the C# compiler as generated by the compiler.
  • The rule Avoid naming types and namespaces with the same identifier could match namespaces generated by the compiler whose name cannot be changed.

Out-of-process Analysis per Default

Analysis can now be executed out of the Visual Studio or VisualNDepend process and this is the default choice.

In-process analysis has very few performance and responsiveness impact. Nevertheless out-of-process is now the default choice to make sure Visual Studio productivity doesn't get affected at all.

Also when the analysis is executed out-of-process it is possible to abort it with the Abort button, shown in the Analysis Error List panel.";

It is still possible to fallback to in-process analysis from the Options > Analysis Settings panel.

Visual Studio 2022 Themes and Icons

The NDepend Visual Studio extension and VisualNDepend are now themed with the Blue, Dark and Light Visual Studio 2022 themes.

NDepend now have Visual Studio 2022 icons. In Dark theme, icon colors are now transformed to increase the contrast with the dark background.

In dark theme, now all right click menus are shown as dark.

Visual Studio 2022 Blue Dark Light Themes

What's new in NDepend v2021.2

NDepend analysis, ruling, reporting, API and PowerTools now run on MacOS and Linux

NDepend runs on Windows, macOS and Linux

The new ./net5.0/NDepend.Console.MultiOS.dll executable is a .NET 5.0 assembly that can be started with the dotnet command. It can be executed on Windows, MacOS and Linux to produce reports. The reports produced on MacOS and Linux are similar to the ones produced on Windows except that they are missing the graph/matrix/treemap diagrams. You can refer to the documentation: Getting Started with NDepend on Linux and macOS

NDepend.API.dll is now a netstandard 2.0 assembly. Thus the NDepend API can be executed within most .NET contexts including: .NET 5.0, 6.0, .NET Core 3.x, .NET Framework 4.7.2 and 4.8. In a non .NET Framework / Windows context, a few UI and Windows related APIs are not supported.

The open-source NDepend PowerTools now runs on MacOS and Linux thanks to the new NDepend.Console.MultiOS.exe .NET 5.0 executable.

NDepend on Windows now require the .NET Framework 4.7.2 or 4.8 installed to run. This is because to run also with .NET 5.0 most non-UI code has been migrated to netstandard 2.0 that works seamlessly with .NET Framework only since version 4.7.2.

Create project with NDepend.Console.exe

NDepend.Console.exe can now be used to create an NDepend project on the fly. The first argument must be /CreateProject or /cp. The second argument must be the project file path to create.

Then at least one or several sources of code to analyze must be precised. A source of code to analyze can be:

  • A path to a Visual Studio solution file
  • A path to a Visual Studio project file
  • A path to a compiled assembly file

See more details in the NDepend.Console.exe documentation.

Register a license or start evaluation with NDepend.Console.exe

NDepend.Console.exe can be used to register a license on a machine, or to start evaluation. Here are console arguments to use (case insensitive):

  • /RegEval : Start the NDepend 14 days evaluation on the current machine.
  • /RegLic XYZ : Register a seat of the license key XYZ on the current machine.
  • /UnregLic : Unregister a seat of the license key already registered on the current machine.
  • /RefreshLic : Refresh the license data already registered on the current machine. This is useful when the license changes upon renewal.

Each of these operations requires internet access to do a roundtrip with the NDepend server. If the current machine doesn't have internet access, a procedure is proposed to complete the operation by accessing manually the NDepend server from a connected machine.

Start NDepend Evaluation on a machine not connected to internet

Improvements

  • The NDepend project can reference some Linux style absolute path like /usr/share. However it is recommended to reference paths as relative to the project file location. This way the project is usable on various OS.
  • Types and methods generated by C# top-level statements are shown as application code despite being flagged as code generated by compiler.
  • New property IEnumerable<IType> IAttributeTarget.AttributeClassesThatTagMe { get; } to easily get all attribute classes that tag an IAssembly, IType, IMethod or IField.
  • When attaching a new NDepend project to a VS solution, or when referencing a VS solution from an NDepend project, if the default project name filters (which is "-test") matches all projects of the VS solution, the filter is reset to avoid the situation where all projects to analyze are filtered-out.
  • When analysing a Visual Studio solution with a filter that filters-out all its projects/assemblies, a new warning explains in plain-english the situation and that the filter needs to be modified.
  • New API method FillIncremental() to compute a ICodeMetric<TCodeElement,TNumeric> object. With the API method FillIterative() (that already existed) only elements computed at iteration N are used to compute elements of iteration N+1. With FillIncremental() all elements computed until iteration N are used to compute elements of iteration N+1.
  • A Technical-Debt breaking point value is a TimeSpan. Such value was formatted in number of days only, like 1000d. Now for values higher than a year the breaking point is formatted this way 2y 270d.
  • Now code query result column can be typed with IAbsoluteDirectoryPath or IAbsoluteFilePath like in the query:
    from a in Application.Assemblies 
    select new { 
      
    a, a.VisualStudioProjectFilePath, 
         
    a.VisualStudioProjectFilePath
          
    .ParentDirectoryPath
    }
  • When assemblies are resolved from a Visual Studio solution, IAssembly.VisualStudioProjectFilePath is now properly assigned to the project file resolved from the solution.
  • Documentation of the rule Avoid namespaces dependency cycles has been improved.
  • The rule Avoid referencing source file out of Visual Studio project directory now checks that the source file path and the project file path are on the same volume before emitting an issue. This avoids false-positive when the same project is used on several OS.
  • It is now possible to drag and drop Visual Studio Solution Explorer types, methods and fields item (those under source file) to the NDepend dependency graph.
  • New Power Tool r) .NET v5.0 and v6.0 installed Public API Changes that works on Windows, Linux and macOS.
  • In the NDepend Project Properties, when browsing for an assembly, a Visual Studio solution or a directory, the default directory shown in the browse dialog is now among the ones referenced by the project. This directory is also updated upon directory selection or directory browsed chosen.
  • The version 2021.2.1 proposes improvements related to NDepend.Console.exe and NDepend.Console.MultiOS.dll.
  • (v2021.2.3) In the Graph Options, the user can optionally define a color that will be used to color the graph background. This possibility is useful for example to obtain a green screen overlay background.
  • (v2021.2.4) When specifiying the project file path to NDepend.Console.exe (analysis or create project modes) it is now possible to provide a path relative to the current directory (obtained internally with System.Environment.CurrentDirectory) or just a file name in the current directory.

Visual Studio 2022 support

Visual Studio 2022 NDepend Extension

The NDepend extension now fully integrates within Visual Studio 2022.

The NDepend extension is still supported for Visual Studio version 2019, 2017, 2015, 2013, 2012 and 2010.

Full .NET 6.0 support

NDepend 2021.2 can analyze .NET 6 code

All .NET 6.0 project's kinds can now be analyzed:

  • ASP.NET Core
  • Windows Desktop
  • Blazor
  • Console
NDepend can analyze all .NET 6.0 projects

Full Support for Target Framework Name

The new property IAssembly.TargetFrameworkName returns the target runtime targeted by an application assembly (like "net5.0", "netstandard2.1", "net461"...).

The new property IAssembly.TargetPlatform returns the target platform targeted by an application assembly (like "AnyCPU", "x64", "x86"...).

For .NET Standard assemblies whose parent directory wasn't named like "netstandardX.Y", in Project Properties the runtime shown was incorrectly shown as "netfx4". Now the proper runtime "netstandardX.Y" is shown in this situation.

NDepend Full Support for Target Framework Name

No more referenced assemblies not found warning

When a third-party or framework assembly referenced by some application assemblies is not found at analysis time, it is now built from the references to it instead of being reported as not found.

Child namespaces, types, methods and fields of such referenced assembly are also resolved from their references found in application code.

The consequence is less warning. Also no matter the flavour of .NET targeted (.NET 6, Unity, Blazor, .NET Standard...) the analysis result is now always complete.

The new property ICodeElement.IsThirdPartyInferredFromRef can be used to list code elements resolved from reference and not from definition at analysis time.

ThirdParty.CodeElements.Where(c => c.IsThirdPartyInferredFromRef)

Improved diff since the baseline

When a class c is sealed in baseline and not anymore (or vice-versa) the extension method c.WasChanged() now returns true.

When a class or an interface x implements in baseline an empty interface and not anymore (or vice-versa) the extension method x.WasChanged() now returns true.

When the list of attributes of a IAssembly, IType, IMethod or IField x is changed since baseline, the extension method x.WasChanged() now returns true.

When the type in a typeof(TypeName) clause in a method m is changed, the extension method m.CodeWasChanged() now returns true.

Fewer False Positives

  • (v2021.2.4) The rule Avoid having different types with same name doesn't warn anymore on usual WPF class name MainWindow.
  • (v2021.2.4)The rule Methods name should begin with an Upper character could incorrectly warn on some methods generated for records like <Clone$>() but not marked as generated by the compiler.

Memory consumption reduced thanks to 40% lighter binaries

20MB of DevExpress Winforms UI libraries have been replaced by a single 434KB library based on the OSS project DockPanelSuite.

As a consequence around 30MB of process memory is saved at VisualNDepend and Visual Studio extension runtime. These saved bytes represent both the discarded DevExpress DLLs weight and their versions JIT compiled to native.

Another benefit is that the downloaded zipped redistributable is now lighter, from 18.7MB to 13.9MB. Without the DevExpress libraries the redistributable should have weight less than 10MB but now it also embeds the Roslyn compiler to compile code queries and rules within a .NET 5.0 context.

What's new in NDepend v2021.1

Importing Code Coverage Data from NCrunch

Since NCrunch version 4.5.0 released in November 2020, NCrunch can export coverage data to OpenCover format XML files.

NDepend can now import coverage data from the OpenCover format XML files generated by NCrunch.

Exporting NCrunch coverage data to OpenCover XML file format

Improved resolving of assemblies from a Visual Studio solution

  • Improved support for MSBuild variables: $(SolutionDir) $(Configuration)
  • New support for MSBuild variables: $(MSBuildThisFileDirectory) $(MSBuildThisFileDirectory) $(MSBuildProjectFile) $(BuildPath) $(TargetFrameworkVersion) $(Platform) $(MSBuildProjectName)
  • Improved support for .props files.

Possibility to resolve assemblies from a Visual Studio solution within a Root Folder

  • If despite these improvements (above) NDepend still doesn't resolve some assemblies from a Visual Studio solution, it is now possible to resolve them through a recursive search under a root folder.
  • Some hints can be proposed to guide the search.
NDepend can analyze all .NET 5.0 projects

Improvements

  • NDepend can now run on Windows machine with Federal Information Processing Standard (FIPS) enabled.
  • Source file declaration is now resolved for records.
  • New NDepend.API flag IType.IsRecord that is set for record classes.
  • New NDepend.API flag IMethod.IsPropertyInit for property initializer method defined with the C# keyword init.
  • .Views.dll ASP.NET Razor assemblies are now analyzed. However all their code elements are considered as notmycode since such assembly is generated by the compiler.

  • New NDepend.Console.exe argument /DontPersistHistoricAnalysisResult to force not persisting analysis result.
  • New NDepend.Console.exe argument /ForceReturnZeroExitCode to force returning exit code zero even when some quality gate are violated.
  • When using the NDepend.Console.exe argument /InDirs with (or without) the argument /KeepProjectInDirs, a new info log is added to explain in plain-english which project's directory are kept (or removed).

  • When opening a file in Windows Explorer, the file is now selected. Like for example in Project Properties > Code to Analyze > double click an assembly row
  • When one or several elements are selected in the graph it is now possible to go back to the menu with application map shown when no element is selected.

New Rule and Fewer False Positives

  • New rule in the Immutability category: Record classes should be immutable
  • The query Types immutable should be tagged with ImmutableAttribute doens't match record anymore since most record classes are de-facto immutable.
  • The rule Avoid namespaces with few types doesn't match anymore namespaces children of common infrastructure namespaces (like Services, Domain ...).
  • The rule Float and Date Parsing must be culture aware doesn't warn anymore on methods in notmocode set.
  • The rule Avoid partitioning the code base through many small library Assemblies doesn't warn on ASP.NET Core generated assemblies whose name is suffixed with .Views.
  • The rule Avoid duplicating a type definition across assemblies doesn't take account of types defined in ASP.NET Core generated assemblies whose name is suffixed with .Views.
  • The rule Types with disposable instance fields must be disposable now operates on JustMyCode types only. This way the rule avoids reporting unfixable issues on classes generated.
  • The rule Do implement methods that throw NotImplementedException now operates only on JustMyCode.
  • The rules Non-static classes should be instantiated or turned to static, Classes that are candidate to be turned into structures, Types that could have a lower visibility, Collection properties should be read only don't warn anymore on classes tagged with System.SerializableAttribute.
  • The rules Methods should be declared static if possible, Methods that could have a lower visibility, Collection properties should be read only don't warn anymore on methods of classes tagged with System.SerializableAttribute.
  • The notmycode query Discard generated Types from JustMyCode now match more Xamarin Resource type.
  • The notmycode query Discard generated Types from JustMyCode now match EF Core migratuon class deriving from Microsoft.EntityFrameworkCore.Migrations.Migration.

Xamarin Applications Support

NDepend can now fully analyze Xamarin applications for Android and iOS.

NDepend Xamarin Support

Unity Applications Support

NDepend can now fully analyze the C# part of a Unity applications.

NDepend Unity Support

UWP Applications Support

NDepend can now fully analyze Universal Windows Platform (UWP) applications.

NDepend UWP Support

Code Querying Improvements

It is now possible to use together:

  • CQLinq expressions containing a code element name like HasAttribute("AttributeName") or DepthOfDeriveFrom("BaseClassName")
  • with all kind of CQLinq expressions like NewerVersion() used to query the delta since the baseline.

As a consequence, powerful queries and rules exploring usage difference since the baseline can be then written:

CQLinq querying improvement

What's new in NDepend v2020.2

Full .NET 5.0 support

  • All .NET 5.0 projects are supported:
    • ASP.NET Core
    • Windows Desktop
    • Blazor
    • Console
NDepend can analyze all .NET 5.0 projects

Other Improvements

  • Resolution of Target Framework Name of projects and assemblies analyzed.

    Resolution of Target Framework Name.
  • Support for the Debugging Information Embedded mode.

    Support for the assembly PDB embedded mode.
  • Performance improvements when resolving third-party NuGet packages referenced. For example on OrchardCore to resolve the 183 NuGet packages referenced it used to take 8 seconds and it now takes around 0.2 seconds.
  • When the dashboard shows a message claiming that the comment metric is not available, this message is now clickable. Clicking it edits a query that matches the assemblies preventing the comment metric to be available on the application.
  • New NDepend.API methods:
    • New property NDepend.DotNet.IAssemblyInfo.TargetFrameworkName that returns a string like "net5.0", "net5.0-windows", "netcoreapp3.1", "netstandard2.0", "net462", "net4x"...
    • New property IType.OutterTypes useful for type nested in a nested type (recursive).

Full C#9 support

  • All source code metrics are now properly computed when parsing C#9 source files.
  • Usage of new C#9 keywords and or now adds up to Source Code Cyclomatic Complexity.
  • The notmycode query Discard generated and designer Methods from JustMyCode now matches methods of C# 9.0 record types. Doing so avoids some false positive issues on those methods.
  • The thresholds for NbVariables is now 25 and for ILNestingDepth is now 10 in rule From now, all methods added should respect basic quality principles because C# pattern matching generates many variables and intricated code.

Full Blazor and Razor Support

  • Both Blazor WebAssembly and Blazor Server projects are now properly analyzed.
  • The notmycode query Discard generated and designer Methods from JustMyCode now matches BuildRenderTree() methods generated by Razor.
  • A class resulting from a .razor file or a type declared within a .razor file has now its IType.SourceDecls filled with the .razor source declaration.
  • .razor source file are now zipped and they are listed from the menu Review Source Diff from the Baseline.
  • The notycode query Discard generated Types from JustMyCode now matches "_Imports" Razor and Blazor types generated by the compiler.
  • The notmycode query Discard generated Types from JustMyCode now matches "TypeInference" Razor and Blazor types generated by the compiler.
  • The rule Nested types should not be visible doesn't warn anymore for types declared inside a Razor page class.

Fewer False Positives

  • The rule Avoid namespaces with few types doesn't match anymore namespaces with few types declared in assemblies with less than 15 types.
  • The rule Non-static classes should be instantiated or turned to static doens't warn if the type is potentially instantiated through a Json serializer like the GetFromJsonAsync() extension method for example.
  • The rule A stateless class or structure might be turned into a static type doesn't warn anymore for types instantiated through a Dependency Injection framework.
  • The rule Namespace name should correspond to file location now deal with minus characters '-' in directories names transformed in underscore characters '_'.
  • The rule A stateless class or structure might be turned into a static type and 'Non-static classes should be instantiated or turned to static' now consider that AutoMapper can create object instance and don't warn when this framework is using a type matched.
  • The rule Non-static classes should be instantiated or turned to static doesn't warn anymore for ASP.NET Core HTML Tag helpers classes.
  • The rule Non-static classes should be instantiated or turned to static doesn't match anymore UWP pages.
  • The rule Avoid defining multiple types in a source file doesn't match anymore types with at least one declaration in a generated file like UWP App and MainPage with some partial declarations in 'App.g.i.cs'
  • The rule Types declared in the same namespace, should have their source files stored in the same directory doesn't match anymore types with at least one declaration in a generated file, like for example UWP App and MainPage with some partial declarations in 'App.g.i.cs'
  • The rule Types with disposable instance fields must be disposable now lists also methods that call a constructor of the type and increases the technical-debt by 4 minutes for each of those methods, to count the refactor effort to call Dispose() on all objects created.
  • The notycode query Discard generated Types from JustMyCode now matches some rare generated nested type

What's new in NDepend v2020.1

Dependency Graph Completely Rebuilt

  • New navigation system:
    • Drag and drop from Visual Studio solution explorer
    • Expand/Collapse parent elements
    • Search elements in graphs by name
    • Call graph / Coupling graph / Inheritance graph ... generated with a single-click
    • Center selected elements
    • Undo / Redo
    • Graph can be saved / loaded as a list of actions (and not as a list of nodes) so it gets refreshed when code changes.
  • New layout options:
    • Group-By Assemblies, Namespaces, Types, Clusters
    • Filters to show or hide: third-party assemblies (like System or ASP.NET Core components), code generated, non-public elements.
    • Box size proportional to element size, Edge width proportional to coupling strength
    • Color conventions instantly identify caller/callee elements
    • Complex graph simplified with Clusters
  • Export to SVG vector format or PNG bitmap format.
  • The graph shown in reports has been improved with the new Cluster feature.

Dependency Graph scales on very large Application

The architecture of large applications can be explored and navigated live.

The short animation below shows a graph made of 15,000+ classes of .NET Core 3 with a zoom on System.String and then System.Dictionary<K,V>

Search in Graph

Search for elements by name on large graphs consisting of hundreds or thousands of elements in real-time.

Keep or remove matched elements.

Regex supported.

The short animation below searches all namespaces whose names contain the string customer, selects them and then expands them to show all their children classes.

Obtain a Call Graph with a single-click

Click a code element to select it and then click one of the links: callers and callees, callers or callees

Use a combo-box to select the call depth. A call depth value N greater than one means that elements calling elements ... (N times) ...calling the element(s) selected are shown.

A call graph can be obtained from several elements selected.

In the background a code query is generated to match elements shown within the call graph.

Obtain a Coupling Graph with a single-click

Click an edge between 2 elements then click one of the links coupling graph.

A graph made of children elements involved in the coupling is shown, for example all classes involved in the dependency between two projects.

In the background a code query is generated to match elements shown within the coupling graph.

Complex graph simplified with Clusters

Clusters are automatically introduced to simplify complex graphs into readable graphs.

This feature can be disabled from the Group-By options

If referenced components like ASP.NET Core components are shown on a graph, they get their own clusters.

Graph of Changes since Baseline

If a baseline is available the changes map link opens the search panel to search classes, methods and fields added or modified since the baseline and exports these elements to the graph.

Others Improvements (2020.1.1)

  • When trend metrics are logged, analysis execution time is roughly divided by 2 within the context of Visual Studio extension or VisualNDepend.exe. The reason for this improvement is that trend metrics are now logged asynchronously out-of-process. When trend metrics are logged, the trend charts in the UI Dashboard gets refreshed with the last values logged.
  • When resolving assemblies from a Visual Studio solution, implicit .props files (Directory.Build.props) and explicit .props files import are now supported.
  • The heuristic that resolves an assembly from a Visual Studio project file now takes account of the tags <RuntimeIdentifier> and <RuntimeIdentifiers> if they are defined.
  • When some assemblies cannot be resolved from a Visual Studio solution or project, a new tooltip panel appears in the Project Properties > Code to Analyze panel and explains how to reference some assemblies directly from the NDepend project.
  • Better support for .NET Core 3.1: in NDepend > Project Properties > Code to Analyze > Directories that contains assemblies > Profile .NET Core 3.1
  • When an NDepend project references a Visual Studio solution but doesn't reference any directory an error message was shown at analysis time even though application assemblies could be resolved. Now instead of an error a warning log is emitted.
  • New Rule: Controller class name should be suffixed with 'Controller'

Graph of Callers and Callees generated from the Visual Studio Code Editor

The Show on Dependency Graph menu is available by right-clicking any source element in code editor.

The same menu is also available when right-clicking a File or a Directory in the Visual Studio Solution Explorer.

Also a sub-menu NDepend > Append to Dependency Graph is available.

NDepend Append Code Element to Graph

Color Conventions to Highlight Dependents

Dependents of the selected elements and related edges, are instantly highlighted. This also works for the hovered element if no selection.

  • Green for direct callers, dark-green for callers of callers (recursive).
  • Blue for direct callees, dark-blue for callees of callees (recursive).
  • Red for mutual dependents, dark-red for non-direct mutual dependents (recursive).

A help panel is shown by default to explain the color convention and can then be discarded

Export to SVG vector format or PNG bitmap format

Click the images below to open some SVG vector graph in your browser.

NDepend Graph SVG

NDepend Graph SVG of ASP.NET Core Components

NDepend Graph SVG of Graph Implementation

Graph of Entangled Code

The cycles link edits a code query that matches cycles between namespaces.

In the GIF below, a cycle of 30 namespaces is exported to the graph. These 30 namespaces all depend on each other and together they form a super-component.

Azure DevOps Extension Improvements

  • Configuration tab added to customize the dashboard.
  • Autocomplete for added build definitions. This is useful in case of many build definitions.
  • Loading time optimized for efficient handling of large project.

Fewer False Positives (2020.1.1)

  • The rule API Breaking Changes: Methods has been modified so a method declared as public from a type that is not publicly visible anymore is not reported.
  • The rules Potentially Dead Type, Potentially Dead Methods and Methods that could have a lower visibility don't warn anymore on ASP.NET MVC controllers and methods invoked by the infrastructure. The [NonAction] attribute is taken account to determine if a method is invoked or not by the infrastructure.
  • The rule Mark assemblies with assembly version doesn't warn anymore if it detects that the assembly version is defined through a way different than an explicit AssemblyVersionAttribute.

What's new in NDepend v2019.3

Source File Store Out Of The Box

  • Parsed source files are now zipped at analysis time. This behavior is out of the box and transparent for the user, no configuration needed.
  • This enables comparison of source file modifications against baseline version.
  • When opening a source file declaration, if the source file is not found locally it is fetched from the analysis result zip store.

Source Diff Against Baseline from Everywhere

  • New menu Diff since Baseline available everywhere:
    • In the Visual Studio Code Editor window right-click menus.
    • In the Visual Studio Solution Explorer window, any item right-click menus : Solution, Project, Project Reference, Folder, Source File, Code Element in Source File.
    • In the NDepend main menu.
    • In the NDepend code element right-click menu.
  • This menu is enabled only when there are changes since the baseline.
  • This menu now unzips the baseline source file to compare it with the current version.
  • When more than one source file declarations are available, this menu action edits a code query to show all concerned source files and the user can choose which one(s) to diff.
  • When several source files are shown, they are grouped per directories. The result can be easily browsed because only directories with modifications are expanded.
  • In query result, when code elements are grouped by source files and directories, the font used to write the files and directories names can now be bold, underlined or striked if the directory or source file has been added, contains changes or has been removed since the baseline.
  • When right clicking a source file in query result, there is a new diff menu. This menu is enabled and set as double-click action if the file has been modified since baseline.

Improved Experience with Coverage Data

  • The dialog NDepend Project Coverage Settings has been improved to highlight that importing coverage files from a directory is the recommended way to import coverage data.
  • The menu Explore Code Coverage opens the Search Methods by Coverage panel and now methods are grouped per namespaces, assemblies and types and the result is shown as expanded until the type level.
  • The menu Review How Diff are Covered by Tests opens the Search Methods by Coverage of Diff panel to show methods grouped per namespaces, assemblies and types. The result is shown as expanded until the type level.
  • When clicking the Lines of code uncovered in the Dashboard a new code query is edited that shows Code Excluded from Coverage Statistics
  • Improved description of the default trend metric # Lines of Code Uncoverable.

New APIs

  • New API methods ICompareContext.WasAdded(...) WasChanged(...) WasRemoved(...) on IAbsoluteFilePath and IAbsoluteDirectoryPath to track changes on source files and on directories that contain source files.
  • New API method ExtensionMethodsTooling.TryDiffSource(this ICodeElement codeElement, ICompareContext compareContext, out string failureReason):bool to diff the older and newer version of the source of a code element. The older source file version is fetched from the source files zip store, created at analysis time.
  • New API properties ICodeBase.AnalysisResultFilePath and ICodeBase.SourceFiles.
  • New API method ExtensionMethodsHelpers.TryGetSourceFileContent(this ICodeBase, IAbsoluteFilePath, out string content).

Code Diffs are now Easier to Browse

  • When editing a query or a rule that relies on diff, double-clicking a code element changed since the baseline has for effect to compare its older and newer source. This makes diff review session easier.
  • In Visual Studio 2019,2017,2015,2013 and 2012 when diffing a source file, the diff panel is opened in the current Visual Studio instance no matter if the Source File Compare Tool option is set to a different Visual Studio version.
  • New menu Visual Studio > NDepend > Code Diff since Baseline now opens the Search Code Elements by Change panel. The result can be easily browsed since code elements are now expanded until the type level. Also double clicking any changed element now opens sources diff.

    Diff Since Baseline for a Visual Studio Solution Explorer Project

Relative Paths Preferred

  • By default a new NDepend project now references files and directories paths as relative to the NDepend project file location whenever possible.
  • When changing paths or adding paths to an NDepend project, relative path mode is chosen if the output directory path is referenced as relative.

    A new NDepend project now references all paths as paths relative to the NDepend project file location

Other Improvements

  • Right click menus on a code element menu have been simplified.
  • Executing rules and queries is 10% faster within the Visual Studio extension and VisualNDepend.exe.
  • The rule Methods name should begin with an Upper character no longer matches explicit interface implementation methods that are potential false positives because of their special naming.
  • These rules now take account of JetBrains.Annotations.UsedImplicitlyAttribute to avoid reporting false positives on code elements implicitly used: Potentially Dead Types, Potentially Dead Methods, Potentially Dead Fields, Methods that could have a lower visibility, Types that could have a lower visibility, Fields that could have a lower visibility
  • The default queries JustMyCode code elements and NotMyCode code elements now show the lines of code not just for methods but for all code elements.
  • Default trend metric queries # Types, # Assemblies, # Namespaces now show the column number of lines of code in addition to issues and debt columns.
  • The menu Code Metrics opens the Search Types by Size panel and now types are grouped per namespaces and assemblies and the result is shown as expanded.
  • When clicking various numbers on the Dashboard (# Lines of Code, #Lines of Code diff, # Types...) code elements matched in the query result are now properly grouped and expanded for an improved browsability.

What's new in NDepend v2019.2

Support for Visual Studio 2019

  • NDepend 2019.2 supports Visual Studio 2019.
    (Visual Studio 2019.1 and upper versions are supported since NDepend v2019.2.3.).
  • NDepend 2019.2 also supports Visual Studio 2017, 2015, 2013, 2012 and 2010.
  • If several Visual Studio 2019 SKUs are installed (Enterprise, Professional, Community) it is possible to install the NDepend Visual Studio extension in one or several SKUs.

    NDepend Visual Studio 2019 Integration
  • A new Move the NDepend Menu to Top Level menu informs of the possibility to move back the NDepend main menu to top level in Visual Studio 2019 with the RestoreMenu extension.

    Move The NDepend Menu To Top Level
  • (v2019.2.5) The NDepend UI is now fully compliant with the new option Optimize rendering for screens with different pixel densities of VS2019 running on .NET 4.8.

    NDepend Compliant with Optimize rendering for screens with different pixel densities

Simplified menu for the Visual Studio extension

(v2019.2.1)
  • A new beginner menu shown per default offers a direct access to each feature.
  • The query, rule, quality gate and trend metric generated by clicking under the New menu now contains the relevant urls to the online documentation.
  • The user can switch back and forth between the beginner menu and the standard menu

    NDepend Beginner Menu

Support for .NET Core 3.0

Applications developed with .NET Core 3.0 can now be analyzed in addition to applications developed with .NET Core 2.2, 2.1, 2.0, 1.1 and 1.0.

ndepend dotnet core 3 support

New Tutorial Videos

Improvements

    (v2019.2.5)
  • Support for the new SuppressMessageAttribute scope namespaceanddescendants.
  • Case insensitive support for the SuppressMessageAttribute scopes. For example Module or module are both recognized, the same way namespaceanddescendants and NamespaceAndDescendants are both recognized.
  • Visual Studio 2019 is now included in the default list of diff tools (NDepend < Options < Source Files Compare Tool)
  • New Sonar Plugin option /d:sonar.cs.ndepend.skip=true to avoid triggering NDepend analysis.
  • (v2019.2.4)
  • Improved support to analyze assemblies of applications compiled with x86, x64 and ARM.
  • TeamCity extension now supports issues suppression through SuppressMessageAttribute and also supports build-failure upon Quality Gate failure.

Report Improvements

    (v2019.2.6)
  • Improved navigation in the left grey menu of the report: empty groups have been pruned to avoid unnecessary clicks and formatting has been improved.
  • In the report dashboard, Rules and Quality Gates titles are now clickable to go directly to Rules Summary and Quality Gates Summary sections.
  • In the report, green/yellow/red counters for counting rules ok/violated and critical rules violated might not be in sync with green/yellow/red rule numbers on the dashboard because they were counting also the number of syntax errors in rules/queries.
  • The code queries group Quality Gates is not anymore visible per default in the report since there is already a dedicated Quality Gates section menu.

Fewer False Positives

    (v2019.2.5)
  • The rule ND1208:Methods should be declared static if possible doesn't warn anymore on methods of JSON or XML serialized classes.
  • The rule ND1204:Overrides of Method() should call base.Method() doesn't warn anymore for override of methods of the Object class.
  • The rules ND1207:Non-static classes should be instantiated or turned to static, ND1304:Classes that are candidate to be turned into structures, ND1801:Types that could have a lower visibility, ND1800:Methods that could have a lower visibility, ND2300:Collection properties should be read only don't warn anymore on JSON serialized classes.
  • The rules ND1207:Non-static classes should be instantiated or turned to static doesn't warn anymore for types instantiated through one of these dependency injection frameworks: Microsoft.Extensions.DependencyInjection, Autofac, Microsoft.Practices.Unity, Ninject, StructureMap, SimpleInjector, Castle.Windsor, LightInject, Spring.NET, Lamar
  • The rule ND1305:Avoid namespaces with few types doesn't match anymore namespaces named "Domain", "Enums", "Abstractions", "BaseClasses", "Settings", "Helpers", "Validators" or "Entities".
  • The query ND3001:Discard generated Namespaces from JustMyCode now match namespaces generated by the Refit infrastructure (namespace named RefitInternalGenerated) to avoid false positives on generated types (typically the PreserveAttribute class).
  • (v2019.2.4)
  • The rule ND2015 Don't call your method Dispose could return false positives when the method System.IDisposable.Dispose() was not resolved as third-party.
  • The rule ND2203 Mark attributes with AttributeUsageAttribute doesn't match anymore abstract attribute classes (since AttributeUsageAttribute can be deferred to derived classes), nor attribute classes that have a base class tagged with AttributeUsageAttribute (since in this case attribute usage is inherited).
  • The rule ND2211 Don't Implement ICloneable doesn't warn anymore for classes that derive from a class that implements ICloneable. In this case the issue must be fixed in the base class, or is maybe not fixable if the base class is declared in a third-party assembly.
  • The default code query Discard generated Fields from JustMyCode now matches generated fields named _tagHelperStringValueBuffer this way such fields won't be matched anymore by any rule.
  • The default code query Discard generated Namespaces from JustMyCode now matches namespaces Microsoft.CodeAnalysis and System.Runtime.CompilerServices. Sometime Roslyn can generate types in these namespaces.

What's new in NDepend v2019.1

NDepend project can now reference Visual Studio solution(s)

  • An NDepend project file can reference one or several Visual Studio solution or project file(s).
    It is still possible to reference only assemblies, or both assemblies and Visual Studio solutions.
  • The result is less maintenance: the assemblies-set analyzed remains automatically synchronized with the Visual Studio projects-set when some Visual Studio projects are added or removed from the Visual Studio solution analyzed.

    A Visual Studio solution referenced by an NDepend project.
  • One or several textual filters on Visual Studio solution's assemblies names can be defined to refine the set of assemblies to analyze. Per default the filter -test is proposed to filter out test assemblies.
  • The Attach a new NDepend project to a Visual Studio solution dialog now proposes to reference the Visual Studio solution per default.

    The 'Attach a new NDepend project to a Visual Studio solution' dialog, now proposes to reference the Visual Studio solution per default.

Other Improvements

  • When analyzing some application assemblies, third-party assemblies set is not gathered anymore from the NDepend project but is inferred from analyzed application assemblies. As a consequence, when the third-party referenced assembly set is changing, changes are automatically taken account.
  • When saving a snapshot picture of the Graph, Matrix or Metric View, the file name gets incremented to avoid overriding previous snapshots.
  • In Visual Studio, when opening an NDepend project or a solution with an NDepend project, and the NDepend project has no analysis result yet available, the NDepend Project Properties window is shown.
  • It is now possible to use the type System.StringComparer in a CQLinq query. This is useful to define the proper string comparer when using a dictionary, a lookup or a hashtable indexed by string.
  • When facing analysis warnings like 'Assembly {AsmReferenced} is referenced by {Asm} but is not found.', an explanation is added to the first warning 'To resolve such warning you can append the assembly directory in NDepend Project Properties > Code to Analyze > Directories that contains .NET assemblies to analyze'.
  • New option in Analysis Settings to show (or not) the Analysis Error List panel when user runs analysis, the default behavior until now is to show this panel.
  • On the Start Page, a new section One-Off Analysis has been added to underline the fact that when the user demands for a quick analysis, an overridable temporary project is created behind the scene.
  • Code coverage technologies supported are now listed on the Start Page.
  • Properties of IType MethodsAndContructors and InstanceMethodsAndContructors are now obsolete because of the typo and 2 properties have been added MethodsAndConstructors and InstanceMethodsAndConstructors.

Support for OpenCover xml coverage files

Support for Visual Studio coverage binary file

  • NDepend was able to import coverage data from one or several Visual Studio coverage XML file (.coveragexml extension).
  • It is now also able to import coverage data from Visual Studio coverage binary file (.coverage extension).
  • More info in the documentation here.

New Security Rules

New rules related to security:

  • Don't use CoSetProxyBlanket and CoInitializeSecurity
  • Don't use System.Random for security purposes
  • Don't use DES/3DES weak cipher algorithms
  • Don't disable certificate validation
  • Review publicly visible event handlers
  • Pointers should not be publicly visible
  • Seal methods that satisfy non-public interfaces
  • Review Commands Vulnerable to SQL Injection
  • Review Data Adapters Vulnerable to SQL Injection

Others new rules:

  • Don't Implement ICloneable    in category .NET Framework Usage > System
  • Avoid fields with same name in class hierarchy    in category Naming Conventions
  • Avoid various capitalizations for method name    in category Naming Conventions
  • Avoid mutually-dependent types    in category Architecture

Improved exclusion of code elements from coverage statistics with an attribute

  • Default support for the attribute System.Diagnostics.CodeAnalysis.ExcludeFromCodeCoverageAttribute for all coverage technologies.
  • Default support for the attributes System.Diagnostics.DebuggerNonUserCodeAttribute and System.Diagnostics.DebuggerHiddenAttribute for the Visual Studio coverage technology only.
  • New flag in the NDepend code model ICodeContainer.ExcludedFromCoverageStatistics (applicable for IMethod, IType, INamespace and IAssembly).
  • The trend metric # Lines of Code Uncoverable now relies on ICodeContainer.ExcludedFromCoverageStatistics and so the code queries generated when clicking the Dashboard > Coverage > Lines of code uncoverable.
  • Better validation of the custom attribute provided in Project Properties > Analysis > Coverage > Settings.

20 bugs fixed

  • A crash could happen in NDepend Visual Studio extension or VisualNDepend if some debt or annual-interest values were overflow. Now the "overflow" string is shown instead of these values.
  • When having a lot of application and third-party assemblies to analyze, when refreshing the Project Properties > Code to Analyze panel upon assemblies resolving, grid views were slowing down with flickering.
  • The version of a Visual Studio solution might not be determined. This could result in resolving failure of assemblies compiled from a solution file.
  • Other bugs fixed, details here

What's new in NDepend v2018.2

Issue suppression with SuppressMessage attribute

  • The attribute SuppressMessageAttribute can now be used to suppress NDepend issues. NDepend issue suppression is applied in any context: i.e. in the Visual Studio extension, in reports and Azure DevOps extension.
  • It is now possible to assign a rule id to an NDepend rule. All NDepend default rules now have a rule id. This rule id can be used by the SuppressMessage attribute.
    // <Name>Class with no descendant should be sealed if possible</Name>
    
    // <Id>ND1203:ClassWithNoDescendantShouldBeSealedIfPossible</Id>
  • New Suppress Issue menu and new SuppressMessage wizard dialog.

    NDepend Suppress Issue Menu

    Use SuppressMessageAttribute in source code to suppress this issue

  • All SuppressMessageAttribute variations are supported and the attribute syntax is enhanced. This includes the support for the usage of Scope, Target, suppression by rule id or by category, suppression in a dedicated file GlobalSuppression.cs. More details below and the full documentation is available here.
  • using System.Diagnostics.CodeAnalysis;

    // Suppress issues in the category ".NET Framework Usage"
    // and all sub categories, in this assembly's
    // namespace types methods and fields

    [assembly: SuppressMessage("NDepend..NETFrameworkUsage", "",
               Scope = "deep", Justification="...")]
    // Same with more verbose Scope
    [assembly: SuppressMessage("NDepend..NETFrameworkUsage", "",
               Scope = "module namespace type method field")]

    // Suppress all NDepend issues in this assembly
    [assembly: SuppressMessage("NDepend", "")]

    // Suppress issues on the method MyClass.Method() by rule ID
    // This can be copied in a GlobalSuppression.cs file
    // thanks to the usage of Target

    [assembly: SuppressMessage("NDepend",
               "ND2010:AvoidMethodsWithNameTooLong",
               Target = "MyNamespace.MyClass.Method()")]

    // Suppress issues for all types
    // declared in the namespace MyNamespace.

    [assembly: SuppressMessage("NDepend",
               "ND1306:NestedTypesShouldNotBeVisible",
               Target = "MyNamespace", Scope = "type")]

    namespace MyNamespace {

       // Suppress issues on MyClass by rule ID
       [SuppressMessage("NDepend",
         "ND1203:ClassWithNoDescendantShouldBeSealedIfPossible")]

       // Suppress issues on all methods of MyClass by rule ID
       [SuppressMessage("NDepend",
         "ND1701:PotentiallyDeadMethods", Scope = "method")]

       // Suppress all NDepend issues on MyClass and its child members
       [SuppressMessage("NDepend", "", Scope = "deep")]
       class MyClass {
          void Method() { }
       }
    }
  • Suppressed issues can be listed with a single-click from the dashboard, and can also be queried:

    Listing NDepend suppressed issues from the dashboard
  • When editing a rule, a suppressed issues list can also be displayed in addition to the issues list.

    NDepend Suppress Issues of a Rule

Support for .NET Core 2.2 Preview

Applications developed with .NET Core 2.2 Preview can now be analyzed in addition to applications developed with .NET Core 2.1, 2.0, 1.1 and 1.0.

Deferred Visual Studio 2017 Extension Loading

  • The NDepend Visual Studio extension is now an AsyncPackage loaded on user request after startup.

    As a consequence, Visual Studio startup performance is no longer impacted by NDepend which now complies with the May 2018 - Visual Studio 2017 extension load policy.

    Visual Studio 2017 NDepend Async Package
  • The NDepend extension is loaded after a few seconds of VS2017 inactivity or on user request.

    To have NDepend VS2017 extension load at startup (i.e. the prior default behavior), just leave one or more NDepend windows open when closing VS2017.

    The NDepend window left open will then force VS2017 to load the NDepend extension at startup.

  • NDepend extension startup performance cost is negligible but now startup is even faster because more processing is delegated to the pool thread.

Fewer False Positives

  • The rule 'Avoid methods with too many parameters' will no longer match situations that are the consequence of lower-level problems, such as:
    • a method that overrides a third-party method with many parameters,
    • a constructor that calls a base constructor with many parameters,
    • a P/invoke method tagged with DllImport
  • The rule 'Avoid methods with too many overloads' will no longer match overloads that result from lower-level overloads such as when overriding a third-party method with many overloads or a constructor that call a base constructor.
  • mshtml COM/Import namespace and all its types and members will now be classified as - ‘not-my-code’ and issues will no longer be reported on this code.
  • Microsoft.Office.* COM/Import namespace(s) and all their types and members will now be classified as – ‘not-my-code’ and issues will no longer be reported on this code. This is especially true for issues related to the rule "Interface name should begin with a 'I'" which tends to be broken by many interfaces in these namespaces.
  • Types tagged with System.Runtime.InteropServices.GuidAttribute, that represents a COM type defined elsewhere are now considered as – ‘not-my-code’ and issues will no longer be reported on this code.
  • The notmycode query "Discard generated Types from JustMyCode" will now match types generated by the compiler that are nested and whose name starts with "<>c".
  • The rule 'Avoid the Singleton pattern' will now match only singleton types with mutable instance fields because Singleton pitfalls result from anarchical access and modification of instance data.
  • The rule 'Potentially Dead Methods' will now ignore methods tagged with OnDeserializingAttribute and OnSerializedAttribute.
  • The rule 'Avoid having different types with same name' will no longer match web types suffixed with "Service", "Model", "Controller", "Page" or "Pages".
  • The notmycode query 'Discard generated Types from JustMyCode' will now match the Entity Framework ModelSnapshot generated class. This means that this generated class will no longer violate quite so many rules anymore.
  • The VB.NET generated namespaces My and My.Resources will no longer be reported by the rules 'Avoid namespaces dependency cycles' and 'Avoid namespaces mutually dependent'

Other Improvements

  • New README.txt file with the NDepend zipped files that explains the purpose of each file.
  • New default keyboard shortcut Alt+A for "Search Any Code Element by Name", will be applicable in both Visual Studio and VisualNDepend.
  • In Visual Studio, when no NDepend project is opened, several empty NDepend panels might still be visible. Each of these empty panels now have a 'Close all NDepend panels' button.
  • The PowerTool 'Technical Debt Evolution Since Baseline' now displays the DebtRating evolution.
  • PowerTools solution is now based on Visual Studio 2013 (compatible with VS2015 and VS2017) and the directory .\NDepend.PowerTools.SourceCode\obj is no longer included.
  • NDepend.Helpers.IReadOnlyList<> and NDepend.Helpers.IReadOnlyCollection<> can now type the result of a code query.
  • When opening the source file declaration of a field, an abstract method or a default constructor, a message is generated to explain that such declaration is not yet available, and the parent type declaration will be opened.
  • When browsing to add an assembly to a project that currently doesn't have any application assembly, the default browse directory is now the project file parent directory. It was previously a .NET Framework assemblies directory.
  • In Visual Studio, when selecting a project on the NDepend start page from the Most Recently Used list, the project is now shown as the first one after selection.
  • New APIs to handle suppressed issues.

More than 40 bugs fixed

  • When inferring the assemblies to analyze from a .NET Core Visual Studio solution or a Visual Studio project, if an assembly name was different from its Visual Studio project file name, the assembly was (previously) not resolved.
  • When inferring the assemblies to analyze from a .NET Core Visual Studio solution or a Visual Studio project, if the output path was not the standard one, the assembly was (previously) not resolved.
  • With Visual Studio 2017 15.6, 15.7 and 15.8 when starting Visual Studio by double-clicking a solution file, if an NDepend project was attached to the solution it would (previously) not load upon Visual Studio startup.
  • In Visual Studio when loading an analysis result, NDepend panels are now frozen (temporarily). This avoids some uncertain behavior and makes it clear the panel is not usable for a short time (typically 1 or 2 seconds).
  • Other bugs fixed, details here

What's new in NDepend v2018.1

Performance improvements for Visual Studio 2017 v15.6 support

  • The NDepend Visual Studio extension performances have been improved to avoid that Visual Studio 2017 v15.6 flags the NDepend extension as slow.

New support for DDD ubiquitous language check (Domain Driven Design)

  • The language used in identifiers of classes, methods and fields of the core domain, should be based on the Domain Model. This constraint is known as ubiquitous language in Domain Driven Design (DDD) and it reflects the need to be rigorous with naming, since software doesn't cope well with ambiguity.
  • A new default rule DDD ubiquitous language check is proposed in the group Naming convention. This rule is disabled per default because its source code needs to be customized to work, both with the core domain namespace name (that contains classes and types to be checked), and with the list of domain language terms.
  • This rule implementation relies on the new NDepend API extension method ExtensionMethodsString.GetWords(this string identifier) method that extracts terms from classes, methods and fields identifiers in a smart way.
  • More about this rule can be found in this blog post.

A New Rule and Fewer False Positives

  • New default rule Properties and fields that represent a collection of items should be named Items. in the group Naming convention.
  • The rule Don't call your method Dispose could warn when overriding the Dispose() method of an interface that is not IDisposable, like IHttpModule.Dispose().
  • The rule Avoid methods with name too long doesn't match anymore test methods because it is considered as a good practice to name unit tests in such a way with a meaningful name.
  • The rule Types that could be declared as private, nested in a parent type doesn't match anymore types with extension methods that cannot be nested. Also it doesn't advise anymore to nest a base class or a base interface into its unique child class.
  • The rule Classes that are candidate to be turned into structures now returns mostly true positive. The rule now requires that instance fields of the class must be typed with value-type, requires the class to be immutable and requires the class to have no parameterless constructor.
  • The rule Avoid empty interfaces doesn't match anymore empty interfaces that implement at least one other interface. Such interface can be considered as not empty, since implementing it means that sub-interfaces members must be implemented.
  • The rule Overrides of Method() should call base.Method() doesn't match any more properties getters and setters that are not supposed to have enough logic to satisfy this rule constraint.
  • The rule Methods should be declared static if possible and the 3 queries Test Methods; Methods directly called by test Methods and Methods directly and indirectly called by test Methods now also support the FactAttribute to define a test method.
  • The rule Instances size shouldn't be too big has been improved to avoid matching classes that derive from some DevExpress components and that derives from classes in System.Component and System.Xml.
  • Annual interests of issues of the rule Instances size shouldn't be too big is now 10x times higher for structure than for classes, because of the performance penalty to deal with large structure values at runtime.

Other Improvements

  • New API method ExtensionMethodsString.GetWord(this string identifier) to extract words from code element identifiers (ICodeElement.SimpleName)
  • New API methods ExtensionMethodsString.Aggregate(this IEnumerable<string> seq, string separator), FirstCharToUpper(this string), StartsWithAny(this string, params string[]), EndsWithAny(this string, params string[]) to ease string manipulation.
  • All www.ndepend.com urls are now referenced as HTTPS.
  • 25 bugs fixed, details here

v2018.1.1 bug fixes

  • Running NDepend with the new .NET Fx v4.7.2 provoques many compilation errors in code queries because this new version of the framework introduces an extension method ToHashSet() with the same signature as the NDepend.API extension ToHashSet() method. NDepend v2018.1.1 introduces the extension method ToHashSetEx(). To easily solve this issue just replace "ToHashSet" with "ToHashSetEx" in all your .ndrules and .ndproj files that contain your code queries and rules.
  • Default code queries and rules and queries generated, now rely on ToHashSetEx() and not on ToHashSet().
  • Special compilation error description with special how-to-fix explanation for the ToHashSet() method problem described above.
  • A ThreadAbortException could rarely be thrown while editing a code query.
  • On an overly complex code query, asking for completion list with typing the dot key could freeze the UI.

What's new in NDepend v2017.3

Support for .NET Core 2.0, 1.1 and 1.0
.NET Standard and ASP.NET Core

  • Following a preview period, .NET Core 2.0 went live with the release of Visual Studio 2017 15.3.
  • With NDepend v2017.3, all your favorite NDepend features now work fine with any .NET Core, ASP.NET Core and .NET Standard Visual Studio project.
  • More than 30 default code rules have been improved to avoid reporting false positive on .NET Core code peculiarities.
  • .NET Core code referenced is properly resolved and a new .NET Core profile is available.
  • More explanations in this blog post Static analysis of .NET Core 2.0 applications

    NDepend support for .NET Core 2.0 and ASP.NET Core

UI Responsiveness

  • UI responsiveness in Visual Studio has been improved when running an NDepend analysis or loading an analysis result.

Many improvements and bug fix

Support for NuGet

  • If Visual Studio projects analyzed by NDepend are referencing some NuGet packages, thanks to a new heuristic NDepend v2017.3 is able to resolve referenced assemblies in these packages.

Fewer False Positive

  • NDepend v2017.3 proposes more than 50 improvements on the default rule-set to avoid matching false positive in various situations.
  • Many issues that were reported on the ASP.NET, ASP.NET Core and WPF infrastructure code are now filtered.

Guide Tooltip for Beginners

  • Guide tooltips now explain the basics of most NDepend UI panels including the Dashboard, the Query Edition panel, the Search panel, the Graph, the Dependency Matrix and the Metric view.

    NDepend Guide Tooltip

Support for Visual Studio 2017

  • NDepend 2017 supports Visual Studio 2017.
  • NDepend 2017 also supports Visual Studio 2015, 2013, 2012 and 2010.
  • If several Visual Studio 2017 SKUs are installed (Enterprise, Professional, Community) it is possible to install the NDepend Visual Studio extension in one or several SKUs.

    NDepend Visual Studio 2017 Integration

.NET Core support

  • NDepend can now analyze any .NET Core assembly and its associated PDB and source files.
  • The new .NET Core Portable PDB file format is now also supported.
  • (v2017.1.1) Resolve VS2015 and VS2017 .NET Core assemblies from their Visual Studio project files thanks to an heuristic that resolves output directories like ".\bin\debug\netstandard1.6" and @".\bin\debug\netcoreapp1.0".
  • Since project.json was discarded with Visual Studio 2017, we don't plan to support it. However the user can still use the Analyze assemblies in folder form to locate assemblies in a folder with the convenient search recursive child folders and the filter assemblies by name options.

New licensing and release scheme

  • NDepend licensing is moving to a yearly subscription model.
  • We now plan 3 to 4 important releases per year instead of one major release every 18 months. This will provide more value, more often to users.
  • Users will be eligible to a 40% discount for each renewed and continuous yearly subscription.
  • Version 6 licenses purchased in 2016 will work as-is with new NDepend versions until their anniversary date in 2017.

    With a version 6 license you have perpetual access to NDepend version 6 but without support if you decide not to subscribe to the annual licensing.

    All version 6 licenses are entitled to a 40% upgrade discount.

  • Version 5, 4 ,3 and 2 licenses are also eligible for an upgrade discount.

Dashboard Improvements

  • Dashboards have been improved in the NDepend UI in Visual Studio, in the generated reports section and in the Azure DevOps web portal.
  • It now contains technical debt estimations, quality gates, rules and issues data.
  • For each data, a visual indicator shows the progression since baseline. Red and green colored values are used to pinpoint progress or regression.
  • Clicking any value generates a query that drills down through corresponding data, which can be a list of code elements, debt estimations, quality gates, rules or issues.

    New NDepend Dashboard

Azure DevOps and TFS Advanced Extension

    The extension can be downloaded and installed from its Visual Studio Marketplace page.

    Send us an email at devops@ndepend.com for product and sales questions.

  • The NDepend Azure DevOps extension consists of a build task that analyses code and code coverage data yielded by the build process. The NDepend Azure DevOps/TFS hub presents the results which embed the NDepend dashboard and makes data actionable by drilling down into any item through a single click.

    Azure DevOps NDepend extension: Dashboard
  • The hub's Dashboard shows a recap of the most relevant data including technical debt estimations, code size, Quality Gates status, rules and issues numbers. A TFS build can be used as a baseline. All dashboard data is then diff-ed since the baseline. Each Dashboard item is clickable to view more.

    Azure DevOps NDepend extension: Dashboard
  • A Quality Gate is a check on a code quality fact that must be enforced before releasing and eventually, before committing to source control. A Quality Gate can be seen as a PASS/FAIL criterion for software quality.

    A dozen of default Quality Gates are proposed by NDepend related to measures like technical debt amount, code coverage or amount of issues with particular severity. For example a Quality gate can be written to enforce a certain amount of code coverage by tests ratio on *code added and refactored since the baseline*. A detailed summary of Quality Gates status is available.

    Azure DevOps NDepend extension: Quality Gates details
  • More than 150 default code rules are proposed to check against best practices. Support for Code Query over LINQ (CQLinq) to easily write custom rules and query code. CQLinq is used both to write the rule code, and also to write smart C# formulas that estimate the **Technical-Debt for each issue** (i.e the cost-to-fix an issue).

    Rules details can be explored. Clicking a rule violation redirects the user to the Code Search extension, displaying the source code of the culprit code element.

    Azure DevOps NDepend extension: Rules details
  • Technical debt can be drilled down till the issue level. Clicking an issue results in editing it in the Rules panel. The datagrid is interactive: issues can be grouped, ordered and filtered by rule names, by code elements, by severity or by their status since the baseline (new / exist / fixed).

    Issues can be also sorted by estimated Technical-Debt metrics, including issues fix prioritization. Typically severe issues that cost little to be fixed should be fixed first and are prioritized.

    Azure DevOps NDepend extension: Technical Debt and Issues details
  • The Azure DevOps extension logs Trend Metrics for each build, and Trend charts are shown. More than 70 predefined Trend Metrics are proposed and CQLinq lets write custom ones.

    Azure DevOps NDepend extension: Trend charts
  • A panel shows a code metrics recap for each assembly, namespace, class or method. Code metrics include Lines of Code ; Cyclomatic Complexity ; Technical Debt (estimated cost to fix code elements issues) ; Code Coverage ratio ; Comment ratio ; # user / # used... The datagrid is interactive: elements can be grouped, ordered and filtered by name and they can also be sorted by metric value.

    Azure DevOps NDepend extension: Code Metrics details
  • An NDepend Analysis recap is shown in each Build Summary:

    Azure DevOps NDepend extension: Dashboard Recap Build Summary

Report Improvements

  • The new improved report dashboard now contains information on debt and issues.

    Improved Dashboard in Report
  • The report main section contains Quality Gates status summary.

    Quality Gates status summary in Report
  • The report Rules Summary now shows the number of issues added and fixed per rule.

    Rules diff in Report
  • New issues since baseline are shown first in the rule results.

    A color scale is now shown on values making it easier to compare them at a glance.

    Different fonts are used to highlight changes in code elements since baseline: bold font for added code, underlined for refactored code and bold striked for removed code.

    Issues of a Rule in the Report
  • A green/red color scale is now shown on code coverage values.

    NDepend Coverage Report

Interactive Abstractness vs.Instability Diagram in Report (v2017.2)

  • The Abstractness vs Instability diagram provided in the report is now a javascript interactive control.
  • Hovering a dot shows the corresponding assembly name and values.
  • A search textbox lets filter a subset of assemblies by name

    NDepend Interactive Abstractness vs.Instability Diagram

Code Querying Improvements

  • Thanks to the new queryable domains QualityGates, Issues, IssuesInBaseline, Rules queries can be written to match IQualityGate, IIssue, IRule objects according to any criteria (rule violated or not, quality gate status that went from pass to fail, issues added since baseline, issues severity or debt...).

    NDepend Issues Per Rule
  • New syntax to write quality gates.
  • A new button lets you run the currently edited code query against the baseline.

    Quality Gate State on Baseline
  • A code query can now return code elements of various kinds such as assemblies, namespaces, types, methods and fields.

    Thanks to this, new queryable domains are available including CodeElements ANTMF ; CodeElementParents ANT ; TypesAndMembers TMF ; Members MF ; CodeContainers ANTM ; AttributeTargets ATMF ; where Assemblies, Namespaces, Types, Methods, Fields.

  • A query can now return values of technical debt through new types Debt, AnnualInterest, DebtRating, Severity, TrendIcon and can also return System.Version and System.TimeSpan values.
  • A color scale is now shown on query result metric values making it easier to compare them at a glance.

    Code Query on Code Elements
  • You can now write very simple queries like Methods or JustMyCode.CodeElements or codebase.PercentageCoverage. This syntax simplifies writing quality gates and trend metrics queries.
  • Trend metrics used to only be defined with queries that return a scalar. A trend metric can now also be defined with a query that returns rows. In such situation the trend metric value is equals to the row count.
  • Improved query edit experience including:

    - PageUp/PageDown and dot supported on completion items list

    - smart query results column width auto-adjustment

    - no more flickering on query result row sorting.

Smart Technical Debt Estimation

NDepend v2017 is the only Visual Studio extension that can tell the developer that, for example, since this morning the code just written has introduced debt that would cost about 30 minutes should it have to be repaid later.

Knowing this, the developer can fix the code before even committing it to the source control.

  • An NDepend rule can now assign a technical debt and annual interest values to its issues.
  • The technical-debt is the estimated man-time that would take to fix the issue.
  • The annual-interest is the estimated man-time consumed per year if the issue is left unfixed. This provides an estimate of the business impact of the issue.
  • Issues of a rule now have a severity level in the blocker, critical, major, minor, info range.

    The annual-interest is a measure of an issues severity. The severity and the annual-interest represent the same concept where the annual-interest is a continuous measure while the severity is a discrete measure.

  • For example the rule below matches methods which are too complex. The technical debt is linear to the methods excessive complexity and the annuel-interest is linear to the methods code coverage by tests (10 minutes per year for 100% coverage, 2 hours per year for 0% coverage).

    All default rules now have these debt/interest formulas which offer real-world estimations, out of the box. If needed, these formulas can be easily customized.

    Technical-Debt Estimation Formula
  • The dashboard now shows estimated Debt values and evolution since baseline.

    This dashboard is available in the NDepend UI in Visual Studio, in generated reports and in the Azure DevOps web portal.

    Technical-Debt on Dashboard
  • Many facilities are proposed from the dashboard to query/sort/filter/group... the debt estimated values and the issues set.

    These facilities include sorting debt and issues per rule or per code element, focusing on new and fixed debt since baseline and issues to fix by priority heuristics.

    Customizable Quality Gates are now available to define excessive thresholds over debt estimations that might induce build failure and prevent checkin.

    Customizable trend metrics are now available to measure debt trending.

    The key is to offer comprehensive sets of actionable results.

  • The NDepend project properties now has a Debt and Issues panel to customize all technical debt computation aspects.

    This includes estimated Debt and Interest values conversion from man-time to cost estimation.

    This also includes Debt Ratio and SQALE Debt Rating on a code element (as defined by the SQALE method). These are expressed in percentage of the estimated technical-debt compared to the estimated effort it would take to rewrite the code element from scratch.

    Debt settings can also be shared among different NDepend projects.

    Technical Debt NDepend Project Properties
  • More info on Smart Technical Debt Estimation can be found here

Quality Gates

A Quality Gate is a check on a code quality fact that must be enforced before releasing and eventually, before committing to source control.

Quality Gates for example can forbid issues with a certain severity introduced since the baseline, enforce particular code coverage by tests ratio on new and refactored code or enforce thresholds on any Technical Debt measure.

  • CQLinq can now be used to write quality gates. Technically a quality gate is like a trend metric. It's a code query that returns a scalar or rows (in which case the value is the row count). In practice a quality gate is used to fail a build when some thresholds are violated. A warn threshold, a fail threshold and a unit can be provided.
  • Thanks to the new CQLinq capabilities, quality gates can be use to measure and monitor any fact concerning code, but also any fact concerning technical-debt, rules and issues.
  • Quality gates can also rely on differences since baseline (diff), which means that they can monitor progression like new technical debt since baseline or % code coverage on new code written since baseline.

    NDepend Quality Gate
  • 11 quality gates are provided per default and LINQ queries can be written to query the quality gates status.

  • In previous NDepend versions, a build used to fail upon critical rules failures. Now the build fails upon any quality gate failure. The critical rule concept has been kept and the default quality gate Critical Rules Violated mimics the build fail behavior of previous NDepend versions.

Issues Management

  • A new Issues menu offers actionable options to list issues to be fixed by priority, and browse debt and issues per rule or per code element.

    NDepend Issue Menu
  • Quality gates, rules and issues numbers are shown from the dashboard. All these numbers are clickable to get lists of quality gates, rules or issues.

    NDepend Issue on Dashboard
  • A single click allows to list issues with a particular severity, added or fixed, since baseline.

    NDepend Major Issues Added Since Baseline
  • New menu to list issues concerning a code element.

    NDepend Issue Menu on Code Element
  • Hovering an issue with the mouse displays a complete description.

    NDepend Issue Tooltip
  • Code element tooltip now shows debt and issues related data.

    NDepend Class Tooltip

Enhanced Baseline Experience

Do you want to measure progress since this morning, last week or since the last release?

Choose the baseline in a single click from the Dashboard and harness the updated results in just a few seconds.

  • Any stored baseline can be applied from the dashboard through a single click.

    Code base diff, rules, issues and quality gates are then recomputed in a few seconds.

    NDepend Choose Baseline
  • Any newly created project now has the baseline settings set to 30 days ago per default.

    As a consequence, the stored baseline with the date closest to 30 days ago is applied.

    The first analysis result of a project is compared with itself since no other result can be used as the baseline.

  • Rules and Quality Gates are now executed against both current and baseline analysis results. Debt estimation, issues and status differences can then be queried.

    New Debt And Issues Per Rule
  • The search panel can now match all code elements added, refactored or removed since baseline.

    The results also show debt and issues information.

    This perspective is ideal to browse changes and issues introduced since baseline.

    NDepend Code Review Diff since Baseline

Default Rules-Set Improvements

  • All default rules now include debt/interest estimation formulas that offer real-world estimations of the technical-debt, out of the box. If needed, these formulas can be easily customized.

    Typically rules related to poor coverage, poor quality and poor structure are the highest source of technical-debt.

  • Thanks to the new CQLinq capabilities 52 existing rules have been improved to offer fewer false positives and more relevant data.
  • For example the rule Avoid namespaces mutually dependent has been improved to offer actionable results. It now lists all dependencies to remove at type and method level to reach a clean layered code structure.

    Actionable result to obtain code cleanly layered
  • New rule Assemblies should have the same version lists application assemblies that have a different version than most other application assemblies.
  • New rule Avoid non-readonly static fields.
  • New notmycode query Discard generated Namespaces from JustMyCode matches the VB.NET generated namespace My.
  • The notmycode query Discard generated Types from JustMyCode now also matches anonymous types.

Improved SonarQube Integration

  • For each issue, now the technical debt measure and the severity are imported into the SonarQube system.
  • For each issue, now the Description and HowToFix texts of the parent rule are shown in the SonarQube interface.
  • The user doesn't need anymore to do the NDepend rule registration step with NDepend.SonarQube.RuleSetBuilder.exe before analyzing.
  • In case of analyzing several Visual Studio projects (which is the most common case), now the user doesn't need to do anything special to make sure that the NDepend analysis is executed once.
  • Bug fixed: To be considered as activated, an activated rules must have all its parent group (recursive) activated. Only the direct parent activation was checked.
  • See the updated documentation here

    Improved Integration of NDepend in SonarQube

Enhanced Visual Studio Integration

  • NDepend analysis can be started after a build to automatically refresh NDepend results. New settings are provided to avoid starting the NDepend analysis when the builds purpose is to provide up-to-date compiled bits for a run session, a debug session or a unit-test session. In such a situation, it might be preferable to avoid starting the NDepend analysis to avoid both consuming CPU cycles and distracting the developer's focus.
  • Minimal interval between NDepend results being refreshed automatically after a build in Visual Studio which can now also be expressed in minutes.

NDepend.API Improvements

  • Possibility to compute an issues-set and an issues-set-diff through a single method call thanks to the new methods ComputeIssues() and ComputeIssuesDiff() declared in ExtensionMethodsProjectAnalysis.
  • Possibility to compile a code query once and resolve it against multiple code bases. This facility represents a significant optimization when multiple resolutions are needed, because query compilation is way slower than query resolving.

    Related method ExtensionMethodsQuery.CompileNoResolve() which returns a IQueryCompiledUnresolved that presents two Resolve() methods, against a ICodeBase and an ICompareContext.

  • The new method ExtensionMethodsQuery.GenerateCompletionItems() provides completion items in code query edition context.
  • The new method ExtensionMethodsQuery.CompileMany(IEnumerable<IQuery>) takes an enumerable of IQuery and returns a dictionary of IQueryCompiled indexed by IQuery.

Other Improvements

  • When the user chose assemblies to analyze that are not compiled in DEBUG mode, with PDB file missing, a warning message is shown to the user. (v2017.2.1)
  • When analyzing a project for the first time, the dependency graph doesn't show anymore third-party assemblies if the total number of assemblies (application and third-party) is higher than 30 and if the number of application assemblies is higher or equal to 5. (v2017.2.1)
  • 25 bugs fixed
  • v2017.2.1 all details
  • v2017.2.0 all details
  • v2017.1.1 all details
  • v2017.1.0 all details