NDepend Analysis
Introduction
NDepend gathers data from a code base.
This includes quality code metrics, test coverage statistics, componentization/architecture/dependencies, evolution and changes, state mutability, usage of tier code and more.
The amount of data gathered is proportional to the size of the code base and can become pretty big in case of a large application analyzed.
NDepend added value lies in its capabilities to let the user browse readily this huge amount of data.
This way developers and architects can know precisely what’s really happening inside their shop and can take decisions based on real facts, not based on intuition and rumor.
There are 2 distinct scenarios to browse data:
- Through a report: NDepend analysis process can be integrated into a build process and can produce a customizable HTML report each time the analysis is run.
The is suited to produce daily dash-boards useful for every members of the team, even non-technical ones.
- Through the interactive UI (standalone with VisualNDepend.exe or 100% integrated in Visual Studio with the NDepend VS addin):
The interactive UI comes with several panels to visualize and query interactively information about the code base.
Interactive UI users are architects and developers that need to dig into details of the code base at any time during development time.
Let's expose here some details about how to integrate NDepend into a build process and customize analysis.
Let's first explain how NDepend can provide useful warnings about the health of a build process.
▲▲ Go to Top ▲▲
Warnings about the health of the build process
These warnings can be found:
- in XML format in the file $AnalysisResultDir$\InfoWarnings.xml,
- in the report section NDepend information and warnings,
- in the panel NDepend Error List in the interactive UI.
What we mean by the health of the build process is some details that can reveal potential flaws. Concretely this includes:
Assemblies versionning issues such as:
- AssemblyA references AssemblyB v2.1 but only AssemblyB v2.0 is available.
- AssemblyA references 2 versions of AssemblyB (which is not necessarily a bad thing, but it's still useful to be aware of such situation).
Assembly conflicts such as:
- The name of my assembly main module file is different from the logical name of my assembly.
- Several different assemblies with the same name can be found (different = different hash code and/or different version).
PDB files issues such as:
- Missing PDB files.
- PDB files and code source files not in-sync.
- PDB files and assemblies are not in-sync.
Coverage files issues such as:
- Corrupted or missing coverage files.
- Coverage files and code source files not in-sync.
- Coverage files and assemblies are not in-sync.
In the Error List panel of the interactive UI you have the possibility to deactivate false warnings to avoid being warned again and again during future analysis.
▲▲ Go to Top ▲▲
Running an Analysis with NDepend.Console.exe
NDepend comes with 4 executables:
- NDepend.Console.exe to run an analysis.
- VisualNDepend.exe a standalone executable to run interactive UI.
- NDepend.Install.VisualStudioAddin.exe to install/uninstall the NDepend Visual Studio addin, to have access to interactive UI features from within Visual Studio.
- NDepend.PowerTools.exe open-source tools based on NDepend.API compiled from the Visual Studio solution: $NDependInstallPath$\NDepend.PowerTools.SourceCode\NDepend.PowerTools.sln.
NDepend.Console.exe is a classic console executable that takes command line arguments.
The only required input is an absolute path to the NDepend project file (extension .ndproj) that defines the code base to be analyzed.
Several command line arguments can be provided and they are listed here: NDepend.Console.exe.
Basically these arguments will let you override folders where assemblies to be analyzed are stored, override the output folder where data produced by the analysis will be persisted and provide a XSL sheet to customize the report.
A simple exec command is needed to integrate NDepend.Console.exe into your build process. More documentation is available concerning the integration of NDepend with different build technologies:
Integrate NDepend with TFS
Integrate NDepend with CruiseControl.NET
Integrate NDepend with Team City
Integrate NDepend with FinalBuilder
▲▲ Go to Top ▲▲
Analysis Options
To handle real-world scenarios, there are several analysis options. Options can be tuned through the VisualNDepend or VS addin > Project Properties panel.
Options are then persisted into the NDepend project file (extension .ndproj) and can be harnessed at analysis time.
The first option is the ability to choose between absolute and relative paths to folders where analyzed assemblies are stored.
Analyzed assemblies include both your own assemblies, but also tier assemblies that are used by your application (like mscorlib.dll or Log4Net.dll).
If you choose the option value relative path, paths are relative to the folder where the NDepend project is stored.
This option is useful when the NDepend analysis is performed on several machines (build servers, developer machines…) where the root folder of the whole development shop can vary.
Notice that the folders where the .NET Framework assemblies are stored are not impacted by relative path option.
NDepend automatically adapts folders path from the current machine's .NET Framework installation.
In the VisualNDepend or VS addin > Project Properties > Analysis sub-panel, you’ll find 3 interesting options beside the project name and output folder.
The Baseline for Comparison option lets define the previous analysis result on which to compare the current analysis performed (or the current analysis result loaded in interactive UI).
This is useful if you’ve defined some CQLinq rules about evolution of your code base like for example, making sure that all new or refactored methods are 100% covered by tests
(More information about this can be found here: Reporting Code Diff) :
warnif count > 0
from m in Application.Methods where
(m.WasAdded() || m.CodeWasChanged()) &&
m.PercentageCoverage < 100
select new { m, m.PercentageCoverage }
Basically, here (m.WasAdded() || m.CodeWasChanged()) means was added or refactored compare to the baseline.
The baseline for comparison can be
- a particular result (like the analysis of the last release we’ve made),
- a result made N days ago
- or the last analysis result available.
Below, you'll find details to detect CQLinq result violations in the report.
The Code Coverage option lets specify the NCover or VisualStudio XML coverage file(s) from which NDepend will gather test coverage statistics.
More details about how to obtain these coverage files can be found in the NDepend documentation Coverage FAQ
The Source File Rebasing option is useful if the code compilation and the NDepend analysis are executed on different machine.
NDepend gathers information from the assemblies, but also from the source files if they are available.
NDepend knows about source files from the PDB files produced by the compilation.
PDB files contain absolute paths to source files. PDB files are initially used by the debugger to link IL compiled code with source files code.
If the code compilation and the NDepend analysis are executed on 2 different machines, it might happen that source files locations are different between the 2 machines.
In this case absolute source files paths contained in the PDB files should be rebased, hence the need for the Source File Rebasing option.
More information about source files rebasing can be found here: Source Files Rebasing
▲▲ Go to Top ▲▲
|
|
NDepend is also available
for
Java and C++
More than 3.000 companies provide better .NET code with NDepend
Full Visual Studio Integration
 |
|