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.
Using Roslyn, it should be easier to support lambdas in the immediate/watch window. This would be enormously beneficial, as right now LINQ, one of the most powerful tools in .NET is not usable while debugging, which makes debugging with data sets a lot more difficult than it needs to be.
So that it's easier to debug.
Jared Parsons commented
Roslyn is not a pre-requisite for this feature (although Roslyn's hostable nature likely makes this an easier problem to solve)
Mehran Davoudi commented
I assume its prerequisite is the Roslyn.
Joao Oliveira commented
It's still not in implemented for VS 2013. This should be a priority.
I know this is tough to implement, but to be able to run some linq in the immediate window would be a great feature. I often wish I had it.
I hope accompanying this will be replacing the Immediate Window with the C# interactive window from Roslyn.
Michael Paterson commented
@Anatoliy, I believe this feature will probably wait until Roslyn is complete.
@Allon, The entire internet: http://blogs.msdn.com/b/bharry/archive/2013/06/03/visual-studio-2013.aspx
Allon Guralnek commented
Who said there's going to be a Visual Studio 2013? Since 2003 Microsoft has never released two consecutive versions of Visual Studio in adjacent years. They're usually two or three years apart.
Anatoliy Pankov commented
It will be in Visual studio 2013?
Damien Delaire 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
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!
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)
This is really what we want and need !!!!
ms is so lazy not to realize this feature !!!
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.
Here's my vote against ENC - it's just not useful compared to Watch/Immediate window support of expressions.
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.
I 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.