“Lambdas! Lambdas! Lambdas! Lambdas! …”

If you hadn’t heard, Visual Studio 2015 will support the use of lambda expressions in the debugger windows.

We’re all very excited to deliver on this longstanding TOP customer request. When LINQ was introduced in 2008 it was a game changer for the way .NET developers think about and code with data. So, to finally be able to use these powerful coding constructs with the Visual Studio debugger is a match made in Redmond.

But wait. There’s more!

The new expression evaluators (the language-specific components that enable you to run snippets of code in various debugger contexts) are the culmination of years of collaboration between the Managed Languages and Visual Studio Debugger teams, and a prime example of why the “Roslyn” project has been such an important investment to the future of VB and C#. But they’re not the only things we’ve been working on. We’re still working very hard to enable Edit and Continue in and around lambda and query expressions, and inside of Async and iterator methods (which requires deep collaboration between the VB/C# team, the VS debugger team, and the CLR team to enable) and we’ll tell you more about how that’s going in a future post 🙂

The road behind and the road ahead

Visual Studio has always had a world class debugging experience with tools like the Watch and Immediate windows, and conditional breakpoints. And since then we’ve only made it better with additions such as Design-Time Expression Evaluation and Edit and Continue. In parallel, the Visual Basic and C# languages have increased in expressiveness with each release, often in ways not even dreamed of when we initially built many of the foundational components of the debugger.

For example, the introduction of a query expression, lambda expression, yield statement, or await expression can result in the body of a method being fundamentally rewritten and even whole new methods and types being created behind the scenes. This is all mostly hidden from the developer but the debugger has to understand everything. And in the case of Edit and Continue or the expression evaluators the debugger must actually understand how to execute that rewrite on the fly. The gulf in understanding and capability between the debugger and the compiler has meant that with each release the sets of language features you can use/manipulate at design-time and at debug time have grown further apart.

But, I’m proud to say, that all changes with Visual Studio 2015.

We’ve rebuilt the expression evaluators on top of the “Roslyn” compilers to ensure they understand modern language constructs, and with the capability to execute exotic IL transformations that they simply weren’t able to before. We’re also rebuilding Edit and Continue to similarly leverage the “Roslyn” compilers to enable edits in and around more language constructs.

This doesn’t mean every language feature will work everywhere overnight. There is still work to do to ensure everything is wired together correctly. But, it does mean that the work of plumbing language features through the debugger is a few orders of magnitude smaller than it used to be. And that’s what’s really got me excited! We can build great debugging experiences for existing language features and we can ensure new features have those great experiences out of the box.

The new conditional-access and interpolated string expressions are just two examples of new language features which will work in the debugger windows and with Edit and Continue on Day 1.

Call to action: Spread the word and send us your feedback

Help us shout it from the rooftops “LAMBDAS WORK IN THE DEBUG WINDOWS!” (Tweet it, share it, tell your friends, text your parents). Remember, this is just the beginning! If you haven’t already, download the Visual Studio 2015 Preview and try it out. Send us your feedback about what you like, what you don’t like, and what you’d love to see us enable next.

Warmest regards (and Happy Holidays),

Anthony D. Green
Program Manager
Visual Basic and C# Languages Team