Debugging Expression Trees in Visual Studio 2010

Published 19 November 09 08:05 PM

First of all, let’s take a look at the example from one of my previous posts. It creates an expression tree for calculating the factorial of a number.

ParameterExpression value = 
    Expression.Parameter(typeof(int), "value");
ParameterExpression result = 
    Expression.Parameter(typeof(int), "result");
LabelTarget label = Expression.Label(typeof(int));
BlockExpression block = Expression.Block(
    new[] { result },
    Expression.Assign(result, Expression.Constant(1)),
    Expression.Loop(
        Expression.IfThenElse(
            Expression.GreaterThan(value, 
                Expression.Constant(1)),
            Expression.MultiplyAssign(result,
                Expression.PostDecrementAssign(value)),
        Expression.Break(label, result)
        ),
        label
    )
);
Expression<Func<int, int>> lambda = 
    Expression.Lambda<Func<int, int>>(block, value);
Console.WriteLine(lambda.Compile()(5));

Now, what if you want to see the content of this tree in debug mode? You can try lambda.ToString() but it’s not very informative. All you get is this: value => {var result; … }. Basically, it tells you only that the lambda has the result parameter.

Another option is to explore the tree structure in the Watch window. However, since this is a tree, you need to click through numerous nodes. This gives you a good understanding of the tree structure, but it might be hard to understand the actual content of the tree.

But there is a better solution: expression trees now have their own visualizer that helps you to explore their structure and content.

Copy the above code example into Visual Studio 2010, set a breakpoint at the last line, and press F5. Rest the mouse pointer over the lambda variable and you will see that it has the DebugView property. This property is private and is exposed only in the debugger, so you can’t use it in your code. But it’s used to hook up the expression trees visualizer. Click the magnifying glass icon and you will see the list of available visualizers.

image

Now click Text Visualizer and you get this.

image

As you can see, the content of the expression tree is represented in some kind of metalanguage. (No, we couldn't use C# here, because expression trees serve other languages as well.)

There are some simple rules used in this metalanguage:

  • Parameters are displayed with a $ symbol at the beginning (for example, $result and $value.)
  • Integer, string, and null constants are displayed “as is” (for example, $result = 1). For other numeric types that have standard suffixes, the suffix is added to the value. (For example, for decimal the value is 1M, for double 1D, etc.)
  • If a parameter, label, or lambda expression does not have a name, the name is generated automatically (for example, #Label1, $var1, etc.)
  • Checked operators are displayed with the # symbol preceding the operator. For example, the checked addition operator is displayed as #+.

There are some other nuances that I think are evident and don't need additional explanation. But if you don’t understand something in this syntax, let me know and I'll include more information in the documentation.

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# KristoferA said on November 22, 2009 9:45 PM:

Very nice.

Will it get debug-step-through-support too? I.e. so when evaluating a tree one can set breakpoints, step through expressions, check values etc?

# NT said on November 23, 2009 6:11 AM:

Why didn't you use instead of yet another meta language the relevant language that the dev is using at the time, e.g. C#, VB, etc? So that we have to remember yet another soup of symbols, rules and names?

# TC said on November 24, 2009 3:17 AM:

NT, you don't have to use any of the new features of .NET4, they're just extras if you want them, and can find a use for them. Anyway, whilst it might technically be possible to do this sort of thing in vanilla C# or VB, it is horribly fiddly and inconvenient.

Also, I don't see any new symbols to be learned, the rules are the same rules for any language (since pretty much all languages are underpinned by compiler that understands some sort of expression tree), and as for the names.... how else are you supposed to program anything without some sort of name to identify the constructs that you are using?

# Pete Montgomery said on November 25, 2009 1:41 AM:

So this isn't strictly a new Visual Studio visualizer, but a new "debug string" available as a private property on Expression or LambdaExpression?

# Jon Skeet said on November 25, 2009 12:12 PM:

Am I right in saying this isn't available in VS2010beta2? I've just tried it and failed to get the debug view to come up... is there anything I need to do to turn this on, or is it just not in beta 2?

# Janusz Nykiel said on November 26, 2009 2:50 AM:

I see that the ExpressionTreeVisualizer sample is no longer shipped with VS2010, and all Expression types have a DebuggerProxyTypeAttribute. Is there a way to make VS debugger visualizer target types that have DebuggerProxyTypeAttribute applied? Textual DebugView sure is nice, but people have written much more useful visualizers and I see no obvious way to make them work with 4.0 expression types.

# Krypto said on November 26, 2009 6:18 PM:

I look at that code and I want to puke.

Now I can't wait to leave an intern in front of pages and pages of this fine new microsoft sponsored mini-programming-language-in-a-language until he blows it's brains out.

# David Brown said on November 29, 2009 5:35 PM:

@Krypto: No one is forcing you or your intern to use it. Besides, it's already easier to read than the original code, and definitely easier to debug than the old way. And if your intern can't even learn to read something as simple as that example, maybe it's a good thing he's not being paid in the first place. And let's be realistic here... pages? C'mon. The author explained the whole thing in 4 bullet points.

Anyway, moving on... this looks great! I'm glad you chose to use something that at least resembles a programming language instead of XML.

# Shivakant Upadhyay said on December 1, 2009 1:30 AM:

I am unable to see the debugview property using VS2010Beta2...

# Alexandra Rusina [MSFT] said on December 1, 2009 10:26 AM:

This feature did ship in Beta2 and I made all the screenshots using the official build. The QA team is investigating.

If you have any problems with the feature, please let us know and give us some details. At least answer these two questions:

1) Can you see the "DebugView" property on the Expression Tree node in the debugger?

2) If yes, can you see the list of visualizers? 

# Jon Skeet said on December 1, 2009 1:48 PM:

Doh! I worked it out in the end... it has to be a project targeting .NET 4.0. It's not just a feature of VS2010, but also of the framework...

Sorry for the false alarm.

Jon

# Alexandra Rusina [MSFT] said on December 1, 2009 5:06 PM:

@ KristoferA

I am not sure I understand your question. You can use breakpoints and see the content of the expression tree in VS2008 and in VS2010 in the same way as for any other object.

@Pete

Well, there is a feature in Vusual Studio that is called "visualizer". The private property "DebugView" is just used to hook up to this feature.

@Janusz Nykiel

Yes, this sample has not shipped with Visual Studio Beta2.

I wonder what "other visualizers" you are referring to. Can you please provide examples? By the way, the old expression trees API has not changed, so those visualizers should work. How to support the new ET nodes is a different question, though.

# Janusz Nykiel said on December 2, 2009 12:04 AM:

@Alexandra Rusina

>I wonder what "other visualizers" you are referring to. Can you please provide examples?

The example one that shipped with VS 2008 (ExpressionTreeVisualizer), or Manuel Abadia's one (google manuel abadia visualizer). Basically, any one targeting the Expression type.

>the old expression trees API has not changed, so those visualizers should work

They may be source-code level compatible, but I see no way to integrate them with VS debugger, unless there is a way to have VS pick up a visualizer for a type attributed with DebuggerTypeProxy.

# Alexandra Rusina [MSFT] said on December 3, 2009 10:19 AM:

@ Janusz

OK, I'll take a look at this problem. It might take me sometime, so don't expect a quick answer. I'll post a comment here as soon as I have something to tell you.

# Toddap_MS said on December 7, 2009 4:12 PM:

On the ExpressionTreeVisualizer question, if you read the directions on how to install/use this visualizer, you can get the visualizer working with dev10, although we haven't done this since Beta1 since we this visualizer didn't add much value over the debugview property and doesn't support any of the new nodes.

# Alexandra Rusina [MSFT] said on December 16, 2009 11:25 AM:

@ Janusz

I asked the QA team to look at this matter. I see that Todd answered you and told you that the old visualizer should work in VS 2010. So should other ET visualizers.

If you have any specific problems, please write to dlr@microsoft.com and we will look into it.

# Janusz Nykiel said on December 28, 2009 1:26 AM:

Alexandra, Todd:

I got it working only when I changed the Target property on the DebuggerVisualizerAttribute to a concrete IQueryable implementation (ie. Entity Framework's ObjectQuery), and added code to the GetData method to extract the Expression from the IQueryable. I then made a minimal visualizer, and it doesn't work (as in: is not picked up by VS - is not listed in the magnifying glass dropdown) for the Expression type, or any type with DebuggerTypeProxy attribute.

# NEil said on January 5, 2010 2:49 AM:

To all the whining people.

Stop whinging and write your own visualizer if you don't like it.

# Toddap_MS said on January 7, 2010 3:29 PM:

Unfortunately, I'm not an expert in debug visualizers (although I've seen some good whitepapers on creating them), so I cannot comment on the above.

However, I am curious as to why you would want a visualizer over what we supply today with the debugview (or ToString()) properties.   Those should be more rich and easier to deal with for most needs, so I'm curious as to what benefit you're trying to gain.

# Alexandra Rusina [MSFT] said on January 8, 2010 10:08 AM:

@Janusz

Take a look at this post:

http://marcgravell.blogspot.com/2009/03/visualizing-expressions-in-propertygrid.html

Looks like it can help you with building custom visualizers.

Leave a Comment

(required) 
(optional)
(required) 

  
Enter Code Here: Required

This Blog

Syndication

Page view tracker