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:
▲▲ Go to Top ▲▲
Warnings about the health of the build process
These warnings can be found:
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:
▲▲ Go to Top ▲▲
Running an Analysis with NDepend.Console.exe
NDepend comes with 4 executables:
Integrate NDepend with TFS
Integrate NDepend with CruiseControl.NET
Integrate NDepend with Team City
Integrate NDepend with FinalBuilder
▲▲ Go to Top ▲▲
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 used at analysis time.
The tab Code to Analyze lets you choose the assemblies analyzed but also the directories that contains them. Analyzed assemblies include both your own assemblies, but also third-party assemblies that are used by your application (like mscorlib.dll or Log4Net.dll).
In the screenshot above you'll notice that directories containing .NET Framework assemblies are absolute. These directories are always absolute and NDepend automatically adapts folders path from the current machine's .NET Framework installation.
You'll notice also that directories that contains application assemblies are relative. The Project Properties tab Paths Referenced (below) lets choose how paths are stored and offer several options to redirect paths. This is useful when the same project file is used in different context on different machine. Each path can be:
In the VisualNDepend or VS addin > Project Properties > Analysis sub-panel, you’ll find several 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 > 0Basically, here (m.WasAdded() || m.CodeWasChanged()) means was added or refactored compare to the baseline. The baseline for comparison can be
The Historic Analysis Results option lets define the location where historic analysis results are stored. Historic analysis results are useful to diff the current snapshot of the code base with a previous one. This option lets also choose the frequency for saving analysis results (at most once a day, a week ...).
The Trend Metrics Log option lets define the frequence of trend metrics log, and also the location where the are saved. More about this in the Trend Metrics Monitoring section.
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 ▲▲