Introduction To Format Specifiers In Visual Studio Debugger

Below are the few format specifiers that developers can use while debugging the applications and which can help reduce the debugging time by certain clicks/expansions (in a watch window). I have tested these code samples using Visual Studio 2017 Community Edition.

1. ac

Often working with LINQ queries, we try to evaluate the expression/query into watch window and upon stepping through the lines, we may need to check the result for the same query and click on the small Refresh button to get the updated value. That is a tedious task if we need to keep evaluating the same for a lengthy code. Well, there is a way to avoid that. Using format specifiers (while debugging), you can force the evaluation of the expression.

Consider the below code - a demo class containing ID and the name properties. I have decorated the class with DebuggerDisplay attribute to view the elements in watch window. For more details, please visit my article on the same here.

[DebuggerDisplay("{ID}:{Name}")]
public class DemoClass {
    public int ID {
        get;
        set;
    }
    public string Name {
        get;
        set;
    }
}

Inside the main method, I am populating the list of the DemoClass.

List < DemoClass > lstDemoClasses = new List < DemoClass > ();
for (int i = 0; i < 5; i++) lstDemoClasses.Add(new DemoClass {
    ID = i, Name = $ "name {i}"
});
var somequery = lstDemoClasses.Where(obj => obj.ID % 3 == 0).ToList();
lstDemoClasses.Add(new DemoClass {
    ID = 100, Name = "name 100"
});
Console.WriteLine();

Consider that you have some query (dummy query) where you want to list the objects whose ID is divisible by 3. And at the same time, you want to list the objects whose ID is even. For the same, I am adding a lambda query in my watch window like this.

Watch Window:



At this moment, I step through the breakpoint above. It is going to add one more object to the collection and the query in the watch window is not going to be evaluated as shown in the watch window. In order to evaluate this query, one may need to hit that little refresh button and then it would work. For most cases, it is okay to hit and go back to debugging but with a couple of queries together, it would be little time consuming.



To avoid these clicks, you can use the format specifiers for the watch window. For example, to force the evaluation of expression in the watch window, you can specify ac separated by a comma in Name column as below.



So now, when you step through the breakpoint (where it adds an object to the collection with id as 100), the debugger forces the evaluation of the query in watch window and you don’t need to hit the Refresh button.

2. Results

Another format specifier comes in handy when you need to view the complex queries in watch window that holds the list/collection.

For example, below is the sample code for the same. I have a list of strings and I am creating a dynamic object that holds the list of names with their length (where the length of the name is greater than 4).

List < string > names = new List < string > ()
{
    "str 1",
    "string 2",
    "test string 3",
    "test string 4121"
};
var linqQuery = names.Where(nm => nm.Length > 4).Select(obj => new {
    id = obj.Length,
        name = obj
});
Console.WriteLine();

Without any specifier, our watch window looks something like below.

By default, it shows some of the private variables from this dynamic object and you can change this behavior if you are focused on the results view only. Using results specifier, you would only see the result/collection directly. You can skip the "in" between privates and avoid one click while debugging.



3. nq

Using this specifier, you can view the string without quotes (no quotes). It is kind of least useful but I thought to mention it here, just in case.



There are a few more specifiers that you can find here.

Please feel free to comment with suggestion(s) to make it better.