Do the extension supports both Azure DevOps Services (formerly VSTS) and Azure DevOps Server (formerly TFS)?
Yes the extension supports both versions : Azure DevOps Services for the cloud version and Azure DevOps Server for the on-premises version.
Do I have to purchase a license for all the Azure DevOps/TFS users?
No, you have to purchase only the users that will access the NDepend dashboard.
Do the Azure DevOps/TFS extension send any data to an external server?
The NDepend extension does not use an endpoint to do the analysis. The NDepend tool is embedded in the extension and all the results are stored as a build artifacts in your server. No data goes outside of your server.
Why some of my projects are not analyzed?
To analyse an assembly , NDepend needs also its ODB file. And if for some assemblies the PDB file is not generated the assembly will not be parsed.
More information in the Understand the NDepend Analysis Inputs documentation.
How to exclude some projects from the analysis?
To exclude some of your projects, you have to specify an NDepend project file (.ndproj extension) to your task.
In such NDepend project you can specify the assemblies to analyze, and enable the Analyze only the assemblies from the NDepend Task flag
(see the screenshot in the Build Task section of this documentation).
A Developer or Build-Machine license is required to create and edit an NDepend project.
Why sometimes the NDepend results are different in the Azure DevOps/TFS extension?
To have the same results you have to use the same .ndproj project file, define the same baseline and the same coverage data imported.
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.
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 Azure DevOps 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.
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.
This extension only runs on a Windows build agent. This situation might evolve in the future.
1) Enable Scripts to access OAuth token
The NDepend task gets the baseline data stored in your build artifact to achieve the comparison between two builds.
For that you need to enable scripts to access the OAuth token, that will permit to access to the build artifacts using the Azure DevOps Rest API.
This option can be either enabled from the yml script...
All the parameters are optional, and here are their definitions:
viewname: It allows you to have multiple configurations for the same project, each project has its own ndproj file.
excluded: It's a regex expression to filter the assemblies.
Assemblies: If it's set to true, NDepend will analyze only the assemblies referenced from the ndproj file.
BuildGates: If it's set to true the build will fail if a quality gate failed.
PullRequest2: Set it to true if you want to associate the NDepend issues to a pull request.
iscoverage: Set it to true if you have some extra directories where the coverage files exist.
3) Configure the NDepend Task
NDepend Project: Specify the NDepend project that contains your rules.The ndproj file is published as an artifact against the source directory. If it's not specified the default ones will be used.
Exclude assemblies that match the regex patterns: This option is useful to exclude some dlls from the analysis, like the unit test ones.The regex patterns are separated by ';'.
Analyse only Assemblies referenced from the .ndproj: This option is useful to focus only on a subset of all assemblies built by the build Azure DevOps/TFS build agent.
Stop the Build when at least one Quality Gate fails.
4) Enable the code coverage
To get the coverage data from the Azure DevOps test task you need to activate the code coverage:
However if you are running a specific or custom task to gather code coverage with a technology different than Microsoft Visual Studio coverage
you can still use the Get Coverage Files from a specified directory NDepend task option option.
NDepend will be smart enough to determine for each coverage file (there can be one or many), which coverage technology has been used to generate it and how to import this data.
VS Coverage, dotCover, OpenCover and NCover coverage technologies are supported.
The NDepend extension detects by default all the assemblies of your application.
However, sometime one or several assemblies referenced by your application (like Log4Net.dll for example, what is called a third-party assembly)
can be also considered as part of your application.
In such case here are the steps to follow to exclude the third party assemblies:
Create a new NDepend project.
Add your assemblies from the Project Properties => Code To Analyze tab.
Save the .ndproj file.
Upload the .ndproj file into your Devops source repository.
From the NDepend task configuration, reference the .ndproj file in the “NDepend Project” input. And check also the “Analyse only the assemblies referenced from the .ndproj”.