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.