Filtering collections in Visual Studio debug windows

Most .Net developers are familiar with lambda expressions and actively use them. However, when trying to use them in debug windows like Watch / Immediate and Locals, Visual Studio will tell us that “Expression cannot contain lambda expressions”. There are reasons for this, and they are set forth in great detail in these posts . Unfortunately, they also lack information about 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

The first solution appeared, oddly enough, long before the lambda expressions themselves and based on the way the debug information is displayed in Visual Studio.

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

1. Text;
2. HTML;
3. XML;
4. WPF visual component tree;
5. The 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 necessary functionality.
')
Therefore, the first solution was a data table that displays a collection of objects with all its properties and allows you to customize 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 70-516 exam : TS: Accessing Data with the Microsoft .NET Framework 4, I carefully studied Entity SQL , which I had only heard about before (except for the experience with HQL ). For those who do not know what kind of beast, give a definition from MSDN:

Entity SQL is a storage independent language similar to SQL. Entity SQL is designed to query and manage a large number of object graphs based on a conceptual model.

Those. in the Entity Framework, we can describe the filtering 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 have already guessed that writing lambda expressions in string form is a way to get around the problem with the Visual Studio debugger. As a result, extension methods for Linq-to-Object were written, accepting string filters as input. By analogy with Entity SQL, they were called Object SQL. The advantages and disadvantages of this solution are obvious. The only thing I would like to point out is an alternative syntax. The fact is that we already have another format for specifying filtering conditions in text form, which is used in the OData protocol. And the above filter 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 waited for the support of lambda expressions along with the release of Visual Studio 2010, but alas. Therefore, we have to put up with the imperfection of the working tool and look for workarounds.

PS: I hope Comrade outcoldman lobbies this question in the Visual Studio development team.