Using NDepend as an alternative to the Layered Diagram

I have used the trial version of NDepend now on several occasions. In general I use it to get a quick overview of large code bases that I am trying to grasp or I use it as a first step in code reviews. It is an amazing tool.

The latest version 4 includes default rules for validating architectures:

image

This kind of rule can also be validated by the Visual Studio layered diagram. But not everybody owns Visual Studio Premium or Ultimate . You need Ultimate to create the diagrams but you can validate using Premium. With $11.000 for ultimate, $9000 for Premium and $400 for NDepend, NDepend is a cheaper alternative for validating your code against this kind of rule

What I like about the layered diagram is:

  • It is easy to setup
  • It is also a nice way to visualize the layers in your application and their dependencies.
  • With a hack you can validate you code against your architecture every time you compile
  • It is easily included as a build step in TFS build.

So let’s look at how NDepend v4.0 does compare on these points.

Easy to setup.

I already had a project in which I used the layered diagram. For setting up NDepend, I started by adding a new NDepend project to this solution:

image

After clicking another Ok I was up and running NDepend. That was pretty easy. You do get a lot of extras when doing this, another dialog in which you can choose to visualize the code or to explore the validation rules. Default the rules are validated on several triggers.

image

Visualizing application architecture.

The Layered Diagram gives me the following overview, which I like a lot. It not only gives me a certain understanding but also a way of communicating with team members and other technical stakeholders. image

The layered diagram also gives the ability to group a number of projects and draw a single dependency for all projects inside of that group, E.g. in the previous diagram the LayeredSample.Services.PortalUpdatBatch group contains four projects any one of these projects has a dependency on the layeredSample.Core group so instead of drawing eight dependencies, this is shown by a single arrow between the two groups. This is a good thing because the diagram is kept readable. This is a bad thing because observers might miss the fact that there are a lot more dependencies.

NDepend gives a number of useful diagrams out of the box. The Dependency Graph comes closest to what I like.

image

The extra info you get when hover over the projects like file location, lines of code and lines of comments is great. Also the fact that you can make the size of the boxes and lines depend on code metrics like lines of code is pretty useful.

What I don’t like is the fact that you can’t save the layout of a diagram, yes you can save it as a picture but I really would like to be able to save which assemblies I have selected and the position they are placed at. As it is now, changing what the box size depends on, redraws my diagram and replaces all the assemblies that I threw away. That is really annoying, (Patrick Smacchia told me there are plans to fix this in the near future)

Validate at compile time

To do any of the architectural validation at compile time we want, we have to write custom CQLinq queries. I had not written any CQLinq queries before but with the online default rules as samples, the intellisense and the design time compilation it was pretty easy to setup the rules I wanted.  For example I wanted only the Core.Configuration project to call the System.Configuration assembly :

//<Name>System.Configuration Should only be referenced by Core.Configuration</Name>
warnif count > 0

from a in Application.Assemblies.Where(x => x.Name != ("LayeredSample.Core.Configuration") && x.IsUsing ("System.Configuration".MatchAssembly()) )

select new { a, a.Name }

I also wanted none of the Core Assemblies to reference any of the service assemblies.

// <Name>Core assemblies should not reference any of the service assamblys</Name>
warnif count > 0

from a in Application.Assemblies.Where(x => x.Name.Contains("LayeredSample.Core") && x.AssembliesUsed.Any(y => y.Name.Contains("LayeredSample.Services")))

select new { a, a.Name, a.AssembliesUsed }

Rules for single dependencies you want to ensure or forbid are made very easily by opening the dependency matrix, clicking with the right mouse button on any dependency  and selecting “Generate a code rule from this”

image

Marking a rule as a critical rule makes the NDepend indicator turn red when it is violated during compilation. It is only too bad that Visual Studio still reports that the build has succeeded even after breaking critical rules. I could find no way to accomplish the build to fail with a local build.

The rules I have build here for NDepend as well as the Layered Diagram are very solution specific. For every project they would have to be created again. NDepend does give you the ability to create more generic rules that you can use over multiple solutions, for details read “Validating Architecture through LINQ query”. Also the out of the box generic rules like “UI should not use DAL” and “Avoid namespaces dependency cycles” are very useful and don’t require any custom code at all.

Including NDepend in the TFS Build.

My first step into integration NDepend into TFS was a bit disappointing.  Looking at the documentation at NDepend it only showed not very detailed steps for integration into TFS2008 and TFS2010, I want to use TFS2012 or TFS Service. Also the recommended way for integrating with TFS2010 is a codeplex project with version 0.5.0 beta 1, not very promising.

But since the documentation for TFS 2010 states that adding a single build step that executes Ndepend.Console.exe with the proper parameters should do the trick it should be possible to do the same for TFS Service or TFS2012. I tried it for both.

  • started by creating a team project and adding my sources to this project. Next step was to create a new build definition with a new process template based on the default process template.
  • Next step was adding a folder to my project called lib\build, placing NDepend complete in that folder and adding this to source control.
  • Added the Ndeped .ndproj file to source control.
  • After that added an InvokeProcess activity to my new build template in the …. section. Based on this post and this post. And calling the NDepend.Console.exe with the parameters described in the NDepend documentation I got it to work with a lot of trial an error

image

image

 

Invoke Process properties:

Property Value
Arguments SourcesDirectory + "\Source\PortalUpdateBatchUltimate.ndproj /OutDir " + BinariesDirectory + "\NDepend /InDirs " + BinariesDirectory + " /silent"
FileName SourcesDirectory + "\Source\lib\build\NDepend.Console.exe"
Result ExitCode
WorkingDirectory SourcesDirectory

Conclusion

NDepend is an amazing tool and in this blog post I don’t do justice to all it can do by just comparing it to the “Layered Diagram”. If you want to quickly get a feeling for an existing code base, or when you do want to de reviews or if you want to keep on ongoing eye on the quality of the code base NDepend is a tool you definitely want in your tool belt.

If I get to a project that has Visual Studio Premium or Ultimate I will be using the Layered Diagram for this kind of validation, it is just too easy to use and the visualization and validations are adequate for the job. This does not mean that there is no room for NDepend, it still offers enough other added value.

In a project without Visual Studio Premium or Ultimate but with an NDepend license I will use it for these kind of architectural validations.

In a single project without Visual Studio Premium or Ultimate and without an NDepend license I don’t think that the architectural validation on it self is enough to buy NDepend . I do think that in any organization there should be a few licenses present that can be used for multiple projects to keep the code quality up to standards.

This post was inspired by this programmers exchange question and the free nDepend version I got from Patrick Smacchia.

References:

About Kees Dijk

Husband, father and Software Architect at Sogeti. Loving my work and having fun while doing it. Interested in all the aspects of software development with a special love for Model Driven Development, Code Generation and Software production lines.

Published by

KeesDijk

Husband, father and Software Architect at Sogeti. Loving my work and having fun while doing it. Interested in all the aspects of software development with a special love for Model Driven Development, Code Generation and Software production lines.

Leave a Reply

Your email address will not be published. Required fields are marked *