Understanding NDepend Analysis Inputs

This documention clarifies from where NDepend analysis gathers its inputs:

  • .NET assemblies obtained from your .NET solution(s) .sln and project(s) .csproj
    • .NET assemblies of your application (mandatory) can be referenced directly by the NDepend project file.
    • Since NDepend v2019.1 the NDepend project file can also reference one or several Visual Studio solution(s) and project(s) from which some .NET assemblies to analyze will be resolved.
    • Third-party .NET assemblies referenced by assemblies of your application (they are automatically resolved from application assemblies).
    See the section How NDepend is resolving assemblies for more details on this topic.
  • .NET PDB files corresponding to assemblies of your application (optional),
  • C# source files (optional),
  • Code coverage result files produced by Visual Studio, NCover, NCrunch, dotCover or OpenCover (optional) (see more on code coverage technologies supported here).
  • Roslyn Analyzers' Issues serialized in .json file through the SARIF format (optional) (see more on importing Roslyn Analyzer's Issues here).
ndepend dotnet framework treemap large poster

Here are various notes:

  • The 3x vertical orange rows on the left reflect the fact that:
    • .NET Assemblies file (.dll) are inferred from solution(s) .sln and project(s) files .csproj
    • PDB files location are inferred from assemblies files location
    • Source files are referenced from PDB files
    Coverage files and Roslyn Analyzer's Issues files location cannot be inferred and must be specified.
  • A PDB file does not need to reside in the same folder as its corresponding assembly. NDepend will try first to find the PDB in the same folder and if not found, it will try to find it in any of the folders specified.
  • Not all C# source files needed to build a .NET assembly are referenced from the PDB file. Only those containing some non-abstract methods are referenced. However NDepend uses a heuristic to find the corresponding Visual Studio project file from the referenced PDB files. If the Visual Studio project file is found, NDepend can then know about all source files referenced by the project.
  • In case the server used to build the assemblies is not the same as the server that performs the NDepend analysis, there is the possibility to rebase the location of source files as in Source Files Rebasing.
  • The bulk of data used by NDepend comes from assemblies themselves. Only the number of logical lines of code is computed from PDB files.
  • Source files are parsed to obtain metrics relative to comments: PercentageComment, and NbLinesOfComment.
  • NDepend computes the Cyclomatic Complexity from the IL code. If source files are available it computes also the Cyclomatic Complexity from the source code. Experience shows that IL CC is a bit larger than the Source code CC. Indeed, a C# 'if' expression yields one IL jump. A C# 'for' loop yields two different offsets targeted by a branch IL instruction while a ‘foreach’ C# loop yields three.
  • So far only C# source files can be parsed by NDepend and in the future we plan to parse also VB.NET source files. Notice that because the number of lines of code is computed from PDB files, this metric is available for all .NET languages.
  • If some PDB files and/or some source files are missing, NDepend will warn about it but won’t stop the analysis. As the bulk of data is inferred from assemblies themselves it is still useful to analyze assemblies only, especially third party assemblies not released with source code.
  • You can read the Coverage FAQ to know more about NCover and Visual Studio coverage XML files. Coverage metrics values are inferred from these files, including: PercentageCoverage, NbLinesOfCodeCovered and, NbLinesOfCodeNotCovered.
  • Finally, NDepend will detect and warn about any synchronization issue between assemblies, and PDB files, sources files and coverage files.