I just finished another course at school that involved studying an open-source application. I've gotten tired of studying Java and using Java tools, so I decided to try studying a .net project. Luckily I stumbled upon NDepend which is the most fully featured tool for studying .net code that I've seen to date.

In the past when I needed to do some kind of code analysis (usually generating DSM's and maybe taking a brief look at some metrics), Lutz Roeder's (I mean red-gate's) Reflector and its' various add-ins has been sufficient for me, and not to mention free. But I found these tools to be somewhat limiting when doing large amounts of analysis (the kind I don't typically get time to do at work!)

I've really enjoyed working on these code analysis projects in the past, but this was my favorite one yet. It was more enjoyable to me because I was working on a .net project, making it easier to see how I can directly apply this to my own work (while working on the Java projects does a good job of teaching the concepts involved, it is hard to apply them to my work without the tools). But it was also enjoyable because NDepend was such a joy to use (and I think I've just barely scratched the surface of what it can do).

NDepend can do all the things you'd expect from a code analysis tool. It does a good job creating DSM's, has very pretty visual displays of said DSM's, and provides quick access to code metrics. I especially like the mouse-over highlighting in the visual dependency graphs, which helps you to tell at a moments notice what depends on a class, what the class depends on, whether any cyclic dependencies are present, and a ballpark idea of how many dependencies exist. I haven't gotten into any of the .net or visual-studio specific features yet (but I am sure they will make life much easier).

My favorite feature (by far) in working on this project was its' "Code Query Language" (CQL). CQL is a SQL-like dialect that lets you write queries directly against your codebase. This allows you to get very quick answers to questions like "What classes in my assembly depend on FooClass?" or "How many classes have more than <insert arbitrary threshold here> Efferent Couplings?". So if you need to find out some information about your code, instead of compiling metrics and poring over the results, you only need to ask NDepend the question directly, and see the answer as fast as you can type. After using this feature for a month or two, I don't know how I could go back to living without it!

An example query would look something like this:

In a larger project, you can use the FROM clause to limit what you bring back to methods from a particular assembly or namespace, like so:

Another cool thing about CQL is the ability to add constraints. So you could set it up to be warned whenever you run analysis if you had a method with over 200 lines of code, or methods with excessive complexity and an insufficient number of comments. Here is an example of a constraint that ships with NDepend, meant to warn the user if any fields break encapsulation.

As I think these few examples show, this CQL is very intuitive, and I really recommend checking it out if you get a chance. Even being quite the SQL junkie myself, I found it hard to find anything to complain about. I especially liked the visual display of the query results. Basically in the NDepend window there is a rectangle filled with unevenly sized blocks. Each block represents a field or method (depending what you are looking at) and they form larger blocks representing types. The blocks can be sized based on different attributes like number of lines of code, or number of efferent couplings. Below is a screenshot (from NDepend's website) showing what this looks like:

When all is said and done, I've really come to love, and even depend on NDepend. I think it will be an indisposable part of my toolkit. What is scary about this is that I haven't even gotten started yet. I haven't used the build comparison feature that lets you watch how your assembly evolves over time (in the past, when I've used the Java tools, I needed to create a separate project for each, version, and compare manually, so I'm sure I will love this feature!). Another thing that I think is really cool is the fact that you can integrate the NDepend analysis with your build process, so you can be warned of violations of your established constraints in real time, not just whenever you get around to running another analysis. You can even embed the constraints in your source code! When I get into all these features I'll be sure to share.

*** If you have questions on C#, check out our C# Forum or even the ASP.net Forum

Microsoft has released IronPython 2.0 on CodePlex, the .NET implementation of the Python language. IronPython 2.0 is now running on top of the Dynamic Language Runtime (DLR).

From the release notes:

The IronPython and Dynamic Language Runtime teams are proud to announce the release of IronPython 2.0 final. IronPython 2.0 is the culmination of nearly two years worth of work resulting in a CPython 2.5 compatible release on .NET 2.0 SP1. By far, the biggest change to 2.0 is that our 1.1 codebase was refactored to run on top of the Dynamic Language Runtime. With this we automatically get improvements in many feature areas such as better .NET interop support and hosting Python from managed code. There have been many other major improvements as well. The most notable are:

• An MSI installer for Windows platforms which includes parts of the CPython 2.5 standard library
• IronPython assemblies targeting Silverlight and tools such as Chiron to improve the Silverlight dynamic development experience
• The addition of more C-based standard modules such as cmath and _winreg
• Significant improvements in importing compatibility and features
• Distribution of IronPython under the Microsoft Public License which has been approved by OSI
• Performance improvements. On that note, a new Wiki page has been created for IronPython performance reports - see http://www.codeplex.com/IronPython/Wiki/View.aspx?title=IronPython%20Performance
• Over 500 bugs have been closed in 2.0. 453 of these were reported on CodePlex
• Support for precompilation of Python source files into a single dll

Download IronPython 2.0 here http://www.codeplex.com/IronPython/Release/ProjectReleases.aspx?ReleaseId=8365#ReleaseFiles

CHESS is an automated tool from Microsoft Research for finding errors in multithreaded software by systematic exploration of thread schedules. It finds errors, such as data-races, deadlocks, hangs, and data-corruption induced access violations, that are extremely hard to find with current testing tools. Once CHESS locates an error, it provides a fully repeatable execution of the program leading to the error, thus greatly aiding the debugging process. In addition, CHESS provides a valuable and novel notion of test coverage suitable for multithreaded programs. CHESS can use existing concurrent test cases and is therefore easy to deploy. Both developers and testers should find CHESS useful.

More on Channel 9 (including video) http://channel9.msdn.com/shows/Going+Deep/CHESS-An-Automated-Concurrency-Testing-Tool/

Chris Shaw posted a new SQL Quiz where he asks: "What are the largest challenges that you have faced in your career and how did you overcome those?"

Denny Cherry (@mrdenny on twitter) tagged SQLDenis who tagged George who tagged Ted who then tagged me so here is my story:

And yeah I just copied the above from someone else's post and improved it a little. I hate these tagging things. But since George and Ted could kill me if I don't, I will anyway.

1) The Guid mistake.

When I redesigned my system and the accompanying database, I decided to use Guids all over the place. It's easier than integers because I don't have to wait on the database to give me an ID. And I'm one of those guys that thinks an object should get a proper ID. So I tested the new system and everything ran fine. But like George, I didn't test with a big enough dataset. And this one table has millions of rows and the primary key is on the guid because it has no other natural key, the two other fields are just nearly unique but can be the same. Anyway, a certain part of that system became slow and it was the part that, among others, pulled data from that table. 421 rows or multiples of that but never more then 10x421. And yet it was slow as hell. Loading a record with, among other things, the 421 rows took seconds, while it used to take less then a second on the old system. It took me a while to find out that the primary key and paging was the problem. With the Guid, the 421 rows were in several pages now (even 421 pages), so it had to do a lot more disk-IO. Changing to an int identity solved the problem because now all the rows fit in one page or two. Easily.

2) The nHibernate mystery.

For my school project, I had to write something and I decided to use some new stuff I didn't know yet. Well that's not entirely true. I knew the Java side of things because that was the main language we used at school and I decide to use all the same technologies but then the .Net versions. This was not fun since I could not get any help from the teacher and I got stuck several times, but I learned lots of neat stuff and I learned to read blogs from persons like Oren Eini, Jeremy Miller and Jeff Atwood; I never asked for help but found out most things by myself and although this was very frustrating it was very rewarding too. But the most frustrating was that nobody read the 400 page "book" I wrote and no-one ever looked at the 200,000 lines of code I wrote for this project. They just listened to the presentation and watched the demo and saw that it was good.

That's it, for the rest I'm perfect ;-).

I will also tag 2 LTD members for whom (among others) I have much respect AlexCuse and damber

Part 3

Like I said in my previous post, I am now going to talk about the difference in namespace and variable declaration.

• C# and VB.NET Comparison Cheat Sheet

Namespace or namespace

The only real difference between C# and VB.Net is the capitalization. VB.Net uses Namespace, while C# uses namespace.

By default C# will also always add the default namespace and the folderhierarchy, for example:

The default namespace can be found in the properties of your project, in the application tab.

When you leave out the namespace, you will find your classes in the default namespace.
The default namespace usually uses the same name as the project name but you can change it if you really want to.

In VB.Net, neither the namespace nor the folder hierarchy is added when you create a class. But you can have this behaviour when you add Resharper to your toolbox. Which you really should do.

When you do not provide a namespace, the class will go into the Root Namespace.

This is where you have a big difference between C# and VB.Net.

This with the default namespace set to C_Class_Library_1

and this with the root namespace set to VB_Class_Library_1

They do not yield the same result. In C#, the namespace will override the default namespace and thus you still write this.

In VB.Net, the namespace gets added to the root namespace and thus you end up with this.

You get the same namespace twice.
Remarkable.

Variable declaration

The following examples do exactly the same thing.

But watch out for inference in VB.Net. In C# 4.0, type inference is turned on by default and you can’t turn it off. In VB.Net 9.0, you can turn it off and it is turned off by default, if you upgrade your project from an earlier version.

There are two solutions to solving the inference problem in VB.Net.

First of all, let’s look at the error message you will get when it is turned off.

Of course, as good VB programmers, we have Option strict on.

We then get this error message on the lines without an “As".

Option Strict On requires all variable declarations to have an ‘As’ clause.

What if we turn Option Strict Off? Then we get rid of the error messages. But instead of inferring the type, it will just make the type of the declarations without a type default to Object. If on the other hand we turn on Option Strict and Option Infer, it will infer the type and Dim counter2 = 1 magically becomes of type Integer. However Dim Count = 5 doesn’t get inferred, so it only infers type inside method declarations when Option Infer and Option strict is on. I would have liked both On but I guess you will have to choose.

We only get the right result if we do this.

Which is very weird IMHO.

But we can also do all this at the project level so that we don’t have to repeat ourselves(DRY).

You can set them in the compile tab.

This ends part 4, next up, Types.