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.
- 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 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:
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
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.
- 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 less 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.
- 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.
- 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