{"id":69206,"date":"2016-12-01T14:01:21","date_gmt":"2016-12-01T14:01:21","guid":{"rendered":"https:\/\/www.simple-talk.com\/?p=69206"},"modified":"2021-06-03T16:47:06","modified_gmt":"2021-06-03T16:47:06","slug":"linq-debugging-visualization","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/development\/dotnet-development\/linq-debugging-visualization\/","title":{"rendered":"LINQ Debugging and Visualization"},"content":{"rendered":"

Microsoft\u2019s Language-Integrated Query (LINQ) technology is fast approaching its tenth anniversary. The earliest reference I\u2019ve found is from February, 2007<\/a>, which was a lengthy article by Don Box and Anders Hejlsberg. Since then, you might think that everything that needs to be said about LINQ has been said. It hasn\u2019t, in fact, all been said, because I need to point out in this article LINQ has at last got the Debugger it always deserved and needed, thanks to a new feature coming in the next release of OzCode. OzCode<\/a> is a Visual Studio extension that improves the debugging experience immensely: It is relatively new so it is not that well known, but it has been around long enough, more than two and a half years, to prove its mettle with many developers.<\/p>\n

Since the 2.0 release of OzCode, the development team at OzCode has focused on the flagship feature of the next release, LINQ debugging. As an early adopter of OzCode, I jumped at the chance to participate in their early access program for this upcoming release. I rarely write about products per se\u2014I think I have done it twice in my last hundred or so articles\u2014as I do not want to appear like a huckster for the company. But this LINQ debugging capability is so useful it really deserves the attention here. Just to be clear, I have no association with OzCode other than being an avid user. (Ed: OzCode is nothing to do with us either)<\/p>\n

I am going to jump right in and show you how LINQ visualization works with OzCode in Visual Studio. I\u2019ll skip my usual type of preamble that, in this case, would include discussing command pipelining, method chaining, LINQ logistics, and debugging limitations & options before OzCode. The reason is that my prior article, LINQ Secrets Revealed: Chaining and Debugging<\/a>, already covers those in depth and I urge you to review that article before continuing. Though that article is six years old (to the day!), the vast majority of it is still relevant today. And it is a great stepping stone for today\u2019s topic. In fact, to show the improvements provided by OzCode I am going to continue the same set of examples.<\/p>\n

Visualizations Before OzCode<\/h2>\n

The first code sample is the simple LINQ chain in ProcessWordList1<\/strong>. (This code is available in the LinqMethodChaining<\/strong> project of the LinqDebuggingWithOzCode<\/strong> solution attached to this article.)<\/p>\n

class Program\r\n{\r\n    static readonly string[] Words =\r\n        {\"   KOOKABURRA\", \"Frogmouth\", \"kingfisher   \", \"loon\", \"merganser\"};\r\n \r\n    static void Main()\r\n    {\r\n        var newWords = ProcessWordList1(Words);\r\n        foreach (var word in newWords)\r\n        {\r\n            Console.WriteLine(word);\r\n        }\r\n        Console.ReadLine();\r\n    }\r\n \r\n    private static IEnumerable ProcessWordList1(string[] words)          \r\n    {\r\n      return words\r\n        .Select(word => word.Trim())\r\n        .Select(word => word.ToLower())\r\n        .Where(word => word.StartsWith(\"k\"))\r\n        .OrderBy(word => word);\r\n    }\r\n}\r\n<\/pre>\n
In the prior article, I showed how to instrument that code to inject watchers that would allow a very crude visualization on the console. In Figure 1, you can see movement of each input element through the LINQ chain. The output on the left comes from injecting the custom EnumerableDebugger<\/strong> with default settings, whereas the output on the right shows the same thing with some customization arguments passed in.<\/p>\n
<\/p>\n
Figure 1<\/p>\n
The figure\u2014particularly the right side\u2014certainly provides useful information, but it requires extensively instrumenting your code to get that output, and even then it is console output rather than something that is available in the debugger.<\/p>\n
<\/p>\n
Figure 2<\/p>\n
The next step I introduced was to take the code over to Joseph Albahari\u2019s LINQPad<\/a>, a very handy sandbox for sketching out your code, because its forte is LINQ visualization. In Figure 2, you have a clearer picture of the data moving through the LINQ method chain, but this also has a number of drawbacks. First, it is divorced from Visual Studio completely so quite disruptive in terms of workflow: You need to copy code from Visual Studio into LINQPad. You also have to manually instrument the code with LINQPad\u2019s Dump method to output the visualizations. Here\u2019s what it looks like:<\/p>\n
string[] Words = new string[]\r\n{\r\n\t\"   KOOKABURRA\",\r\n\t\"Frogmouth\",\r\n\t\"kingfisher   \",\r\n\t\"loon\",\r\n\t\"merganser\"\r\n};\r\nWords\r\n   .Dump(\"ORIGINAL:\")\r\n   .Select(word => word.Trim())\r\n   .Dump(\"TRIMMED:\")\r\n   .Select(word => word.ToLower())\r\n   .Dump(\"LOWERCASE:\")\r\n   .Where(word => word.StartsWith(\"k\"))\r\n   .Dump(\"FILTERED to 'K':\")\r\n   .OrderBy(word => word)\r\n   .Dump(\"SORTED:\");\r\n<\/pre>\n
The final approach I offered in my previous article was that of using Robert Ivanc\u2019s LINQPad Visualizer<\/a>, a plug-in of sorts for Visual Studio that lets you generate the same LINQPad visualizations within Visual Studio using the Watch window. That technique allowed you to stay in Visual Studio, and also removed the impediment of having to decorate the code (i.e. it did not require adding the Dump method calls), but I assume it never really garnered enough interest as the web page shows support only through Visual Studio 2012.<\/p>\n
All of these debugging techniques are ways to dance around the true issue; needing to visualize a LINQ chain in situ. That is, ideally it should require no code instrumentation, should allow interacting with a LINQ chain with the same ease that Visual Studio allows you when interacting with variables and objects while stopped at a breakpoint. Let\u2019s explore how OzCode delivers this experience.<\/p>\n
OzCode: A First Look at LINQ Exploration<\/h2>\n
In Figure 3, I am in the debugger in Visual Studio 2015 and have just stepped onto the return statement of ProcessWordList1<\/strong>. Visual Studio has highlighted the entire LINQ chain in yellow.<\/p>\n
The first thing to notice, unrelated to LINQ, is the decoration of the method signature, that string[5]<\/strong> above the parameter sitting in a shallow tray. That is OzCode\u2019s standard Heads Up display<\/a>. Like its namesake from the automotive industry, it is a feature that presents data right in front of you, so you do not have to look in your Locals window, Watch window, etc. Here it is just letting us know the passed in array has five elements. More on that shortly.<\/p>\n
<\/p>\n
Figure 3<\/p>\n
The second thing to notice is that each expression in the LINQ chain is decorated with a numerical marker, e.g.  . Those numbers indicate how many elements are in the sequence at that point in the chain. In other words, the source (words) starts with five elements then goes through a couple Select expressions. Since Select does not change the cardinality of a sequence, it shows five on both of those as well. Then, the Where expression filters the list down to two, and OrderBy<\/strong> maintains that list size, also showing two elements.<\/p>\n
Note that, if the size or complexity of your sequences are great enough, OzCode will not<\/em> automatically execute the sequence in case that impedes Visual Studio\u2019s responsiveness. When OzCode detects that this might happen, you will see a question mark  rather than a number in each marker; clicking on any one will evaluate the sequence and fill in the numbers.<\/p>\n
Next I click on the first marker, shown by the arrow I have added on the left side of Figure 4.<\/p>\n
\"figure4\"<\/p>\n
Figure 4<\/p>\n
The action of clicking on that marker \u2026<\/p>\n
    \n
  1. Inverts the colors and darkens the selected marker to show it is the current sequence in the chain.<\/li>\n
  2. Changes the contents of the marker to show both the position of the current element in the current sequence and the length of that sequence.<\/li>\n
  3. Opens a DataTip<\/a>-like window enumerating the current sequence.<\/li>\n
  4. Activates the current sequence so you can navigate around it with the mouse or the arrow keys.<\/li>\n<\/ol>\n
    Note carefully the distinction between current sequence<\/em> and current element<\/em> in the above.<\/p>\n
    In Figure 4, the current sequence<\/strong> is the list of data elements as it exists at some point in the LINQ chain. I clicked on the very first marker, so the current sequence at that point is just the input (or source <\/em>as OzCode prefers to call it), which is the contents of the variable words. That\u2019s just what you see in the DataTip on the right of the figure.<\/p>\n
    A current sequence always has to have a current element<\/strong>, i.e. one member of the sequence that is highlighted and notated in some fashion. When you click on a sequence and activate it, the first element in that sequence automatically becomes the current element. Thus, the  expression you see in the marker that I just clicked on means the first element in the sequence is the current element and there are five elements in the current sequence. Over on the right of the Figure 4, the second arrow I have added is pointing to the current element\u2014the first element at the moment\u2014that, from a list perspective, is at index zero.<\/p>\n
    Walking through Elements<\/h2>\n
    To recap Figure 4, the current sequence is just the input, words. The current element is the first element, \u201c KOOKABURRA\u201d (with some extra leading spaces). So now let\u2019s advance to the next element in the current sequence. There are three ways to do that:<\/p>\n