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.
  • 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.
  • (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.
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
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.

New Tutorial Videos
  • A dozen of videos are now available to get started with each NDepend feature. Watch them here.
  • 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 VS solutions.
  • The result is less maintenance: the assemblies-set analyzed remains automatically synchronized with the VS projects-set when some VS projects are added or removed from the VS solution analyzed.
  • One or several textual filters on VS 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 VS solution dialog now proposes to reference the VS 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
  • NDepend is now able to import coverage data from one or several OpenCover coverage file (.xml extension).
  • More info in the documentation here.
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 VS 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 VSTS 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.

  • 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:
  • When editing a rule, a suppressed issues list can also be displayed in addition to the issues list.
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 VS 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.

  • 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 VS solution or a VS project, if an assembly name was different from its VS project file name, the assembly was (previously) not resolved.
  • When inferring the assemblies to analyze from a .NET Core VS solution or a VS 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 VS by double-clicking a solution file, if an NDepend project was attached to the solution it would (previously) not load upon VS 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

Support for .NET Core 2.1 Preview
  • Applications developed with .NET Core 2.1 Preview can be analyzed.
  • Here you can read a blog post about spotting new .NET Core 2.1 APIs with NDepend.
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
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.

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.
.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 VS 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 Team Services 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 coloured 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.
Visual Studio Team Services VSTS and TFS 2017 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 VSTS extension consists of a build task that analyses code and code coverage data yielded by the build process. The NDepend VSTS/TFS hub presents the results which embed the NDepend dashboard and makes data actionable by drilling down into any item through a single click.

  • 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.

  • 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.

  • 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 VSTS Code Search extension, displaying the source code of the culprit code element.

  • 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.

  • The VSTS 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.

  • A panel shows a code metrics recap for each assembly, namespace, class or method. Code metrics include Lines of Code ; Cylomatic 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.

  • An NDepend Analysis recap is shown in each Build Summary:

Report Improvements
  • The new improved report dashboard now contains information on debt and issues.
  • The report main section contains Quality Gates status summary.
  • The report Rules Summary now shows the number of issues added and fixed per rule.
  • New issues since baseline are shown first in the rule results.

    A colour 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.

  • A green/red colour scale is now shown on code coverage values.
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
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...).
  • New syntax to write quality gates.
  • A new button lets you run the currently edited code query against the 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 colour scale is now shown on query result metric values making it easier to compare them at a glance.
  • 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 VS 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.

  • 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 Team Services web portal.

  • 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.

  • More info on Smart Technical Debt Estimation 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.
  • 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.
  • 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.
  • A single click allows to list issues with a particular severity, added or fixed, since baseline.
  • New menu to list issues concerning a code element.
  • Hovering an issue with the mouse displays a complete description.
  • Code element tooltip now shows debt and issues related data.
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.

  • 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.
  • 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.

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.
  • 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
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 VS 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