This year marks a decade since I started to use NDepend to assess the quality of .Net projects.
NDepend got much better over the years, and as far as I can tell, it is still the most flexible and versatile tool in this space. After using the current version for the last three months, it is about time to give NDepend some space in this blog.
What is NDepend?
NDepend offers an in-depth .NET code quality assessment that starts with analysing your application, creates reports of the findings inside Visual Studio or as an HTML report, and gives guidance on how to fix the problems. Unlike other tools, NDepend offers a domain specific language that allows you to find problematic hotspots in your application based on your own rules and ideas. You can persist those queries and run them against all your applications.
The price of NDepend starts at €399 for a single developer license and €799 for build machines.
New with v2023.2
The biggest new feature for NDepend is most certainly the full support for .Net 8. We now can analyse all project types and get a quality report for ASP.NET-, Blazor-, desktop-, and console applications. The support for .Net 8 also covers the newly introduced features of C# 12.
Another nice improvement is the analysis speed. We can now get our quality reports much faster than with the previous versions. The improvement is so good that we can run NDepend on larger applications and we did not notice a significant delay until the report pops up.
The report got a visual refresh and I find the improved layout much calmer. The navigation is a great help to jump from one part to another. You can get an impression of how that looks now with the sample reports.
My favourite feature: the inline code for issues
So far, we only could access the code on the machine where we run the report – or a machine that had the exact same setup for the code repositories. With v2023.2 that changed for the issues: we now can see the issues as an overlay over the code:
If we have the code coverage report in a format that NDepend supports, we get the coverage information directly mixed with our issues:
When we run multiple NDepend checks over time, we get a diff viewer directly within the report. On the left side is the code from the baseline (the previous time we made the analysis) and on the right side we have the new code. That allows us to check what happened to the code directly in the report:
The code is part of the report. That allows us to share the report with other developers and they can get the same overview of the problems of a class as we can in the desktop application of NDepend.
Just be aware of this new feature when you share the report. Those who can read the report can also see the code.
NDepend API
Most people will use the Visual Studio extension or the stand-alone application to interact with the result of the quality check. However, there is another way in which we can access the NDepend API.
The API allows us to write our own code that uses the features of NDepend for our own use cases. If you like NDepend but cannot get your desired outcome through the customisation options, then the API may be the right place for you.
I could create a spike for an idea I had without much effort. Should this idea materialise into something useful, I will let you know in due time.
Conclusion
NDepend offers a lot of flexibility and comes with helpful default values. You can start with the first analysis by pointing NDepend to the solution file (*.sln) of your application and you get a report of your quality problems right away. If you want to dig deeper, you need to spend some time to learn the basics of NDepend. It is worth it and can help you to spot problems long before they slow down your development efforts.