What’s up with no edit & continue support for methods with Lambda Expressions(mostly from LINQ queries).
Error 7 Modifying a ‘method’ which contains a lambda expression will prevent the debug session from continuing while Edit and Continue is enabled.
Originally this post was going to be “LINQ Vs. Edit and Continue”, but then I found this article on MSDN saying how it works just fine in Visual Basic. Visual Basic! WTF!!!
The details for VB are a little cagey though:
You can add or remove code before the LINQ statement…. Your Visual Basic debugging experience for non-LINQ code remains the same as it was before LINQ was introduced.
Does this mean if you add or remove code after a LINQ statement it stops edit and continue, or does this mean MSDN needs a better editorial staff? The “before” seems to cast doubt on the statement that “debugging experience for non-LINQ code remains the same ” Not that I really care since I like my languages with curly brackets.
If you want to know what you can’t do in C# edit and continue, read this article. I personally have no interest in what I can’t do. I only want to know when I’ll be able to do it and I couldn’t find any articles on that. I heard from a friend that its not fixed in C# 4.0. 😦
LINQ is too good to give up, but this is really getting annoying.
I’m almost (getting this close) ready to make my own solution, or horrors, switching to VB.
I watched the video about the new Dynamic feature coming in .Net 4.0. Its an interview with Sam Ng and Chris Burrows who are the compiler developers who actually helped design and implement the feature.
They almost lost me when they said it was for interop & COM (features I hope to avoid), but they brought me back when they mentioned it would be helpful with the HTML DOM and Office (features that keep sucking me back in).
They talked about the DLR (dynamic language runtime) which helps with dynamic expressions. Lots of mentions of interop with IronPython & Ruby so we’ll see if this makes those guys happy or is just a red herring.
There’s going to be a dynamic type: its syntactic sugar for object type (I’m in favor of anything sweet). Dynamic type will help the compiler optimize, but the syntax will be the same as usual. This is primarily for COM Interop, Dynamic C#/Reflection, and Office API’s.
Dynamic will allow for working with dynamic objects without all that nasty casting, but you need to know method names in that case, so it sounds like you wont get intellisense :(, and late bound type errors aren’t pretty either. While getting the same error at runtime as you would at compile time sounds good, the bad part is that you’ll get an error at runtime. More debugging…
Another use case is using a dynamic object (essentially an object type) as a parameter and the proper overload being determined at runtime. Oh joy, imagine all the possibilities. Now test them all…
On the other hand, if you really need to do this, it sounds like dynamic will help make things easier without much trouble for the developer. I’m all for that.
I bet one day I’ll use this. I hope I won’t build something embarrassing or that I regret. At least I feel smarter listening to these guys talk.