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.

Less 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'

6 minutes videos

6 minute video presents the main graph features.

Drag and Drop from Visual Studio Solution Explorer to Graph

Files and Directories in the Visual Studio Solution Explorer can be dragged and dropped onto the graph

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.

Less 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

  • 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


  • 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

  • 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

  • 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",
               Target = "MyNamespace.MyClass.Method()")]

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

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

    namespace MyNamespace {

       // Suppress issues on MyClass by rule ID

       // Suppress issues on all methods of MyClass by rule ID
         "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.
  • When purchasing this annual subscription, you will get a perpetual fallback license for the exact version available at the time of purchase. This perpetual license will allow you to continue to use the software even after the subscription ends, but without support.
  • 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 [email protected] 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