C# Debugging functions that contain lambda expressions [duplicate]

Question

I have a function with a lambda expression something like:

int maxOccurrences = ( from field in data select field ).Max( f => f.Occurrences )

P.S. I'm sure that there's a nicer / neater / more idiomatic version of the above statement, it might be nice to know what that might be, although its not important to the question!

If I modify anything else within the function whilst debugging say a Console.Write expression, the debugger states:

Modifying a 'method' which contains a lambda expression will prevent the debug session from continuing while Edit and Continue is enabled.

I was wondering why this might be the case?

I would have thought that the IL generated for the lamba function and the Console.Write statement would be separate and that the Debugger could alter and modify when necessary. Is there some fundamental concept that I'm missing concerning the lamda functionality?

Answer 1

It isn't that it would be impossible to achieve in all cases (I don't think). It would be a monster feature to develop, though.

When you've got LINQ syntax in your method, generally that involves some anonymous method either behind-the-scenes:

// This LINQ query...
var fields = from field in data select field;

// ...is equivalent to this:
var fields = data.Select(f => f);

...or just flat-out in front of the scenes (as in your example):

( from field in data select field ).Max( f => f.Occurrences ) // <- lambda

An anonymous method in turn gets compiled into a type with instance methods to support the code you've written.

In the example above, consider the f => f.Occurrences lambda. This gets compiled into a type with a single instance field whose type is that of the local f in that lambda; this type contains a method that returns f.Occurrences.

So when the code ultimately enumerates over the result of your LINQ query, what's happening is that an instance of this compiler-generated type is being constructed for every field in data and that type's single method which has been generated to support the f => f.Occurrences lambda expression is being called to calculate Max.

The issue with edit-and-continue is that if there's any change to the lambda expressions in the method being edited, this necessitates changing the types generated, which is not an option. One would think this could still be done in the case where nothing is altered about the lambda expressions themselves; as long as the same locals are captured and the anonymous methods are unchanged, it should be feasible to modify a method with these characteristics while debugging just as it is for "normal" methods in VS.

But as you can see, the type generation used to support anonymous methods in general and therefore LINQ queries specifically adds a great deal of complexity to the edit-and-continue process, and in many cases makes it impossible (since it requires changing generated types completely).

I think it was just decided that it wasn't worth the development cost to even bother trying to support this behavior in the limited scenarios where it could hypothetically work.

Answer 2

Or you can simply move to Visual Studio 2015 :)

The "Edit and Continue" feature in VS 2015 allows editing methods with lambda expressions.

You can read about it in more detail here:

http://blogs.msdn.com/b/visualstudioalm/archive/2015/04/29/net-enc-support-for-lambdas-and-other-improvements-in-visual-studio-2015.aspx