Saturday, February 14, 2009

As a Program Manager at Microsoft, I wear several different hats. First and foremost, I am the Visual Basic IDE Program Manager, whose job is to keep the powerful engine that is the VB IDE Team running smoothly. However, another hat I wear is that of the Debugger Experience PM, whose job is to ensure that C#, Visual Basic and, yes, F# programmers have a great debug-time experience. From the language perspective, this often comes down to making the right tweaks in the debugger expression evaluators.

So, what are these debugger expression evaluators? The expression evaluators (affectionately known as the EEs) are magic machinery that deal with language-specific details on behalf of the core debugging engine that lives inside Visual Studio. In general, the EEs are responsible for the following:1

Notice that all three of the items above must be tailored to the language that the user is developing in. For example, it doesn’t make sense to display the C#-style hexadecimal value, 0x2a, to Visual Basic users. VB users expect to see the value rendered in the Visual Basic style for hexadecimal numbers, &H2A. Thus, to keep the experiences consistent, C# and VB both provide their own debugger expression evaluators.2

Recently, I was playing with a bit of Visual Basic code using an XML literal.

Module Module1

  Sub Main()
    Dim contacts = <contacts>
                     <contact name="Bob"/>
                     <contact name="Sally"/>
                   </contacts>

        Console.WriteLine(contacts)
    End Sub

End Module

If you’ve never seen a VB XML literal before, know that they are beautiful and powerful language constructs.3 Essentially, the code above is equivalent to the following C# code.

var contacts = new XElement("contacts",
                 new XElement("contact", new XAttribute("name", "Bob")),
                 new XElement("contact", new XAttribute("name", "Sally")));

Console.WriteLine(contacts);

If I set a breakpoint in the VB code above on Console.WriteLine(contacts) and press F5 to start debugging, I can see in the Locals window that my XML literal has effectively produced the same tree of XElement and XAttribute objects that the C# code explicitly declares above.

Locals

Now, suppose that I’ve made a mistake when declaring the XML literal (e.g. “Bob” should be “Harry”), but I don’t want to stop debugging, fix the code, and F5 to start again. I have a couple of options available to me for modifying values at debug-time.

  1. I can use Edit and Continue. This feature allows me to change my code at debug-time and move the instruction pointer in order to execute the modified code. However, this might not always be convenient.
  2. I can edit the value directly in one of the variable windows, the datatip, or the Immediate Window.

Choosing option two above, I’ll fix my mistake by editing the XML value directly in the Locals Window.

EditingWhenNotRemovingQuotes

Upon pressing ENTER, I’m presented with the following error dialog.

EndOfStatementExpected

What the heck does that mean? Well, this is the message that would be displayed by the Visual Basic compiler for a string value with inner quotes that are not escaped.4

Attempt number two: I’ll edit the value again and be careful to escape the quotes.

EditingAndEscapingQuotes

This time, when I press ENTER, I get yet another error message.

ValueOfTypeStringCannotBeConvertedToXElement

Grrr. Now I’m getting irritated!

Fortunately, the error message above gives me the clue I need to make this work. The problem is that I’m producing a string value, and I should be producing an XML value. What do I need to do differently? I need to remove the quotes that are enclosing the whole XML value.

Last try.

Editing XML in Locals

Success!

This time, I’m rewarded with a red display color for the value, indicating that the value has changed. If I expand some of the inner nodes, I can see that the tree of XElement and XAttribute objects has indeed been rebuilt.

Modified XML in Locals

That’s a pretty nifty trick that you can use right now in Visual Studio 2008. However, when I put on my Debugger PM hat, I consider how to improve this experience for Visual Studio 2010. Easy! We’ve removed the enclosing double-quotes from XElement values in the Visual Basic Expression Evaluator.

Sometimes achieving the best experience is just a simple tweak away.

1This is not an exhaustive list.
2F# currently uses the C# EE, but eventually F# will provide its own. Feel free to ping Luke and Tim to help make this happen.
3For a good example of how powerful XML literals are, see Dmitry Robsman's ASP .NET MVC Engine Using VB.NET XML Literals.
4Displaying this string without escaping the quotes strikes me as a bug. :-)

posted on Saturday, February 14, 2009 12:07:24 PM (Pacific Standard Time, UTC-08:00)  #    Comments [0]

kick it on DotNetKicks.com