Why won't Visual Studio Debugger enumerate a BitArray and show me the results?

Question

For the following line of C# code:

BitArray bitty = new BitArray(new[] {false, false, true, false});

If I evaluate \"bitty\" in the Watch windo

Answer 1

The results view only works for collections which meet the following conditions:

1. Implement IEnumerable<T> or IEnumerable (VB.Net only works for IEnumerable<T>)
2. Do not implement IList, IList<T>, ICollection or ICollection<T> (C# restriction only)
3. Do not have a DebuggerTypeProxy attribute
4. System.Core.dll is loaded in the debugee process

In this case BitArray implements both IEnumerable and ICollection. The latter disqualifies it from being used with the results view.

One way to work around this is to use the Cast extension method. This produces an IEnumerable<T> value from which you can use the results view

bitty.Cast<bool>(), results

The reason for #2 is a combination of factors:

• The Results view was originally invented to solve a very specific problem: the debugging experience of C# iterators (and by extension LINQ queries) was poor. There was simply no good way to view the contents of the IEnumerable<T>.
• The Results view is not free and does have very specific risks. In particular it will eagerly and synchronously load the entire collection into memory. This can cause issues with collections backed by database queries, extremely large or infinite collections
• Every known IList/<T> and ICollection<T> type already have a method that let you view the contents

Hence the C# team decided to minimize risk and not add IEnumerable<T> to types which they felt already displayed well. VB.Net chose the other direction and will display it for any IEnumerable<T>.

You might rightfully ask how two teams could look at the same data and make different decisions. It comes down to perspective and of course time. The VB.Net team was very keen on providing a great LINQ debugging experience. VB.Net has a long history of providing a rich debugging + ENC experience and hence was more accustomed / willing to take this type of risk on and additionally had the bandwidth to test it. C# was simply more risk averse, very tight on the schedule and pragmatically decided against it.

Note: My earlier confusion about IEnumerable not being supported is because that's actually the case in the VB expression evaluator. The C# expression evaluator does support IEnumerable though and by the above rules.