The reason this happens is a consequence of how the debugger works. When a value is expanded it essentially enumerates the members and display the values as child nodes. This is great for most types of objects where the members hold the mots interesting data. For collections though it’s often far more interesting to see the elements in the collection.
Most collection types don’t have this issue because they are either custom handled by the expression evaluator, arrays for example, or use a debugger type proxy helper class (Dictionary<TKey,TValue>, List
The languages team realized this was a problem and added a debugger feature in Visual Studio 2008 to help: the ‘Results View’ node. When an expression appears in the locals or watch window which is typed to IEnumerable
This display is much better because it’s actually showing me the elements in the IEnumerable
Astute readers may be wondering at this point why this doesn’t work for F# out of the box. After all F#’s seq
Developers can get this experience in F# by forcing System.Core.dll into the debugee process. My favorite trick is to add the following line at the start of my F# applications.
#if DEBUG System.Linq.Enumerable.Count() |> ignore #endif
This forces System.Core.dll into the process in debug builds which results in a much nicer display for any seq
When I originally posted this solution to a question on StackOverflow, Tim Robinson pointed out that it’s possible to force System.Core.dll into the debugee process without adding extra debug code to the process. Simply use the Assembly.Load API to do it by evaluating the following expression in the watch window.
System.Reflection.Assembly.Load(“System.Core, Version=18.104.22.168, Culture=neutral, PublicKeyToken=b77a5c561934e089, processorArchitecture=MSIL”
I still prefer my solution but this is a great trick to have if developers are in a situation where they can’t edit the code. Such as debugging in a production environment.