I suggest you ...

LINQ Debugging - condensed call stack view that was more of a "query stack"

Improve debugging support for Ix and Rx queries in the IDE. Specifically, a condensed call stack view that was more of a "query stack" would be great. It would also be great if we could hook into the "query stack" features from our own LINQ-based APIs.

143 votes
Sign in
Password icon
Signed in as (Sign out)
You have left! (?) (thinking…)
Dave shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Password icon
Signed in as (Sign out)
  • Floele commented  ·   ·  Flag as inappropriate

    The current VS 2014 Preview does this when executing "x.OfType<MyType>()" within the immediate window:

    [System.Linq.Enumerable.<OfTypeIterator>d__aa<MyType>]: {System.Linq.Enumerable.<OfTypeIterator>d__aa<MyType>}
    Results View: Expanding the Results View will enumerate the IEnumerable

    This is so incredibly not helpful that I would rather report it as a bug, but I have been told to submit it as feature so here is my request. I obviously want to see the collection content here and not some kind of gibberish.

  • Dave commented  ·   ·  Flag as inappropriate

    The problem is that call stacks tell you where you're going next, not where you've been. It just-so-happens that in a synchronous world it tells you both. In Rx queries specifically, what we really need is a "query stack" that tells us where we've been, relative to where we currently are. I think that would make debugging async queries much easier. And of course, the same view could be used to simplify debugging Ix queries as well.

  • Matt Downing commented  ·   ·  Flag as inappropriate

    I think you are trying to say what I'm thinking... Linq is amazing. But debugging it is a pain.

    What I would like is for debug to be able to move through Linq clauses one at a time, calling the equivalent of ToArray() (or something) so I can see the state of the resultset at each stage.
    Otherwise when faced with .Where(...).GroupBy(...).Where(...).Select(...) etc to debug you'd need to break your code into lots of little queries, forcing the code to be in a "development" state rather than a more efficient "release" state.

    Is that your idea?

Feedback and Knowledge Base