Vagif Abilov's blog on .NET

First look at NDepend 3.0

Vagif Abilov — Thu, 11 Mar 2010 22:20:46 GMT

I installed to today the latest version of NDepend and gave it a try. Last time I blogged about NDepend, I used it on a small solution, and while the generated report was full of useful information, I did not use the product at full strength, because as it’s name suggests, NDepend is about analyzing dependencies, and my solution was too small for interesting observations. This time I plan to analyze a large solution consisting of all of our projects with an exception of a Web administration projects that are not so interesting for such analysis. The solution file was generated using a utility described earlier and contains 140 projects. I never worked with such large solutions (usually I group projects in much smaller solutions), so I was a bit uncertain about how long it will take to load on my Dell D830 notebook. But it started up relatively quickly.

The biggest news about NDepend 3.0 is that it is now fully integrated into Visual Studio development environment. So now all its menus and windows are parts of development session, and windows of course can be docked.

The very first impression from NDepend: it’s fast, blazingly fast. As you can see from the summary below, it used only 18 seconds to analyze 1188 source files in 140 projects of my solutions: 15 milliseconds on each file.

So these are the metrics for my large solution, though I disagree with one detail: the report states that the solution has only 1 attribute class. Yes, it has only one class with .NET Attribute as its immediate parent, but there are several other classes that derive from Attribute, but not directly. One class derives from TypeMock.DecoratorAttribute that inherits from Attritbute. In addition there are several classes inheriting from PostSharp.Laos.OnMethodBoundaryAspect, and walking its inheritance tree brings us to MulticastAttribute that inherits from Attribute. I believe all such classes should be classified as attribute classes (since this is how they are used).

Enough with class attributes. I browsed the report and noticed that I’d like to change a few metrics’ parameters right away. For example, a list of too long type names included all types with names longer than 35 characters. While this seems to be a reasonable limit, some exclusions from such rule can also be reasonable. The top 10 entires in this list ended with either “Exception”, “Preset”, “Response” or “Request”. “Preset” is a suffix for a special category of classes that we use in tests, “Response”/”Request” are used in Web service communication, and “Exception” is of course a suffix for exceptions. I want to see classes with “really” long names, so how do I exclude these special classes from the rule?

It appeared to be very easy. I displayed a CQL Query Explorer and double-clicked on the rule. NDepend displayed a CQL Query Edit window, and it was obvious what I had to do to customize the rule. Below is an updated query:

The simplicity of rule customization encouraged me to start inspecting other report’s details. One of the most important ones was the list of methods to refactor. And it also had to be customized. Because this is what I saw:

Firstly, I think the table will look more informative if it highlights the figures that violates the metrics. Otherwise you have to browse every column and compare its data with the values from the respective CQL query. But what deserves customization is that the top of the list is occupied by class constructors with number of parameters exceeding recommended maximum (5). Should an exception be made for constructors? I believe it should, at least these days, when developers tend to use IoC containers and compose large applications with constructor injection. But how do I specify constructor exclusion? Luckily, I didn’t even have to browse NDepend online documentation - NDepend supports intellisense.

Exclusion constructors from the query resulted in much more interesting list of methods (below). They are candidates for refactoring for different reasons: number of lines, number of IL instructions, netsing deptsh, number of variables, etc. Again, I would appreciate if offending figures were highlighted.

It took me just minutes to apply these customizations, and what’s most encouraging is that I did not have to read anything about what these metrics are and how to adjust them to fit my needs: everything is intuitive, with additional explanation text shown along the queries and reports. I need more time to interpret metrics and diagrams related to dependencies – the solution is too big to give a simple picture. I leave it to a second look. To be continued…

Using “yield” to enumerate endless sequence

Vagif Abilov — Thu, 11 Mar 2010 09:41:09 GMT

Craig Andera in his blog post showed yet another Fibonacci algorithm, this one with “yeild” operator.

private IEnumerable Fibonacci()
{
    yield return 0;
    yield return 1;

    int a = 0;
    int b = 1;
    while (true)
    {
        int temp = a + b;
        a = b;
        b = temp;
        yield return b;
    }
}

Now it's possible to fetch Fibonacci numbers in this manner:

static void Main(string[] args)
{
    foreach (int a in Fibonacci())
    {
        Console.Write(a);
        Console.Write(" more (y/n)?");

        string more = Console.ReadLine();
        if (more.ToUpper() != "Y")
            break;
    }
}

As you can see, code in Main procedure uses “foreach” statement, but the Fibonacci sequence is endless, so it can’t be populated in advance. Without “yield” we would have to create a temporary state variable (actually two: to store “a” and “b”) and pass them to a GetNextFibonacci that would produce a next number and return updated “a” and “b”. But with yield it’s possible to compute results on demand.

NUnitForVS: integrating NUnit tests into Visual Studio

Vagif Abilov — Sat, 06 Mar 2010 20:23:45 GMT

Roy Osherove listed advantages of NUnit over MsTest but also mentioned one MsTest’s strength that can be crucial for many developers: “the integration with other team system tools and reporting is just beyond compare and the reporting alone helps alot to find recurring breaking tests, code churn vs. new tests and others”. This reminded me about what I recently read in a book by Jeff McWherter and Ben Hall Testing ASP.NET Web Applications where they said that forthcoming release of Visual Studio 2010 will make it possible to configure VS test runner to execute tests that use syntax different from MsTest.

I am a faithful user of TestDriven.Net, but I know that ability to use built-in Visual Studio test runner is an important factor that may affect the choice of unit test framework. So it would be nice to separate these decisions: selection of a unit test framework and selection of a test runner. I asked in Microsoft’s VS 2010 forum it new version of Visual Studio is really that flexible when it comes to configuring it’s test runner. Unfortunately not. Microsoft’s Euan Garden answered: “this was something we wanted to do in the release but never made it into the product.” However, Euan gave a couple of hints: Gallio and NUnit integration CodePlex project.

I checked CodePlex and found NUnitForVS: NUnit integration for Visual Studio 2008. I downloaded an ran the installer and within 5 minutes was able to make Visual Studio development environment to treat NUnit tests as they were native MsTest. The only preparation (in addition to installing NUnitForVS) was to open test project file in a text editor and add the following entry to the first PropertyGroup:

This has to be done to every test project that uses NUnit, but otherwise Visual Studio won’t be able to classify the project as a test project (why should it? – the only type of test projects that it natively recognizes is MsTest). After this change Visual Studio accepts NUnit tests, and you will see all your tests in the Test View window:

So far so good. Next checkpoint is to run and debug some of these tests. This also works well and test results are displayed in a respective window:

Note the very last test in this list, the one that is called “Add(2,3,5)”. This is a parameterized test implemented using TestCase attribute:

[TestCase(2, 3, 5)]
public void Add(int x, int y, int sum)
{
    Calculator calc = new Calculator();
    decimal result = calc.Add(x, y);
    Assert.AreEqual(sum, result, "Incorrect result");
}

So using NUnitForVS we can exploit features of NUnit 2.5 that don’t exist in MsTest, and still Visual Studio correctly treats them. This is good news.

When it comes to collecting code coverage, the situation is a little trickier. When I open code coverage window, I see not very encouraging message “Code Coverage is not enabled for this test run”:

Actually this is correct message: you have to explicitly enable code coverage instrumentation. But how? Apparently our solution sill lacks some piece, but luckily it’s easy to fix. All we need is to add a test configuration file with extension “testrunconfig”. Then we can activate its configuration and enable code coverage collection. One simple way to add such file is to add and then delete a test project to a solution (a “real” MsTest project). The MsTest project will be gone but will a trace in a form of test configuration file:

If you now enable code coverage instrumentation for assemblies in your solution and rerun the tests, you will see the coverate summary:

Pretty useless, isn’t it? The summary displays coverage only for the test assembly and not for the actual code under test. Why?

More googling, and the explanation came from Peter Stephen’s blog post: even though coverage instrumentation is enabled for all assemblies in our solution, one of assemblies was taken from a wrong place: the assembly under the test lies both in its own “bin” folder and in the “bin” folder of the test assembly, and it is there it has to be taken from. To resolve the problem you just need to add the assembly from a right place:

Note 2 copies of UnitTestDemo.dll. The unchecked one is the one that was added initially, the checked one was added manually. And everything works:

Of course, I only tried NUnitForVS on a very simple project. I plan to check it out with more complex code. But so far it looks quite promising opening Visual Studio test runner for NUnit - the most popular unit test framework.

Fluent object construction

Vagif Abilov — Wed, 17 Feb 2010 12:13:59 GMT

I like an idea to replace constructor overloads that take optional parameters with more fluent approach, so there will be less (and easier for understanding) constructor overloads and more readable code. Perhaps also more writeable.

Let’s take an example, well-known StreamWriter. It has the following constructors:

public StreamWriter(Stream stream);
public StreamWriter(string path);
public StreamWriter(Stream stream, Encoding encoding);
public StreamWriter(string path, bool append);
public StreamWriter(Stream stream, Encoding encoding, int bufferSize);
public StreamWriter(string path, bool append, Encoding encoding);
public StreamWriter(string path, bool append, Encoding encoding, int bufferSize);

Stream and path parameters are mutually exclusive and one of them must be sent to a constructor, other parameters (encoding, append and bufferSize) are optional, and append flag can only be used together with the path. There are in total 8 constructor overloads, and they don’t cover all possible valid combination: there is no overload that only takes path, encoding and bufferSize (you will have to send append flag too).

What if this class had fewer constructors but provided additional methods to enrich stream writer setup? Like this:

public class FluentStreamWriter
{
    public Encoding Encoding { get; private set; }
    public int BufferSize { get; private set; }

    public FluentStreamWriter(Stream stream) { }
    public FluentStreamWriter(string path) { }
    public FluentStreamWriter(string path, bool append) { }

    public FluentStreamWriter With(Encoding encoding, int bufferSize) { this.Encoding = encoding; this.BufferSize = bufferSize; return this; }
    public FluentStreamWriter WithEncoding(Encoding encoding) { this.Encoding = encoding; return this; }
    public FluentStreamWriter WithBufferSize(int bufferSize) { this.BufferSize = bufferSize; return this; }
}

And the code using classic and fluently constructed stream writer would look like this:

var writer1 = new StreamWriter("temp.txt", false, Encoding.UTF8);
var writer2 = new StreamWriter("temp.txt", true, Encoding.UTF8, 1000);

var writer3 = new FluentStreamWriter("temp.txt").With(Encoding.UTF8, 1000);
var writer4 = new FluentStreamWriter("temp.txt").WithEncoding(Encoding.UTF8);
var writer5 = new FluentStreamWriter("temp.txt").WithEncoding(Encoding.UTF8).WithBufferSize(1000);

What I like in this approach is the separation between mandatory and optional set of constuctor arguments: what is sent to the constructor is mandatory (either individual parameters or set of mutually exclusive parameters). Everything that is optional may be added using methods prefixed with “With” that return the same class instance.

The drawback of this approach is that since it moves some object construction options to custom methods, they can be overlooked by developers that are not aware of API style and may conclude that object construction possibilities are limited by the list of constructor overloads. So perhaps this approach is not suitable for a small API where fluent construction will be the only deviation from traditional type design style. But in large frameworks with fluent API style it can feel natural and be easily accepted.

Time to buy ReSharper?

Vagif Abilov — Tue, 19 Jan 2010 14:32:20 GMT

Today I spent a few hours on mysterious error. One automated test failed, and since it was actually an integration test with complex setup, tracking down the failure was not easy. The problem that I’ve eventually found can be illustrated with a couple of tests:

[Test]
public void BadClosureTest()
{
    int[] numbers = new int[]
    {
        1, 2, 3
    };

    List> functions = new List>();
    foreach (int n in numbers)
    {
        functions.Add(new Func(() => n));
    }

    // Will fail on first assertion!
    Assert.That(functions[0].DynamicInvoke(), Is.EqualTo(1));
    Assert.That(functions[1].DynamicInvoke(), Is.EqualTo(2));
    Assert.That(functions[2].DynamicInvoke(), Is.EqualTo(3));
}

[Test]
public void GoodClosureTest()
{
    int[] numbers = new int[]
    {
        1, 2, 3
    };

    List> functions = new List>();
    foreach (int n in numbers)
    {
        int m = n;
        functions.Add(new Func(() => m));
    }

    Assert.That(functions[0].DynamicInvoke(), Is.EqualTo(1));
    Assert.That(functions[1].DynamicInvoke(), Is.EqualTo(2));
    Assert.That(functions[2].DynamicInvoke(), Is.EqualTo(3));
}

As you can see, the only difference between these tests is a line in the second test assigning iterator “n” to a variable “m” defined within the “foreach” scope. Why does this matter?

Well, for us, procedural languages veterans the difference may be not so obvious at first glance. But if you happen to have ReSharper, it will immediately give you a warning about the first test: “Access to modified closure”. And will suggest to copy “n” to a local variable. I didn’t have ReSharper, so I came to the same conclusion in a hard way.

A lambda-expression “() => n” is not just a delegate – it’s a closure. It uses a variable that is defined outside its scope. Such variables are always treated by reference, even though they may be of a value type. So as long as the variable “n” lives, any changes applied to it will affect every closure where it is referenced.

And apparently ReSharper can warn us about improper use of closures.

By the way, if instead of “foreach” test had a “for” loop with an index, the first test would fail with IndexOutOfRangeException. Because closures were accessed after the array elements are iterated and index would be set to 3.

Programmer’s calendar for 2010

Vagif Abilov — Tue, 19 Jan 2010 13:46:23 GMT

Don’t know who made it, but holidays hint me that it comes from Russia.

WCF and large hierarchical data

Vagif Abilov — Thu, 14 Jan 2010 18:44:03 GMT

If you need to send large amount of information using a single WCF call, you will need to customize binding configuration that is by default tuned for efficient transfer of small messages. And if your data contracts happen to have types with circular (or self-) references, this behavior needs to be configured too. Here what I had to tweak in order to enable transfer of very large (up to 100 MB) collections of hierarchical data.

1. Binding configuration

The following binding attribute may need adjustments:

maxBufferSize
maxBufferPoolSize
maxReceivedMessageSize
openTimeout
closeTimeout
sendTimeout
receiveTimeout

Binding element has “readerQuotas” sub-element where the following attributes may be tweaked for large amount of data transfer:

maxDepth
maxStringContentLength
maxArrayLength
maxBytesPerRead
maxNameTableCharCount

In addition, transferMode can be set to either “Buffered” or “Streamed” depending on how data should be received by the client.

2. Behavior configuration

In case large amount of data are sent as standard collections (arrays, lists etc.), no behavior customization is needed in order to increase data transfer limits. But if the data represent more complex topology, there is an additional attribute to adjust, and this attribute belongs to behavior, not binding. It is called “maxItemsInObjectGraph” and can be specified either on serviceBehavior or endpointBehavior level. The customize behaviors element may look like this:

<behaviors>
	<servicebehaviors>
		<behavior name="LargeTreeBehavior">
			<servicedebug includeexceptiondetailinfaults="true" />
			<datacontractserializer maxitemsinobjectgraph="2147483647" />
		</behavior>
	</servicebehaviors>
	<endpointbehaviors>
		<behavior name="HighlightBehaviorLarge">
			<datacontractserializer maxitemsinobjectgraph="2147483647" />
		</behavior>
	</endpointbehaviors>
</behaviors>

3. Serialization of object graphs with circular references

.NET 3.5 SP1 introduced a new attribute IsReference that can be used with DataContracts to enable serialization of object graphs with circular references. Previously it was not possible without writing custom code. Now it requires only a single attribute specification:

[DataContract(IsReference = true)]
public class Node
{
	[DataMember]
	Node Parent { get; set; }
	....
}

That should be it. Now you can send graphs with millions of nodes over the wire using WCF. In may cases sending so much data in a single call is not a good idea, but that’s another topic.

When NUnit stops working on a build machine…

Vagif Abilov — Thu, 10 Dec 2009 12:13:58 GMT

… then it’s time to check the registry entries. Make sure you see something like this:

In case the build runs in the context of a dedicated user, not the one who logs on to a build machine and install applications, then it is likely that the build user does not have correct setup for NUnit assemblies. You can of course import missing registry entries into that user registry part, but the best is just to create them for everyone under LOCAL_MACHINE folder using path \HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\AssemblyFolderEx.

Utility to generate solution files can now create solution folders

Vagif Abilov — Thu, 03 Dec 2009 10:10:00 GMT

If somebody wants more from the program you wrote, it’s a good sign. It means that at last you did something useful :-)

Recently my colleague mentioned that the utility that I wrote to generate project solution file should support creation of solution folders. Our development team has in total more than 200 projects, and grouping them within the solution makes a lot of sense.

So I extended the tool, and you can specify number of solution folder levels using “/l” command line switch.

GenerateSolutionFile /p <path> /s <solution> [/i includeFilter] [/e excludeFilter] [/l [*]solutionFolderLevels]

You can specify solution folder levels using an integer number – project names will be split using “.” as separator, and resulting words will be used as solution folder names. Since it’s a good practice to start project name with a name of the company that won’t be useful as a solution folder, it’s possible to skip common project prefix by using an asterisk letter in front of the number specifying the number of levels.

Here are a few examples. If you generate solution file without instructing the tool to create solution folders, you will get a flat structure of projects:

If you add a command line switch “/l 1”, then the program will extract a first word from compound project names and create a root solution folder:

You can add number of levels with “/l 2” switch:

To skip “MyCompany” from solution folder tree add an asterisk when specifying number of folder levels: “/l *1”:

And of course you can increase number of levels, here’s how it looks when using “/l *2” switch:

Enjoy!

A danger of being too clever

Vagif Abilov — Tue, 10 Nov 2009 14:34:04 GMT

A friend of mine applied for a job and received a test task to write an application that should be using a singleton. He decided to follow the fourth approach among the ones listed here (“not quite as lazy, but thread-safe without using locks”). I also think that this is most elegant although .NET-specific singleton implementation. Yes, it is not as lazy as other alternatives, but it is lock-free, and I’d always go for minimalistic code first and make it more complex later based on additional requirements.

Unfortunately, my friend’s suggestion has been rejected. And one of the reasons: “not thread-safe singleton”. I guess the guy who verified the code was looking for locks and refused to believe that code can be made thread-safe without using them. The suggested solution was just too clever for him.

So my friend was not hired, but I said to him that he should not regret. I am not sure I’d personally enjoy working for somebody so fixated on his own decisions. Still there may be a lesson learned from such failure. Perhaps when presenting our solutions to others we should evaluate if they can be unexpected for those who is going to review them, and in case of such risk add a brief explanation about why we made our choice and what other alternatives could be considered.

Expression tree serialization

Vagif Abilov — Thu, 29 Oct 2009 20:16:30 GMT

Serializing lambda expressions using MetaLinq, by Onur Gumus.

Remoting lambda expressions, by Casey Marshall.

Expression tree serialization project.

Selecting IoC framework

Vagif Abilov — Tue, 27 Oct 2009 09:10:04 GMT

No, I haven’t chosen one to use yet. But I kind of feel that instead of investing more time in home-made and fairly inefficient DI classes, I should rewire the code to use one of the available IoC frameworks. And here are some blog posts that can help to make a choice.

Comparing .NET DI (IoC) Frameworks (part1 and part2) by Andrey Shchekin. Very good comparison with source code uploaded to Google Code.

IoC libraries compared by Chirs Brandsma. Focuses on most common case - constructor injection. Source code is also available.

Having read these two posts, I’d probably go with either StructureMap or Autofac. But I would also like to have a closer look at MEF that was not covered in these blog posts (I guess because it’s not a pure IoC container). Here’s an excellent Ayende’s post explaining why.

.NET mocking framework comparison

Vagif Abilov — Wed, 14 Oct 2009 14:03:21 GMT

A couple of good sources for those who need to decide:

Capability comparison made by Morgan Soley. Half year old but with a feature comparison table.

Recently updated comparison by Andrew Kazyrevich.

TypeMock Isolator is a clear winner if it fits in your budget. Otherwise Rhino Mocks or Moq seem to be the most mature frameworks. According to a recent Roy Osherove’s pole they are in the lead with Rhino Mocks having 47% and Moq on second place with 34%. If I had to choose a free mocking framework today, I’d probably go with Moq because of Rhino Mocks’ confusing “very large array of syntaxes”. Or wait for Rhino Mocks 4.0 that will be radically simplified and, like Isolator, will go for AAA abd single “fake” concept.

But for mocking without severe limitations there is no alternative to Isolator. Still in the lead.

Twitter Geek Quiz with TypeMock

Vagif Abilov — Mon, 12 Oct 2009 23:04:57 GMT

I am kind of slow with adoption of communication channels. But motivation works sometimes. Perhaps Twitter Geek Quiz that TypeMock is arranging this Wednesday can help me retraining my Twitter skills.

There will be prizes (from WiFi-detecting T-shirt to XBox), and to join is just to tweet any message with the quiz's hash tag – #GeekQuiz. Rules are listed here.

Functional programming for C# developers

Vagif Abilov — Mon, 12 Oct 2009 21:23:35 GMT

Latest Jeremy Miller’s article in MSDN Magazine will be very helpful for C# developers who haven’t started yet exploring functional programming. What is good about this article is that it gives practical advices on how to inject some fairly small pieces of functional programming into existing C# code in order to make it better – for example by removing code duplicates.

What seems to be radical for many C# developers is how functional programming handles blocks of code with variables that are not resolved within those blocks – closures. A piece of code with variables defined somewhere else is traditionally viewed by programmers with background in procedural languages as an invalid construction that will cause a compiler error. But closures are fully supported now in C# (in form of anonymous delegates or lambda-expressions), and Jeremy’s article demonstrates advantages of using this technique to pass around code blocks as data.

I think however that the example with ConnectedSystemConsumer could be presented somewhat simpler, without focus on Interface Segregation Principle. Here’s how the original class looks before refactoring:

class ConnectedSystemConsumer
{
    private readonly IConnectedResource _resource;

    public ConnectedSystemConsumer(IConnectedResource resource)
    {
        _resource = resource;
    }

    public void ManipulateConnectedResource()
    {
        try
        {
            // First, you have to open a connection
            _resource.Open();
            // Now, manipulate the connected system
            _resource.Update(buildUpdateMessage());
        }
        finally
        {
            _resource.Close();
        }
    }

    // The rest of the class is skipped
}

The article then introduces two new interfaces and one class: IResourceInvocation, IResource and Resource, where IResourceInvocation contains the “interesting” part of IConnectedResource (methods FetchData and Update) and IResource defines and Resource implements a single method Invoke that takes care of all ceremony stuff. While this helps splitting the original ConnectedSystemConsumer class into smaller logical blocks, for developer doing his first experiments with functional programming it may leave false impression that adding additional classes are required (or at least expected) steps to take advantage of functional programming in C# code. But the same effect can be achieved without adding new interfaces or classes, just by extracting all ceremony code in a separate method:

class ConnectedSystemConsumer
{
    private readonly IConnectedResource _resource;

    public ConnectedSystemConsumer(IConnectedResource resource)
    {
        _resource = resource;
    }

    public void ManipulateConnectedResource()
    {
        InvokeResource(x =>
        {
            x.Update(buildUpdateMessage());
        });
    }

    private void InvokeResource(Action<IConnectedResource> action)
    {
        try
        {
            // First, you have to open a connection
            _resource.Open();
            // Now, manipulate the connected system
            action(_resource);
        }
        finally
        {
            _resource.Close();
        }
    }

    // The rest of the class is skipped
}

As you can see, ManipulateConnectedResource no longer contains ceremonial code that opens and closes resource and handles exceptions. This code is now moved to InvokeResource method that takes as an argument a block or a closure defined in ManipulateConnectedResource or any other method that requires the same ceremony.

After reading Jeremy Miller’s article I browsed some of my old code and found several classes that can be simplified using the same approach. Perhaps at first they will not look simpler – functional programming style adoption requires some time. But they will become more compact, with less or without code repetition, and this alone is worth it.