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

Question

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

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

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

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

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

Answer 1

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

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

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

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

bitty.Cast<bool>(), results 

Причина # 2 представляет собой сочетание факторов:

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

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

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

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