Debugging LINQ Queries

When I looked around recently for answers to the very same question I found some intriguing hints here and there but no cohesive narrative really digging into answering the question. So I wrote one myself and it was just published on Simple-Talk.com (LINQ Secrets Revealed: Chaining and Debugging). You might need to register to read the article (site seems to be going through some changes in recent days) so here are the highlights of the article:

(1) In LINQPad: Use its extraordinary Dump() method. You can inject this at one or more points in a LINQ chain to see your data visualized in an amazing clean and clear fashion.

(2) In Visual Studio: Embed nop statements in the middle of your LINQ chain so you can set breakpoints. Note the return statement must be on its own line to set a breakpoint in Visual Studio. (Thanks to Eric White’s blog entry Debugging LINQ Queries for this tip.)

.Select(z =>
{return z;}
)

(3) In Visual Studio: Inject calls to the Dump() extension method I present in my article to allow logging. I started with Bart De Smet's Watch() method in his informative article LINQ to Objects – Debugging and added some labeling and colorization to enhance the visualization, though still it pales in comparison to LINQPad's Dump output.

(4) Finally, (yes I am enamored of LINQPad's Dump method!) bring LINQPad's visualization right into Visual Studio with Robert Ivanc's LINQPad Visualizer add-in. Not a perfect solution (no support yet for VS2010, requires classes to be serializable, some rendering issues) but it is quite useful.

2016.12.01 Update

Just published on Simple-Talk.com is the sequel to the above article: LINQ Debugging and Visualization. This article provides thorough coverage of the new LINQ debugging capability of the OzCode extension for Visual Studio 2015. OzCode finally makes LINQ debugging easy and powerful. (And, no, I do not work for OzCode :-).

A query like that seems to indicate to me that you're not doing a good job choosing appropriate data structures, or doing a good job with encapsulation and separation of tasks. I'd suggest taking a look at it and breaking it up.

In general, though, if I want to debug a LINQ query that isn't obviously correct, I'd break it up into subqueries and examine the results one-at-a-time in the debugger.

I know my answer is "a bit" late, but I had to share this:

Just discovered LinqPad and it's AMAZING (not to mention free).
Can't believe I've written Linq for so long without knowing about this tool.

As far as I understand, it's the work of the author(s?) of O'Reilly's "C# 3.0 in a Nutshell" and "C# 4.0 in a Nutshell" .