July 1, 2015 at 21:26Overview of New Features in NDepend 6
What is NDepend has already been said on Habré - this is a static code analyzer on .NET. Recently, a new - the 6th version of this wonderful utility has been released, the new features of which are described below. This is a translation, the original article is here .
Recently released NDepend 6 . Until now, the release of major releases has been scheduled for a while after the release of Visual Studio, and now Visual Studio 2015 is in a pre-release state. NDepend 6 is the result of hard work for 18 months. After 11 years of development, NDepend has reached a certain level of maturity, but there are still many opportunities and improvements that can be made. And for version 6, the most delicate issue was choosing new features and improvements for users. Since version 5 was released in 2013, ideas have been received with Visual Studio User Voices and NDepend User Voices . As a matter of fact, the new features of the 6th version reflect well the most demanded featuresthat have been completed.
Users have requested greater integration of NDepend into the automatic build process. They ran NDepend.Console.exe to collect information and report whether important rules were violated that make the build process unsuccessful (this information can be obtained from the return code from NDepend.Console.exe). Users were asked to show more information directly in the build tools. There are many build technologies, the most requested of which are TFS , TeamCity and SonarQube. As a result, the developers collaborated with top-notch experts in these technologies to make built-in integration, which supposedly includes most usage scenarios, and which will be supported for future versions and gain new features.
Because Since users wanted more integration with the build process, over the past year, efforts have mainly been devoted to tools for Visual Studio. NDepend was integrated into Visual Studio using VS Addin technology - this decision was made by the development team in 2009. At that time, VSIX (another stopob for developing extensions for the studio) was raw, and it was also necessary to support VS2008 and VS2005, so VS Addin was the right choice. Over time, VS Addin became less and less relevant, did not receive improvements from Microsoft, and led to crashes, but most importantly, it was not possible to remember the location of NDepend windows at runtime. This caused users great inconvenience and ended with requests for User Voice to remember the location of the windows .
Starting with version 6, NDepend is based on VSIX technology for integration into VS 2015, 2013, 2012 and 2010. In addition, Microsoft has banned the use of VS Addin in the 2015 studio. In any case, thanks to VSIX, it became possible to make a smoother and more reliable integration with Visual Studio, with window memorization, new features (for example, attaching an NDepend project to .suo (and not just to .sln), and full support for hot keys).
Also, there were three features presented by the free studio extensions that were included in NDepend so they were always at hand.
Rules for .NET code are NDepend's main feature. Users left a lot of feedback on ways to improve existing rules, mainly to reduce false positives. Therefore, about a third of the default rules were redone in accordance with their recommendations.
It's great that the rules for the code are C # mutable LINQ queries that contain a few comments. But for many users, they were not informative enough about why the rule generated a warning, why compliance with a particular rule would improve the code, and how to fix a rule violation. Therefore, the ability to add 2 formatted texts to the source code of the NDepend rule through tags
Another need for users was to make rules available between several NDepend projects. Typically, a company has several projects analyzed using NDepend, and users want to manage them all at once. And taking into account that writing NDepend rules for .NET code is easier than anywhere else, users wanted the ability to use one profile for different projects. Therefore, in NDepend 6, it is possible to define a list of rules that can be used together in NDepend projects.
NDepend already had visualization of code metrics using treemap , and it was decided to add coloring. The idea is that you can show two code metrics. One is represented by a rectangular area, and the other by the color of the rectangle. For example, the following picture shows the coverage of NDepend 6 code with tests in a specific, but convenient and accurate way.
Taking a look, it is immediately clear that a color treemap can help to understand information that would be difficult to understand in another way. Despite the fact that the NDepend code is 82% covered by tests, you can see clusters of red rectangles that show the code that is not sufficiently covered by tests. There is probably no longer a tool that can show this with such accuracy.
NDepend developers are trying to make product features cohesive. Therefore, you can visualize not only any two of NDepend ’s many metrics , but also your code metrics described through LINQ queries in C # , and you can also highlight the final code of a rule or query. As a result, if you request complex methods, you can display them on a color treemap:
It is worth noting that since code coverage with tests is one of the most important quality indicators, a separate interface has also been added for this in the query code results:
The product is in an ever-changing environment. This means some features that work well before should be reviewed. Some of these needed improvements were made in NDepend version 6.
Helper code generated by the C # and VB.NET compiler: From version to version, more and more sugar appeared in C # and VB.NET. It started with anonymous methods and iterators in C # 2.0. Then lambdas and anonymous types appeared in C # 3.0, and then async / await in C # 5.0. These constructs force the compiler to generate additional methods and types. And because these constructs are used quite often; these generated elements are accumulated in the IL code. And NDepend relies heavily on IL code to get code information.. Therefore, the NDepend code model includes all the generated methods and types, and this annoys the user who is mainly interested only in his code. Now NDepend fixes this. Just getting rid of all these generated elements is not an option, as they actually contain some user code. Therefore, some heuristics have been developed to combine these generated elements with custom classes and methods that contain the code that makes the compiler generate it. Thus, there was no compromise - all code model data was saved, including code metrics (number of lines, percentage of coverage, cyclomatic complexity, ...), dependencies and differences.
Improved async support:Asynchronous constructs have specificity, which caused some difficulties with NDepend. Custom code is actually embedded by the compiler in the generated method, which overrides the IAsyncStateMachine.MoveNext () virtual method . Therefore, the IL code that calls this generated MoveNext () method is associated with an abstract interface method, not an implementation. Asynchronous method calls are lost in the IL code ... and therefore in the NDepend code model. Thanks to the heuristics written for the previous paragraph, NDepend is now able to analyze and identify the correct calling asynchronous methods.
High Resolution Support:Now high-resolution monitors (such as 4K) are becoming available and, as a result, more and more developers are working with the appropriate Windows settings. This means that the pixel density is higher and, therefore, more pixels are used to display a graphic element (text, picture). NDepend's interface is mainly based on Windows Form and GDI +, and these technologies by default do not scale very well when Windows is set to high resolution. When users started reporting this problem, it was decided to redo the entire NDepend interface so that it could work with resolution settings from 100% to 250%. It was an opportunity to improve some graphic elements and learn some ways to work with Windows Form and GDI + at high resolution. The results of this will be described in a future NDepend blog post, as on the Internet it is clear that this is a problem for many developers.
Topics in Visual Studio: Statistics show that most users use NDepend from Visual Studio. Therefore, the NDepend interface themes do not blend well with standard Visual Studio themes such as Light, Dark, Blue and the standard VS2010 theme. Fortunately, in NDepend, menu items, panels, bindings ... are based on the DevExpress WinForm library and their latest version includes these themes (and not only). Therefore, a simple update to the latest version helped.
Analysis Improvement:Some improvements had to be made regarding analysis. NDepend's project references some directories and assembly names (without a file extension). During the analysis, the location of the assemblies for analysis was found in the following two ways. If many copies of the assembly were found, then if they are all the same, then NDepend took one of them, and if they were different, then NDepend reported an error, because this situation is considered a serious problem of deploying a solution. But over time, new technologies, such as Windows Phone or Portable Class Libraries, appeared, and they led to such a situation during proper operation. Therefore, when such a situation is detected, NDepend 6 now uses heuristic analysis to find the correct assembly based on its version, dependencies and file size.
The right choice of new features
Recently released NDepend 6 . Until now, the release of major releases has been scheduled for a while after the release of Visual Studio, and now Visual Studio 2015 is in a pre-release state. NDepend 6 is the result of hard work for 18 months. After 11 years of development, NDepend has reached a certain level of maturity, but there are still many opportunities and improvements that can be made. And for version 6, the most delicate issue was choosing new features and improvements for users. Since version 5 was released in 2013, ideas have been received with Visual Studio User Voices and NDepend User Voices . As a matter of fact, the new features of the 6th version reflect well the most demanded featuresthat have been completed.
Integration into the build process
Users have requested greater integration of NDepend into the automatic build process. They ran NDepend.Console.exe to collect information and report whether important rules were violated that make the build process unsuccessful (this information can be obtained from the return code from NDepend.Console.exe). Users were asked to show more information directly in the build tools. There are many build technologies, the most requested of which are TFS , TeamCity and SonarQube. As a result, the developers collaborated with top-notch experts in these technologies to make built-in integration, which supposedly includes most usage scenarios, and which will be supported for future versions and gain new features.
Improved Visual Studio Integration
Because Since users wanted more integration with the build process, over the past year, efforts have mainly been devoted to tools for Visual Studio. NDepend was integrated into Visual Studio using VS Addin technology - this decision was made by the development team in 2009. At that time, VSIX (another stopob for developing extensions for the studio) was raw, and it was also necessary to support VS2008 and VS2005, so VS Addin was the right choice. Over time, VS Addin became less and less relevant, did not receive improvements from Microsoft, and led to crashes, but most importantly, it was not possible to remember the location of NDepend windows at runtime. This caused users great inconvenience and ended with requests for User Voice to remember the location of the windows .
Starting with version 6, NDepend is based on VSIX technology for integration into VS 2015, 2013, 2012 and 2010. In addition, Microsoft has banned the use of VS Addin in the 2015 studio. In any case, thanks to VSIX, it became possible to make a smoother and more reliable integration with Visual Studio, with window memorization, new features (for example, attaching an NDepend project to .suo (and not just to .sln), and full support for hot keys).
Also, there were three features presented by the free studio extensions that were included in NDepend so they were always at hand.
Rules Enhancements
Rules for .NET code are NDepend's main feature. Users left a lot of feedback on ways to improve existing rules, mainly to reduce false positives. Therefore, about a third of the default rules were redone in accordance with their recommendations.
It's great that the rules for the code are C # mutable LINQ queries that contain a few comments. But for many users, they were not informative enough about why the rule generated a warning, why compliance with a particular rule would improve the code, and how to fix a rule violation. Therefore, the ability to add 2 formatted texts to the source code of the NDepend rule through tags
Another need for users was to make rules available between several NDepend projects. Typically, a company has several projects analyzed using NDepend, and users want to manage them all at once. And taking into account that writing NDepend rules for .NET code is easier than anywhere else, users wanted the ability to use one profile for different projects. Therefore, in NDepend 6, it is possible to define a list of rules that can be used together in NDepend projects.
Visualization of code metrics
NDepend already had visualization of code metrics using treemap , and it was decided to add coloring. The idea is that you can show two code metrics. One is represented by a rectangular area, and the other by the color of the rectangle. For example, the following picture shows the coverage of NDepend 6 code with tests in a specific, but convenient and accurate way.
- Rectangles - methods,
- Rectangular areas are proportional to the number of lines of code,
- The color of the rectangle is the percentage of code coverage with tests.
Taking a look, it is immediately clear that a color treemap can help to understand information that would be difficult to understand in another way. Despite the fact that the NDepend code is 82% covered by tests, you can see clusters of red rectangles that show the code that is not sufficiently covered by tests. There is probably no longer a tool that can show this with such accuracy.
NDepend developers are trying to make product features cohesive. Therefore, you can visualize not only any two of NDepend ’s many metrics , but also your code metrics described through LINQ queries in C # , and you can also highlight the final code of a rule or query. As a result, if you request complex methods, you can display them on a color treemap:
It is worth noting that since code coverage with tests is one of the most important quality indicators, a separate interface has also been added for this in the query code results:
What else was to be done
The product is in an ever-changing environment. This means some features that work well before should be reviewed. Some of these needed improvements were made in NDepend version 6.
Helper code generated by the C # and VB.NET compiler: From version to version, more and more sugar appeared in C # and VB.NET. It started with anonymous methods and iterators in C # 2.0. Then lambdas and anonymous types appeared in C # 3.0, and then async / await in C # 5.0. These constructs force the compiler to generate additional methods and types. And because these constructs are used quite often; these generated elements are accumulated in the IL code. And NDepend relies heavily on IL code to get code information.. Therefore, the NDepend code model includes all the generated methods and types, and this annoys the user who is mainly interested only in his code. Now NDepend fixes this. Just getting rid of all these generated elements is not an option, as they actually contain some user code. Therefore, some heuristics have been developed to combine these generated elements with custom classes and methods that contain the code that makes the compiler generate it. Thus, there was no compromise - all code model data was saved, including code metrics (number of lines, percentage of coverage, cyclomatic complexity, ...), dependencies and differences.
Improved async support:Asynchronous constructs have specificity, which caused some difficulties with NDepend. Custom code is actually embedded by the compiler in the generated method, which overrides the IAsyncStateMachine.MoveNext () virtual method . Therefore, the IL code that calls this generated MoveNext () method is associated with an abstract interface method, not an implementation. Asynchronous method calls are lost in the IL code ... and therefore in the NDepend code model. Thanks to the heuristics written for the previous paragraph, NDepend is now able to analyze and identify the correct calling asynchronous methods.
High Resolution Support:Now high-resolution monitors (such as 4K) are becoming available and, as a result, more and more developers are working with the appropriate Windows settings. This means that the pixel density is higher and, therefore, more pixels are used to display a graphic element (text, picture). NDepend's interface is mainly based on Windows Form and GDI +, and these technologies by default do not scale very well when Windows is set to high resolution. When users started reporting this problem, it was decided to redo the entire NDepend interface so that it could work with resolution settings from 100% to 250%. It was an opportunity to improve some graphic elements and learn some ways to work with Windows Form and GDI + at high resolution. The results of this will be described in a future NDepend blog post, as on the Internet it is clear that this is a problem for many developers.
Topics in Visual Studio: Statistics show that most users use NDepend from Visual Studio. Therefore, the NDepend interface themes do not blend well with standard Visual Studio themes such as Light, Dark, Blue and the standard VS2010 theme. Fortunately, in NDepend, menu items, panels, bindings ... are based on the DevExpress WinForm library and their latest version includes these themes (and not only). Therefore, a simple update to the latest version helped.
Analysis Improvement:Some improvements had to be made regarding analysis. NDepend's project references some directories and assembly names (without a file extension). During the analysis, the location of the assemblies for analysis was found in the following two ways. If many copies of the assembly were found, then if they are all the same, then NDepend took one of them, and if they were different, then NDepend reported an error, because this situation is considered a serious problem of deploying a solution. But over time, new technologies, such as Windows Phone or Portable Class Libraries, appeared, and they led to such a situation during proper operation. Therefore, when such a situation is detected, NDepend 6 now uses heuristic analysis to find the correct assembly based on its version, dependencies and file size.