Catel and NDepend 6

As you might have read before on my blog, I am a happy user of NDepend. It gives you insights in your code that you as a developer has never thought of. We are always too busy getting that next feature built in that we hardly have time to write our unit tests. That moves having time to analyze our code even further away from reality.

Build server integration

One of the features of NDepend 6 that I like is that it can automatically check the quality of the code after each build. But what I was missing was real build server integration. It still required me to open up NDepend and analyze the assemblies manually. With the new version, build server integration has been implemented so this is really nice! Even users that are not running NDepend on their machines (but are contributing) can see the results because of the build server integration.

NDepend versus ReSharper

I also heavily use ReSharper. This doesn’t mean you can stop using NDepend. Where ReSharper gives you a lot of information during software development (and helps you refactor stuff), NDepend gives you a nice (graphical!) overview of your code quality. For example, it tells me about potentially dead methods:

image

And besides the full solution analysis, it can also be integrated into Visual Studio and directly show you the results of the whole solution!

How does this all relate to Catel

You might be thinking: why reference Catel in the title. Catel is a very large solution (over 100 projects) and for me it’s the ultimate test for NDepend. Every software package can be used on simple projects, but even ReSharper starts hicking up with Catel. NDepend has no issues with analyzing the big solution though, and it does help me manage the complexity of the solution.

So every time you are using Catel, part of the quality is powered by NDepend. If you think NDepend might be able to help you out as well, take 5 minutes to watch the tour video.

Introducing ContinuaInit – initialize your build server variables

I am using Continua CI as a continuous integration server. One of the things I always do is to try and mainsteam all the configurations so I know what is happening for each product. However, I always found myself doing a lot of if/else to determine the state of a build:

image

The advantage of these variables is that I can implement logic inside a configuration based on whether the build is a CI build and whether it is an official build. My goal was to replace this whole tree by a single call to an executable that contains rules to determine variables and init them all.

The result is ContinuaInit. You can replace the whole tree by the Execute Program action and call ContinuaInit.exe. That will result in a much cleaner initialization:

image

What initialization is supported?

For now, it supports the following rules:

PublishType

If the branch is master, the PublishType will be set to Official. Otherwise the PublishType will be set to Nightly.

IsOfficialBuild

true if the branch master, otherwise false

IsCiBuild

true if the branch does not equal master, otherwise false

DisplayVersion

Will be set to the version provided by the command line. Then it will apply one of the following values:

nightly => when nightly build

ci => when CI build

How can you get it?

ContinuaInit is available on both NuGet and Chocolatey.

Using NDepend v5 on Catel

It’s been quite a while since I have given NDepend a spin on Catel. Catel is a good project to test-drive such a product because it contains a huge code-base and supports various different platforms (WPF, Silverlight, Windows Phone, WinRT, Xamarin.Android and Xamarin.iOS). Today I will give the latest version of NDepend a spin.

Upgrading from v4 to v5

Though normally moving from v4 => v5 introduces breaking changes and maybe even a new project structure, the update went very well. It recognized my “old” v4 project file without having to run some sort of transformation wizard. The first thing I noticed was the new look and feel of the software. They skipped the “black & white metro look” of Visual Studio 2012 theme and immediately went for the much better “colorized metro look” of Visual Studio 2013:

image

First things first

Normal people would read the manual and carefully provide the right input on the product. I decided not to follow the normal way because I like to do things differently (whether that is good or bad is up to you). I made so many changes to the upcoming Catel 4.0 release that I decided to simply plug in all the NET 4.5 assemblies of the core and all available extensions (up to 15 assemblies at the time of writing). Then I simply ran the project and it came up with this dashboard:

image

Luckily I didn’t violate any critical rules so that is a good thing Smile.

In-depth verification of rules

One of the rules is that the code might be poorly documented. The reason for this is that it checks the lines of code (LoC) against the documentation length. Though this method works in most cases, some methods are allowed to be long because splitting them would make no sense.

Another great feature that NDepend provides is detecting dead code. It checks all types and type members and will inform you when it can see dead code. As you probably know, I am a big fan of Fody, a great way to weave code into your assemblies. One of the artifacts of Fody is an interface called ProcessedByFody. This interface is injected to ensure that an assembly won’t be handled twice by Fody. However, NDepend sees that as dead code. I could simply modify the LINQ query at the left top by adding an additional check:

image

Conclusion

NDepend v5 is a solid improvement of an already great product. It makes the software easier to work with. Even though the tooling is nice, I want to spend as less time as possible inside it. It is a great way of automated code-reviewing which nearly all developers I know tend to forget. At first it requires some setup and configuration, but after that you can easily verify the code.

It is always good to have your code reviewed, even though you think are you are very skilled developer. Whether it is automated by a tool (such as NDepend) or by a co-worker is up to you. I prefer a tool because it saves my co-worker time + my co-workers are human beings and can make the same mistakes I make. Tools normally aren’t influenced by a bad day Winking smile.

What’s next in the future?

In the future I hope to add the NDepend analysis to my automated builds with Continua CI to see what comes out of it. The reports can be added to the build artifacts in Continua CI. Then I can break the build when there are warnings and I have two options:

1) Change the configuration if I think the code is correct
2) Change the code if I think the code is incorrect

But that is another blog post, another time!