Another geek blog.

Category Archives: C#

Recently I started out exploringNDepend. After looking into the basic stuff I wanted to explore the comparison features. Being able to report on how the quality of your code base changes over time would be very nice. Luckily, NDepend lets you do this very easily.

Let us assume you have already set up an NDepend project and finished your first analysis. I included not only the assemblies I wanted to be analyzed but also added a dotCover code coverage report (thus being able to track code coverage as well). Under Project Properties you choose the analysis result as Baseline for Comparison:

Once you have done that you sit back and wait for your code base to change. I waited a few days and luckily it did! I re-built the assemblies (which are referenced in the NDepend project so I did not re-include them) and also created another code coverage report. After that you just run a new analysis and the dashboard, in addition to giving you a brief overview of the analysis, now shows some interesting details about what changes have taken place:

In my case it informed me about:

increased number of lines of code, namespaces, types, methods etc.

a slight increase in average method complexity

about a decreased code coverage (I have more lines of code covered now but more uncovered lines of code were also added)

new rule violations

When I looked at the rule violation results there was an interesting category named API Breaking Changes. It informed me about possible problems because some public interfaces had been changed. It marked them as critical which I do not think they are (still have to find some way of ignoring certain rules). If you develop a closed product and you are analyzing all there is to it, it should not pose a problem. Would I be developing a framework that others are using, then I can see the point. NDepend has no way of knowing. But there were also some rules in there which were clearer like the one checking for changes to serializable types.

So the comparison feature is really nice. I guess if you do this analysis frequently and observe the results over time, NDepend can give you both

a meaningful and quick impression of your code base changes to the better or worse as well as

tools to find out more about the areas where the problems grew or shrank that are important to you.

I got my hands on a copy of NDepend. Don’t worry, it is a legitimate professional license… NDepend is a .NET code analysis tool that offers a lot of metrics and information on your code base. Here are some of my first impressions.

It starts out easy enough. You have the choice of using it from Visual Studio (it comes with an AddIn installer), from the command line (for analysis during automated builds, I guess) or from a standalone desktop application. I chose the desktop application and was prompted to specify the code base. It analyses assemblies and you have multiple ways of importing them, including some wizards. This is were it started to get tricky because the wizardry did not work that well so I had to import the DLL’s by hand. This is a tool for the sophisticated developer and it shows already at the beginning. After I imported the main assemblies of a project I am working on, I generated my first report.

Here are a few items from the report.

I have seen NDepend before and the thing that scared me then and still scares me now is a thing called Treemap Metric View (which is presented very prominently):

It is supposed to provide you with a single visual on the complexity and state of your code base. The report provides a few other visuals on relationships between namespaces and assemblies which are nice but overly complex and too much 10000 foot view.

The main part of the report consist of results of checks applied to your code base. Don’t freak out: You will see a lot of rule violations! If you can understand it for what it is supposed to be, fine. These rules represent opinions. But they have been found to be very helpful by a lot of developers over a long period of time and thus might have become hard facts. Here are a few examples.

There is this critical warning called Types too big of which the tool found two violations, both being around 800 lines of code long. It is common knowledge that big types should be broken down into parts that each are small and ideally just do one thing. It makes your components way more maintainable and reusable but the main advantage is increased readability, in my opinion. So good job, NDepend! There are many other useful rules, like Methods that could have a lower visibility.

Some rules are debatable, especially ones that are declared as Critical but only in the eye of the beholder. Yes, it is not good to have a violation of the rule Potentially dead Methods, but should it be critical? Who out there does not have unused methods or types sitting around waiting to be reenacted? An interesting one is Constructors of abstract classes should be declared as protected or private. I agree and my Resharper lets me change that in a heartbeat but is it critical issue? Rules come with some sort of source code example of the rule alogorithm which also shows comments so that you can learn more about the rule. In this case it it says the very fact is of a public constructor in an abstract class is useless. Useless is not critical, at least not to me.

I think there is a dilemma here. You need to be a sophisticated developer to correctly use and interpret NDepend. But the very fact that you are of such advanced state means that you already know what you are doing wrong and what you are doing right. The bad developer will get way more violations but does that point him in the right direction? Does that change him?

I like the tool. It gives me something so that I can get into an informed discussion about the state of my code.

Things I would like to check out in the future:

Baselining. Even if you do not buy into some of the rules and metrics you can see your code base evolving.

Introduction

Recently, I was asked to look into a .NET push-capable network messaging framework at work. We already had an in-process system working that helped us monitoring progress on long-running processes (using IObservable/IObserver). This just needed to be improved so that you could listen to updates from outside processes.

Naturally, I looked into SignalR. But we wanted to be able to do server-side message filtering (for instance, to have a central messaging server but only receive updates on certain long-running processes in a given listener application). And maybe also have LINQ-capable filtering. Core SignalR does not bring these things to the table. But I found Pushqa which uses SignalR under the hood and adds the functionality we were looking for. Pushqa introduces itself the following way:

Pushqa is a .Net library that allows the filtering of incoming push events from a server to be performed server-side.

It allows the consumer to define queries over event streams so that events that are being emitted server side can be filtered and constrained by client side code. The queries are serialized and executed server side rather than sending all the events to the client for client side filtering.

Pushqa uses Microsoft’s Reactive Extensions (Rx) expressions over an HTTP connection with the queries serialized using the oData URI specification.

A Pushqa service at this point is designed to be working within an ASP.NET MVC web application (see Pushqa website or this blog post for examples). This was not the kind of environment I was looking for. SignalR itself is not limited in this regard so I went looking for a way to create a self-hosting setup for Pushqa (the full source code for the following demo can be found here: https://dl.dropboxusercontent.com/u/31759146/ProgressUpdate.zip).

Service

I created a simple console application that uses in-process OWIN hosting. It uses the following NuGet packages:

The Pushqa connection needs a context in which we define the observable property that clients want to access. For this demo I am simply using a Subject (which implements both IObservable and IObserver) into which my demo service puts messages into while running:

Listener

For the client I also created a simple console application. It mainly uses the Pushqa.Client NuGet package. The client takes a long-running process’ ID and uses it to filter messages by this ID. It is also just interested in the next 10 messages. This filtering is all done server-side! This is great because now you can have a ton of messages going through the service but only the interesting ones actually get sent to clients. For comfortable client-side filtering and processing you can use Reactive Extensions.

Conclusion

You can now start a service and have multiple listeners being updated in a push-manner and using the comfortable IObservable/IObserver pattern! The service is hosted in a simple console application (which at this point is not officially supported by Pushqa) and the message filtering can be done server-side!

I am not totally happy with Pushqa, though… Here is why:

It uses a LINQ-like interface but it is not LINQ! You have simple functionality like Where and Take but you cannot use the full LINQ spectrum.

Not many LINQ expressions are supported. For instance, a simple Where(() => true) is not supported!

I would have expected Pushqa using some official OData library (ODataLib?) to do the OData plumbing but it relies on its own implementation.