Почему Visual Studio Debugger не перечисляет BitArray и покажет мне результаты?

Для следующей строки кода С#:

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

Если я оцениваю "битти" в окне "Часы", я не вижу членов коллекции. Если я оцениваю "bitty, results", который должен перечислить IEnumerable и показать результаты, я получаю сообщение "Только перечисляемые типы могут иметь представление результатов", хотя BitArray IS является IEnumerable.

Почему отладчик делает это?

CLARIFICAITON: Я спрашиваю, что происходит внутри анализатора экспрессии VS Debugger, не спрашивая, как просмотреть BitArray в отладчике.

Ответ 1

Просмотр результатов работает только для коллекций, которые удовлетворяют следующим условиям:

Внедрить IEnumerable<T> или IEnumerable (VB.Net работает только для IEnumerable<T>)
Do не реализовать IList, IList<T>, ICollection или ICollection<T> (только ограничение С#)
У нет атрибут DebuggerTypeProxy
System.Core.dll загружается в процесс debugee

В этом случае BitArray реализует как IEnumerable, так и ICollection. Последний дисквалифицирует его от использования с представлением результатов.

Один из способов обойти это - использовать метод расширения Cast. Это дает значение IEnumerable<T>, из которого вы можете использовать представление результатов

bitty.Cast<bool>(), results

Причиной № 2 является комбинация факторов:

Представление результатов было первоначально изобретено для решения очень специфической проблемы: опыт отладки итераторов С# (а также запросов LINQ) был плохим. Просто нет хорошего способа просмотра содержимого IEnumerable<T>.
Вид результатов не является бесплатным и имеет очень конкретные риски. В частности, он будет с нетерпением и синхронно загружать всю коллекцию в память. Это может вызвать проблемы с коллекциями, поддерживаемыми запросами базы данных, чрезвычайно большими или бесконечными коллекциями.
У всех известных типов IList/<T> и ICollection<T> уже есть метод, позволяющий просматривать содержимое

Следовательно, команда С# решила свести к минимуму риск и не добавить IEnumerable<T> к типам, которые, по их мнению, уже хорошо отображаются. VB.Net выбрал другое направление и отобразит его для любого IEnumerable<T>.

Вы можете по праву спросить, как две команды могут просматривать одни и те же данные и принимать различные решения. Это сводится к перспективному и конечному времени. Команда VB.Net очень заинтересовалась предоставлением отличного опыта отладки LINQ. VB.Net имеет долгую историю предоставления богатого опыта отладки + ENC и, следовательно, был более привычным/желающим принять этот тип риска и, кроме того, имел пропускную способность для тестирования. С# был просто более склонным к риску, очень напряженным по расписанию и прагматически решил против него.

Примечание. Моя ранняя путаница в отношении IEnumerable не поддерживается, потому что это фактически случай в оценщике выражения VB. Оценщик выражения С# поддерживает IEnumerable хотя и по приведенным выше правилам.