I started by testing out VisualNDepend, that offers the possibility to generate an analysis report for an assembly (or set of assemblies) from an independent GUI (separate from Visual Studio).
Once NDepend is installed, VisualNDepend is located in the root folder. The main application UI at startup looks like this:
Layout-wise, it is somewhat similar to that of Visual Studio, so the UI is pretty intuitive. Before starting the analysis, a new project should be created. A series of .NET assemblies can be analyzed straight away, however, a project will facilitate the later reuse of the analysis results.
Creating a project is also pretty intuitive:
Now comes the part when the developer has to open the solution for analysis. The empty project window will look similar to the Properties dialog in a Visual Studio project:
I am now going to add a solution to the current project. To do this, I selected the Add Assemblies of a VisualStudio Solution option and navigated to my solution.
Once the solution is loaded, I am able to track basic assembly information. I can see the targeted version of the .NET runtime, the CPU architecture for the assembly. I can also easily track the linked assemblies that are used by the main assembly:
This is pretty basic information and to an experienced developer who is directly working with the project isn't of much value. However, the interesting part of NDepend is the report capability. To generate a report, I selected the Report tab and selected the elements I needed to be included. By default, everything but Types Dependencies is selected. I selected that as well. Of course, the developer can customize the report even more by setting the analysis parameters in the Analysis tab, but at this point I will concentrate on the report itself. To generate it, I clicked the Run Analysis on Current Project (can also be triggered by pressing the F5 key).
A HTML report will be automatically generated. The data presented there is pretty impressive, if you ask me. NDepend basically allows the developer to look under the hood of an application at a completely different level.
The first thing that goes in the report are Application Metrics.
What I find quite interesting here is the number of IL (Intermediate Language) instructions compared to the number of lines of code.
The assembly structure is also outlined graphically, depending on each function usage:
Along with other metrics, I am able to see the assembly dependencies diagram, that shows how much an assembly depends on a series of external (be it .NET or third-party) assemblies.
A major part of the report is composed of CQL queries. CQL stands for Code Query Language and it is very similar to SQL, although serves a different purpose. When used in conjunction with Visual Studio, NDepend can be used to track specific code parts with CQL. There is a number of constrains that need to be considered when building CQL queries, but all of them are listed here for reference, so it won't be a problem adapting them to existing code.
A sample CQL query could look like this:
WARN IF Count > 0 IN SELECT TOP 10 METHODS WHERE PercentageComment < 20 AND NbLinesOfCode > 10 ORDER BY PercentageComment ASC
This query will result in a warning for methods that are inside the assembly and are not commented enough.
IMPORTANT NOTE: Once the report is generated, the developer can adjust report settings as well as review the existing metrics in the UI and execute additional CQL queries. The after-report result should look similar to this: