How to debug a LINQ Statement

Question

Yes it is indeed possible to pause execution midway through a linq query.

Convert your linq to query style using lambda expressions and insert a Select statement that returns itself somewhere after the point in the linq that you want to debug. Some sample code will make it clearer -

        var query = dataset.Tables[0].AsEnumerable()
            .Where (i=> i.Field<string>("Project").Contains("070932.01"))
 //         .Select(i =>
 //         {return i;}
 //           )
            .Select (i=>i.Field<string>("City"));

Then uncomment the commented lines. Make sure the {return i;} is on its own line and insert a debug point there. You can put this select at any point in your long, complicated linq query.

I'm not sure if it's possible to debug from VS, but I find LINQPad to be quite useful. It'll let you dump the results of each part of the LINQ query.

You should be able to set a breakpoint on the expression in the where clause of your LINQ statement.

In this example, put the cursor anywhere in the following section of code:

(l.LineNumber == startline.LineNumber) || (l.LineNumber == endline.LineNumber)

Then press F9 or use the menu or context menu to add the breakpoint.

When set correctly, only the above code should have the breakpoint formatting in the editor rather than the entire LINQ statement. You can also look in the breakpoints window to see.

If you've set it correctly, you will stop each time at the function that implements the above part of the query.

I wrote a comprehensive article addressing this very question published on Simple-Talk.com (LINQ Secrets Revealed: Chaining and Debugging) back in 2010:

I talk about LINQPad (as mentioned earlier by OwenP) as a great tool external to Visual Studio. Pay particular attention to its extraordinary Dump() method. You can inject this at one or more points in a LINQ chain to see your data visualized in an amazingly clean and clear fashion. Though very useful, LINQPad is external to Visual Studio. So I also present several techniques available for use within Visual Studio because sometimes it is just not practical to migrate a chunk of code over to LINQPad:

(1) 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.

(2) Bring LINQPad's visualization right into Visual Studio with Robert Ivanc's LINQPad Visualizer add-in. Not sure if it was through my prodding :-), but the couple inconveniences present when I was writing my article have now all been admirably addressed in the latest release. It has full VS2010 support and lets you examine any object you like when debugging.

(3) Embed nop statements in the middle of your LINQ chain so you can set breakpoints, as described earlier by Amazing Pete.

2016.12.01 Update

And I just wrote the sequel to the above article, titled simply LINQ Debugging and Visualization, which reveals that true LINQ debugging capability has finally arrived in Visual Studio 2015 with the about-to-be-released new feature in OzCode. @Dror's answer to this question shows a tiny glimpse of it, but I encourage you to read my new article for an in-depth "how to". (And I do not work for OzCode.:-)

[Disclaimer: I work at OzCode]

The problem with LINQ is that it's hard to impossible to debug - even when dealing simple queries a developer is forced to refactor his/her query to a bunch of foreach loops, or use logging. LINQ debugging is supported in a soon-to-be-released version of OzCode (currently available as an Early Access Preview) and it helps developers drill into their LINQ code as well and pinpoint those hard to catch exceptions inside queries

This is what your query would look like in OzCode: