I’m using NSubstitute in a new TDD project for a component. Normally I prefer to program in C# but the company I’m currently working for is a VB-Shop, so I have to use VB here. (Note: I’m using VS 2008 atm)

NSubstitute is a mocking framework which makes heavy use of Lambdas. This results in compact and very readable Tests.

Here is an example where I want to throw an exception when a specific method on a mock is called (C# version). Given this interface:

In the test we expect that the Bar() method should throw an ApplicationException.

First we create a Substitute (a mock) aSub. By using the Returns() – extension method which comes with NSubstitute, it is possible to define what should be returned by a given method. Here I just define that calling Bar() throws the expected ApplicationMethod.

Calling Bar() throws and our test turns green.

Now turning to the dark side VB side:

The first thing to notice here is how the VB spoils the nice syntax by the Of Keyword for generics. “Substitute For Of IFoo” is just not as nice as  “Substitute For IFoo”.

But let’s focus on the main part I want to discuss. To satisfy the tests expectations we cannot just use a nice lambda as in C# because throw new ApplicationException just returns nothing, which is not allowed in VB. The workaround is to use a delegate. So let’s point to (AddressOf) our ThrowExForStringFunction.

To define this function you have to figure out which signature you have to use. This is not as easy as I thought and ReSharper won’t generate the correct signature for you. Studying the NSubstitute sources and the compiler errors is the way to go. Sadly.

In contrast to the C# example we have to deal with internal details to generate the matching method signature just to throw an exception.

To be fair the method could be generalized by using generics:

And the generic method:

Summary: It’s not only NSubstitute which looses the concise syntax. It’s all over the place when using Lambdas in VB.net!  I hope Visual Studio 2010 brings some improvements to the language.

I think almost everybody had the “pleasure” to extract information out of text files. The content may be Logs, Debug outputs or from any other source.

Lately I was asked task to analyze our codebase for some given keywords. I did it by downloading all sources to my local disk, and did a somewhat naive search method using Visual Studio “Find In Files”  (Shortcut is Shift+Ctrl+F).

Visual Studio offers the handy “Find In Files” option. You can specify to look in custom folder collections:

After selecting your folders you can start searching. 

In Visual Studio’s output window you see the search results. Copy and paste it into your favorite text editor (I’m, using Notepad++) and save it to disk.

The next step is to extract the information you need from this rather raw txt.

Fire up LinqPad. I suggest you download the latest version for .NET Framework 4.0.

To read in your file use the ReadLines() method which comes with framework 4.0. ReadLines gives you an IEnumerable<string> and yields the results. This means processing large datasets is possible, because only the current element is used. A good article by Paul Jacksonville can be found here.

My goal was to get all Files and the number of places my keyword was found.

So let’s look at how to read in Visual Studios “Find In Files” output:

The format is as follows:

FilePath(LineNumber):Contens

I’m using a regular expression to extract File and Line into an anonymous type:

var filesAndLines = File.ReadLines("c:\\temp\\SearchResults.txt")
                    .Where(x => Regex.IsMatch(x,@"(.+)\([1-9]+\)"))
                    .Select(y => new {  File= Regex.Match(y,@"(.+)\([1-9]+\)").Groups[1].Value, 
                                        Line=Regex.Match(y,@"(.+)\(([1-9]+)\)").Groups[2].Value});

Having this structure, it’s an easy step to group it:

filesAndLines.GroupBy(x => x.File)
              .Select(y=> new {File = y.Key, Count = y.Count()})
              .Dump();

That’s it. Hit F5 and see what the beautiful little Dump() – Extension from LinqPad produce:

The best thing is, you can easily export it to Excel or Word!

Fazit: LinqPad is a handy and versatile tool. I’m using it not only to understand LINQ better, but even for little tasks as shown here.