IEnumerable Visualizer in Visual Studio 2022: bounding large lazy collections without re-executing IQueryable queries

Direct answer

1. The visualizer does **not** cache the entire sequence; each request for more rows (scrolling or applying a filter) causes a new enumeration via GetEnumerator()/MoveNext(). For an IQueryable source this usually means the underlying query is re‑executed unless the provider itself caches results.
2. There is **no** built‑in setting to limit how many rows the visualizer evaluates. To bound evaluation you must apply a limiting operator such as Take(n) (or Skip/Take) to the variable in the watch expression before opening the visualizer.
3. If the enumerable has side‑effects (logging, state changes, etc.), the safer approach remains to use a DebuggerTypeProxy (or materialize with ToList()) because the visualizer may re‑enumerate and repeat those effects.

Confirmed facts

• The built‑in IEnumerable visualizer in VS 2022 displays collections in a sortable, filterable grid and loads rows incrementally as you scroll or apply filters.
• No documented visualizer option exists to cap the number of evaluated rows.

Likely explanation

When the visualizer needs additional rows it calls the enumerable’s GetEnumerator again. For lazy LINQ over IQueryable each call creates a new query execution unless the provider (e.g., EF Core with tracking disabled) caches the results internally. Hence filtering or scrolling can trigger repeated database round‑trips.

Steps to avoid unwanted re‑execution

1. In the Watch window, prepend a limiting operator to the variable, e.g., myQuery.Take(50).
2. Click the magnifying‑glass icon to open the IEnumerable visualizer; only up to the specified number of rows will be fetched.
3. If you need to inspect side‑effect free data, consider adding a DebuggerTypeProxy to the type or materialize with ToList() in the debugged process.

Missing diagnostic detail

Whether your IQueryable provider caches results (e.g., EF Core AsNoTracking vs. tracked queries) changes the impact of re‑enumeration. If the provider caches, repeated visualizer enumerations may not re‑execute the query; if it does not, each scroll will cause a new database round‑trip. Confirm the caching behavior of your provider to decide if additional bounding is required.