-
Analysing .NET code dependencies–NDepend
This is the first in a series of posts on reviewing tools for analysing .NET code dependencies.
I last wrote about NDepend briefly four years ago, and with a bit more detail way back in 2010. Some of the features added since then include:
- Support for Visual Studio 2013 and 2015
- Now a proper VSIX extension (v6)
- NDepend project can be included in VS solution.
- New Dashboard Panel – state of your code base at a glance
- Focus on recent rules violations – only show rule violations on added/modified code
- UI enhancements – improved menus
- Better path management – UNC paths and support for environment and MSBuild variables.
- Windows Store and Windows Phone support – honours the TypeForwardedToAttribute
- Trend monitoring – monitor trend metrics and view via trend charts
- Share rules between projects
- Rules
- Rule descriptions and fix suggestions added
- Reduction in false positive detection
- TFS integration
- 2013 (2015 is coming)
- SonarQube integration
- TeamCity integration
- Report enhancements – report includes trend metric charts
- More console options – additional parameters to support file and directory variables.
- Coloured Code Metric view – treemap elements can be coloured to indicate second metric
- Code coverage shown with red/green colouring
- Improved handling of compiler-generated code
- Async support
- High DPI support
- Visual Studio theme support
So let’s take NDepend v6 for a spin and see what it can do.
I’m going to use the Open Live Writer code base for these reviews. The writer.sln contains 28 projects and around 3,000 types.
The OLW solution is special in that most projects point to the same single output folder. As a result you might have to tell NDepend to look in this output directory rather than just relying on it to examine the solution’s projects. Once the assemblies are selected, the analysis begins.
Analysis might take a minute or two, but when it finishes you are prompted to view the results. I chose the Dashboard view:
To dig into the dependencies, let’s look at some useful diagrams. First up, the Dependency Graph. Go to NDepend, Graph, View Application Assemblies Only.
By default, the size of each ‘node’ indicates the relative number of IL instructions in that assembly. From the graph above, it’s obvious that OpenLiveWriter.PostEditor is the largest assembly. That sounds reasonable given that OLW is all about editing posts.
Switching to the Matrix, here again is the ‘Application Assemblies Only’ view:
The intersections where there are 0 methods used from the assembly reference bear further investigation. Sometimes there might be a valid reason, but quite often this represents an unnecessary assembly reference that can be removed.
The query language is very powerful. I’d like to find assemblies that are only referenced by one other assembly. Matching assemblies could be candidates for merging with the parent assembly if there’s no good reason for keeping them separate.
I came up with this custom query:
from m in Assemblies.ExceptThirdParty() where m.AssembliesUsingMe.Count() == 1 select new { Parent = m.AssembliesUsingMe.First() , Child = m}
Which returned the following results:
- OpenLiveWriter.FileDestinations
- OpenLiveWriter.HtmlEditor
- OpenLiveWriter.InternalWriterPlugin
Are all referenced only by OpenLiveWriter.PostEditor. That’s useful to know.
Jumping back to the dashboard, let’s drill in to see some of those “Critical Rules Violated”. Clicking on this heading in the dashboard opens the Queries and Rules Explorer, with the “14 Critical Rules Violated” filter selected.
Selecting the top item in the list opens the Queries and Rules Edit window, with the top half showing the actual query that was used to search for the violations and the bottom half showing a tree of matches for this rule (in this case it’s the offending methods). So that Init() method takes 15 parameters. Maybe that’s ok, maybe not.
I love digging around the results of these kinds of rule queries. Particularly the ones around potential dead code, where you end up identifying and removing code that isn’t being used anymore.
NDepend has really progressed over the years. It’s particularly nice to see the improved integration with Visual Studio. Ideally every developer would have NDepend in their toolbox to use themselves, but a first step is probably including it as part of your build pipeline. That way, at least everyone can view the reports it generates as part of the build results.
- Support for Visual Studio 2013 and 2015
-
Analysing .NET code dependencies–Overview
How can you tell if modules/components in your application are loosely-coupled between each other, and tightly cohesive internally? You could read the code line-by-line, but that becomes difficult once the codebase becomes large.
It can be very valuable to be able to visualise the the dependencies between the various components that make up your application – both at the class and module/assembly level. These tools analyse code, either by parsing the source code, or by analysing the compiled assemblies to produce various summaries and reports about the state of the code.
I’m planning to spend a bit of time in future blog posts reviewing a number of these tools that can help with this analysis, including:
I’m also interested to hear what you use. Let me know in the comments of your experiences with these or other tools I haven’t mentioned.
-
My new Dell XPS 15 laptop
My birthday has come early this year. I’ve finally bought a new laptop! It wasn’t the cheapest either, so I think that will cover a couple more birthdays in the future too 😀
I’d been evaluating a number of different manufacturers and models, and eventually went with a Dell XPS 15 (9550). I’d had a pretty good run with my old XPS 1645 and that counted in the XPS 15’s favour.
I bought the 1645 in 2010, so I was expecting to buy something that represented 6 years of technology improvements. So far I think the 15 delivers that.
- 16GB DDR4
- 512GB SSD (PCIe)
- 4K Ultra HD (3840 x 2160) touch display
Modifications
Out of the box, the top row of the keyboard defaults to the feature keys. I make use of the Function keys (F1, F2, etc) much more than I’d use the feature keys (Mute, Volume Up/Down, etc) so I went into the UEFI firmware settings and changed that to default to function keys.
Here’s a comparison of the keyboards of the 1645 and 15 (the shiny strip above the main keyboard on the 1645 has the feature keys). Obviously fashions change too – from glossy/shiny to matte.
I HATE touchpads that simulate a mouse click with a single tap. Maybe it’s my hands but I find I end up ‘clicking’ a lot more than I intended. So it’s another thing I try to disable if possible. On the 1645 this was done through the Synaptics touchpad driver, but that isn’t present on the 15. Instead it turns out that’s a setting provided by Windows itself.
Old and new comparison
Here’s the 15 sitting on top of the 1645, to show it’s slightly smaller.
Side views show the 15 is a fair bit slimmer. The 1645 comes with VGA, HDMI and DisplayPort ports – the 15 just has a single HDMI, but you can get an external adapter with a second HDMI and VGA (as well as extra USB and Ethernet). No DVD drive in the 15 either!
The rubber feet of the 1645 fell off a while ago – both the ones on the base of the laptop and the ones fixed to the battery bar. The 15 has two rubber strips. Time will tell if they last longer.
My 1645 weighs 3.065kg. I’m pleased to see the 15 weighs only 2.040kg. (For those days when I need to carry it around, my back is also pleased!)
It’s not easy to show the difference in displays, but this gives you a bit of an idea of the 4K display of the 15 next to the standard 1080 of the 1645. It doesn’t show up here, but the 1645 screen also got quite scratched over the years from rubbing against the keyboard. Probably made worse from the extra rubber pads falling off that should have prevented this. I’m looking into getting a protective cloth for the new laptop to try and reduce the chance of that happening again.
And check out the disk performance – almost 10x faster with the PCIe SSD – nice!
Finally, I’d forgotten what it was like to have a battery that holds a decent amount of charge (the 1645 might say it has 1:45 left, but that’s pretty optimistic). I can sit on the sofa with the XPS 15 and it lasts the whole evening. Wow :-)