Home
  Latest posts
  My Writings
  My Code
  My Gallery
  About me
 
  rssfeed Syndication
 
Bloggtoppen.se
 
 
Links
  Cornerstone
  SweNug
 
Post categories
  misc (48)
  Architecture (21)
  C# (19)
  Asp.Net (2)
  Vb.Net (2)
  Training (7)
  Data (19)
  Events (40)
  Platform (2)
  Orcas (4)
  Updates (3)
  Methods (10)
  Tools (6)
  Announcements (14)
  Languages (1)
  Patterns (6)
  Opinions (11)
  Fun (3)
  Ineta (1)
  Opinion (0)
  Practices (2)
  WCF (5)
 
 
 

Debugging LINQ Queries

Wednesday, March 21, 2007

Building applications based on LINQ, debugging is a must. In Visual Studio Orcas a lot of effort has been put down to give us a smooth experience when debugging queries. In addition to breaking on row where the query is created, it is also possible to break on separate parts of the query when the query is executed. The image below demonstrates how a breakpoint on a where clause could look like:  

Since the query isn't executed where it is declared (a concept called deferred execution) the breakpoint will not be hit until you actually execute. In practice this means that when the query executes, the debugger will go back to the query definition and break the execution there.

The following image illustrates how the code execution really is at the "in" (There is a grey box around IN, kind of hard to see I know) keyword of the foreach statement but the debugger indicates the where statement as being the one currently executing.

This is something that will need some training to get used to. In the above example it's kind of easy to still follow the code. But in a more real world example it is bound to get a bit more confusing. What if the query is defined in another method in some other place in our domain?

Yes, the debugger will jump to that file and to the breakpoint at the query definition. The below example has two classes, program and gateway, the query is defined in the gateway class and program is what executes it.

 So hitting "IN" (or any other place where the execution is triggered), will teleport you immediately to the Gateway.cs file and the creation of the query. Unorthodox and possibly very confusing since the code we really are looking at is the declaration of the query, not the execution of the same, and that might be totally out of the current execution context (i.e in a DAL when the real code is executing in the presentation layer).

All and all, the C# team have put in a lot of effort to get a smooth debugging experience and as we get used to this teleporting around, it might not feel as awkward as it currently looks.

kick it on DotNetKicks.com
 

Comments
3/21/2007 8:21:00 PM   http:/   -   jc
 
Yikes! That I didnt know. Thats for the heads up.
 
7/18/2007 10:41:00 AM     -   Tarun
 
No Dought a great effort made by Microsoft


Comment
Title:
Your name:
Your url:
Text:
Please enter the text from the image: