Debug Lambda expressions
Allow Quick Watch and other Debug functions to work with Lambda expressions.
"Expression cannot contain lambda expressions" makes this powerful language feature second-class within the IDE.
Especially for data intensive applications being able to write Lambda expressions in the Quick Watch, Watch, Immediate Windows and debug evaluation is a must have.
Matthew Rowan
shared this idea
33 comments
-
Damien Delaire
commented
+1
-
Qwertie
commented
I realize that this feature is quite difficult to implement, but has MS considered a stripped-down version of the feature that supports only very specific scenarios, particularly Where() and Select()?
Another feature that would really help is something that one could use *instead* of lambdas: a per-type string template that you could input into the debugger; basically I want to be able to assign a DebuggerDisplay attribute to a type on-the-fly, without stopping the program, changing/adding DebuggerDisplay and restarting. Imagine a right-click option in the watch window that would allow the user to change how the type is displayed.
-
Geoffrey Rayback
commented
Yes please.
-
Joshua A. Schaeffer commented
Wait for Roslyn. It will give us all this and more.
-
Mickey Perlstein commented
I agree wholeheartedly
-
David Johnson commented
+1 to this. It would be super handy!
-
Anonymous
commented
As I wrote already on microsoft.connect.com for ms there is an easy way to implement this feature. It would be maybe not have the very best performance but it is better than not to support it at all. They wouldn't even have to change the compiler support (f.e. for the Immediatewindow).
The expression tree could be created with the System.Linq.Expressions API in the background.
So when i would enter myList.Where(p => p.IsValid == true) this would be translated to first generate the Expression, get the function and execute the where (without actually compiling the lambda-expression) -
justin
commented
This is really what we want and need !!!!
ms is so lazy not to realize this feature !!!
-
jstevenson72 commented
This is one of the most frustrating things I've ever had to deal with. Edit and Continue has become a necessity in my team's work flows, and now we are forced to abandon it.
We have become increasingly more dependant on LINQ in all of it's forms, and the inability to edit code that contains a lambda or anonymous method really slows us down.
Our application takes a lot to get running, and having to stop/start it for tiny tweaks as we polish the logic is maddening.
Please put some MS muscle into giving us Edit / Continue behavior with LINQ, Lambda, and Anonymous methods.
-
codekaizen
commented
Here's my vote against ENC - it's just not useful compared to Watch/Immediate window support of expressions.
-
JaredPar commented
For those who are interested here are some articles which detail what exactly is involved in writing this feature and why it hasn't yet made it into the product.
http://blogs.msdn.com/b/jaredpar/archive/2009/08/26/why-no-linq-in-debugger-windows.aspx
http://blogs.msdn.com/b/jaredpar/archive/2010/08/14/10016054.aspxI no longer work on the languages team so I have less insight into the decision process. But I do know the teams are very much aware of the desire to have this feature. It's usually high up on the next version list. But the large cost usually causes it to be traded for other features.
-
Allon Guralnek
commented
The problem is that lambda expressions ARE second class citizens. There is no concept of lambdas in the CLR, they cannot be expressed in IL. They exist only in the compiler's imagination. They are just syntactic sugar. Lambdas are transformed by compilers into a method (and optionally a class to hold the closure), so writing a lambda in Quick Watch is the equivalent of adding a new method or a new class, something you wouldn't expected Quick Watch to be able to evaluate or accommodate. Adding new methods and classes is also not supported by Edit & Continue, which is why touching anything with a lambda is not supported.
But since you do expect to be able to evaluate lambdas in Quick Watch, then it should be able to support new methods and classes at runtime. And if you enable that, then it is almost as if you enable arbitrary runtime (or at least a debug time) program modification of any nature. Such a feature would enable both evaluating lambdas in Quick Watch and doing Edit & Continue on any imaginable change to the code. That would be an awesome yet hugely expensive feature to implement. It would make the code totally malleable during debugging, and would basically entail implementing a compiler with an expanded, flexible and powerful API that would allow calling it at runtime and plugging into it. That sounds awfully like Roslyn, doesn’t it?
-
Jon
commented
I think it's really strange that people have said "I won't upgrade to VS11 because of this". How does that make any sort of sense?
The problem is that lambda expressions may require classes to be created behind the scenes, and at the moment, as far as I understand it, the CLI requires an app domain's class layout to be constant.
So I think this requires a very deep framework change to implement. I have given this 3 votes as this is the biggest problem I come up against in debugging but I just thought others would like to know why this is such a big problem, and the work would probably bump a few other features you'd love off.
-
Alon Kobets commented
**** yeah! You pushed LINQ as the next best thing, but then don't allow us to debug it properly? What gives?
-
Michael Paterson commented
I don't care so much about E&C but would definitely love this feature. Totally disagree with @Ian Kemp though. The (sad) fact that this hasn't been implemented yet doesn't mean I won't upgrade to VS11.
-
Ian Kemp
commented
My company, and i'm sure many others, will not bother upgrading to VS11 if the ability to debug/quickwatch lambda expressions is not available. I don't particularly care how difficult this is to implement, what I do - and Microsoft should - care about is how much this feature is requested. Get it done and stop wasting everyone's time.
-
Dave Black
commented
I've had this request presented on the Connect website since July 2009. Isn't it about time?
https://connect.microsoft.com/VisualStudio/feedback/details/472999/ability-to-evaluate-lambda-expressions-in-immediate-window -
Lefteris Kalamaras
commented
It's a great pain to start working with lambda expressions because of the increased flexibility and faster execution they offer, only to find out later that edit&continue is broken because of the appearance of a lambda expression elsewhere in our code. We had to completely remove lambdas because of this as our productivity decreased exponentially. As a Microsoft MVP, I can't stress enough the importance we place in edit&continue in our company's code development so I strongly suggest you get this functionality implemented.
-
Giedrius
commented
Totally agree, that lambda debugging would be great. Until that, there's an workaround I use: there's dynamic linq library (link is here: http://weblogs.asp.net/scottgu/archive/2008/01/07/dynamic-linq-part-1-using-the-linq-dynamic-query-library.aspx), so if you have it somewhere referenced, simply use it in debug, as it does not use lambdas.
So simply write in quick watch window: System.Linq.Dynamic.DynamicQueryable.Where(source, "Id > 100"); -
kzu commented
Indeed, edit&continue aren't paramount at all. Even the most simple Where or Select Linq expressions are a must-have in the watch, locals and immediate windows for inspecting app state while debugging.
