Visual Studio 2010 has many windows helping in a debug process. But more of them follow an next idiom: “Say me a password and I’ll tell you a secret”. Above the password I mean a variable name and above the secret I mean a variable value. This is right and covered more part of cases. But sometimes you know a value instead of a place where it is. Sounds unrealistic? Maybe… Then imagine a list of more than 50 elements where each element of the object has 2 properties. A question: How quickly can you find an object knowing the value of a property and using only debug windows? And if it’s not single? If you are familiar with this situation, then the post for you.

Let’s try to analyze described situation. You have next solutions.

1. The most unreliable and long way – go through the list of values manually in a “Watch” or “Quick Watch”  window. This is possible because the IEnumerable (of course, with a generic version) interface and special classes for debug views (for example, Mscorlib_CollectionDebugView). You can ease the task of using the special debug attributes (such as DebuggerDisplayAttribute, DebuggerTypeProxyAttribute and so forth) to display the property values. But it should be done before you start debugging;
2. If you don’t like something, fix it! With earlier versions of the Visual Studio, programmers were able to change a data view in debug windows. A technology is called visualizers. Using them is a significant step forward, but still the search is done by hand (rather we are talking about your eyes and attention). Here is a good example of a visualizer for a list and a dictionary;
3. But how to get to work the machine (frankly, we do it every day)? The most obvious way is to write additional code. You can even bypass a simple cycle with a condition or use a conditional breakpoint;
4. If you look at the problem from an other side, we can see that similar problems we solve using Linq. Ok, let’s using Linq in debug windows, say in “Immediate window”… Don’t go. We can’t use lambda expressions in the debug window of  Visual Studio. Jared Par wrote excellent post (first and second parts) about the problems of supporting the lambda expressions in the debugger. It’s really important and useful feature. But as long as it does not exist, we can use next trick. Use a special method marked ConditionalAttribute and encapsulated our filter. A sample:

   [Conditional("DEBUG")]
   static bool ApplyFilter(MyType myObject)
   {
       if (myObject.MyProperty == "MyValue")
       {
           Debugger.Break();
           return true;
       }
   
       return false;
   }
   

That’s it. We can use this filter in debug windows. If you know other ways I am pleased to read about them in the comments.
Now I would like to share my vision of a search window in Visual Studio. Firstly, it’d be a good thing to implement a search based on Linq. Maybe it could be done on current version. How? Yes, I wrote about the problems of support for lambda expressions in debug windows. But, let’s consider the implementation details of a debug visualizer.

[assembly: System.Diagnostics.DebuggerVisualizer(
typeof(DebuggerSide),
typeof(VisualizerObjectSource),
Target = typeof(List<>),
Description = "LinqTest")]

namespace LinqTest
{
    public class DebuggerSide : DialogDebuggerVisualizer
    {
        override protected void Show(IDialogVisualizerService windowService,
                           IVisualizerObjectProvider objectProvider)
        {
			// An assembly attribute without a type specification.
            var people = (IEnumerable<dynamic>)objectProvider.GetObject();

            using (var form = new Form())
            {
                form.FormBorderStyle = FormBorderStyle.FixedToolWindow;

                var label = new Label { Parent = form, Text = "Only children" };

                // We'd get this chain from an user!
                var adults = people.Where(p => p.Age > 21).Select(p => p.Name);
                if (adults.Any())
                {
                    label.Text = string.Join("; ", adults);
                }

                windowService.ShowDialog(form);
            }
        }
    }
}

I use dynamic type here because I don’t want to complicate the example of reflection. If we add a textbox to enter the Linq queries and a parser which analyzes them for building of expression trees. We can get a tool like LinqPad.  And finally, we could take an alternative solution – any grid with advanced grouping and filtering. On the other hand, this way covers only public members. So we need a search based on reflection. Note, because we can’t use other variables, except for a value collection, it protects us from closures. I think about next options for the search:

• Set a access modifier for members in public, protected and so forth;
• Set a member for search in property, field, a result of methods;
• Set a type of a value that we’re finding in int, float, double and so forth;
• Set a level in current object or full hierarchy;
• Set attributes. For example, I want to find in properties with DataAnnotations attributes, but I want to exclude the properties with ObsoleteAttribute.

No, I don’t want to google in the debug window. But if you meet  with enterprise products that have heavy and tangled API every day (for example, SPList class from Microsoft SharePoint API have more than 80 properties) you will appreciate my idea of dignity.