Showing posts from October, 2019

Evaluating NDepend on current codebase Part 2

In Part 1 we saw a first approach to NDepend starting off with analyzing a project of 2 assemblies and focusing on the smaller assembly. In this part we will focus on the main executable and the gems NDepend discovered in it TL; DR Memory leak detected... Photo by  Daan Mooij  on  Unsplash Enter 3 years old WPF project - Main executable Going back to the dashboard I see the "usual" long types or methods errors, some immutability warnings, which I would have set as errors and 400 violations of "Avoid namespaces mutually dependent" some with debt time of 4 days. "Oh come on.. what 4 days. How hard can it be..." Drilling down into the code (a wpf application) I realize that there is a single class that is injected in the constructor of every view model and I hardly see any services in the system save for calls to the DAL assembly. Without drilling down into the class I changed it's namespace and made the necessary, albeit sisyphic, chan

Evaluating NDepend on current code base Part 1

A while ago I was asked by one of NDepend's founders to evaluate any .NET code base I wanted with NDepend and write a blog post about it. It turns out I came up with a two-part post. TL; DR Oh boy.... Photo by geralt on Picabay Enter 3 years old WPF project Without revealing the nature of the specific project I would just say it is a feature rich client, with UI elements customized to the customer's needs. It is written using MVVM, some third party grids and communicates with an SQL Server database via a classic  DAL class library. All and all the project is comprised of one executable and one DAL assembly. So off I went and added the necessary assemblies to a new NDepend project and let the analysis run. Given the size of the project it was pretty swift and started off with a a dashboard (or at least this is the view I chose to start from). NDepend desktop Dashboard At the same time a very nifty HTML based dashboard popped up in my browser NDepend HT