Bernhard Glück

Today during work I made a mistake that I want to share with you because I think this is a corner case of LINQ and maybe not immediately clear to everyone. At least it wasn’t clear to me.
The code:

var rootElement = XElement.Load("SomeFile.xml");
var result = from x in rootElement.Elements("Child") where x.Attribute("Value").Value == "0" select x.Elements("GrandChild");

I thought that result would be a normal IEnumerable of XElement where the elements are all grandchildren in all children of the root element combined.
But guess again, the result will be an IEnumerable of IEnumerables, because the select statement selects the return value and does not iterate over it implicitly.

No, I am not playing the game, ( that should be left to way smarter people than me ) but fiddling around with Microsoft CHESS a product by their research group, that is going to be included in Visual Studio 2010. Right now it’s available in Beta form and it simply rocks.

The basic premise is that a new Test Runner for the Microsoft Testing Framework will run your unit tests that make use of multiple threads a large number of times with different thread interleave patterns, and thus detecting many kinds of threading bugs in your code.

After it has found a thread interleave sequence that will make your unit test fail, you can save this information and add it to the unit test itself, making your unit test reproduce the problem each time reliably.

This is simply a godsend, and the magic does not stop there.

While debugging the running unit test you can also break on any thread preemption which are very likely the spots in your code that actually contain the code that is the root cause of your bug.

So give this awesome tool a try, and write even better multithreaded code.

Microsoft Chess