Filtering collections in Visual Studio debug windows

Most .Net developers are familiar with lambda expressions (lambda expressions) and actively use them. However, when you try to use them in debug windows such as Watch / Immediate and Locals, Visual Studio tells us that “Expression cannot contain lambda expressions”. There are reasons for this, and they are very detailed in these posts . Unfortunately, they also lack information on solving this problem. While developers every day are faced with the need to filter collections in debug mode and support for lambda expressions would greatly simplify their work.

Visualizers

Oddly enough, the very first solution appeared long before the lambda expressions themselves and is based on the way debugging information is displayed in Visual Studio.

The built-in debugger displays the values ​​of variables or objects using the so-called visualizers - user interface components. Out of the box, 5 different visualizers are available for working with:

1. Text;
2. HTML
3. XML
4. WPF Visual Component Tree
5. A dataset represented by DataSet, DataView, and DataTable objects.

Some of them can not only display values, but also edit them. In addition, it is an extensible mechanism and the developer can write a visualizer with the functionality he needs.

Therefore, the first solution was a data table that displays a collection of objects with all its properties and allows you to configure filtering rules using a collection of predefined filters:



Not the most convenient way is to open a separate window each time to set filtering conditions, so the search continued.

Entity SQL

A year later, in preparation for the exam 70-516: TS: Accessing Data with Microsoft .NET Framework 4, I carefully studied Entity SQL , which I had only heard about before (except for experience with HQL ). For those who don’t know what kind of beast, I’ll give a definition from MSDN:

Entity SQL is a repository-independent language similar to SQL. Entity SQL is intended for querying and managing a large number of object graphs based on a conceptual model.

Those. in the Entity Framework we can describe the filter condition as a string. Example:

using (var context = new CountriesEntities())
{
    var countriesStartWithA = context.Countries.Where("it.Name LIKE 'A%'");
}

* This source code was highlighted with Source Code Highlighter.

Object SQL

I think you already guessed that writing lambda expressions in string form is a way to get around the problem with the Visual Studio debugger. The result had been written extension methods (extension methods) for Linq-to-Object, receiving the input string filters. By analogy with Entity SQL, they were called Object SQL. The advantages and disadvantages of such a solution are obvious. The only thing I would like to point out is the alternative syntax. The fact is that we already have another format for setting filtering conditions in text form, used in the OData protocol . And the filter above could be rewritten as:

using (var context = new CountriesEntities())
{
    var countriesStartWithA = context.Countries.Filter("$filter=startswith(Name,'A')");
}

* This source code was highlighted with Source Code Highlighter.

Honestly, I was expecting support for lambda expressions along with the release of Visual Studio 2010, but alas. Therefore, you have to put up with the imperfection of the working tool and look for workarounds.

PS: I hope comrade outcoldman is lobbying this issue in the Visual Studio development team