¿Por qué el depurador de Visual Studio no enumerará un BitArray y me mostrará los resultados?

Question

Para la siguiente línea de código C#:

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

Si evalúo "algunas partes están" en la ventana Inspección, no veo los miembros de la colección. Si evalúo "bitty, results", que se supone que enumera el IEnumerable y muestro los resultados, aparece el mensaje "Solo los tipos enumerables pueden tener una vista de resultados", aunque un BitArray ES un IEnumerable.

¿Por qué el depurador hace esto?

CLARIFICAITON: Estoy pidiendo lo que está sucediendo en el interior del Evaluador de Expresión VS depurador, no preguntar cómo ver una BitArray en el depurador ..

Answer 1

los resultados Ver sólo funciona para las colecciones que cumplan las siguientes condiciones:

1. implementar IEnumerable<T> o IEnumerable (VB.Net sólo funciona para IEnumerable<T>)
2. Haz no aplicar IList, IList<T>, ICollection o ICollection<T> (C# única restricción)
3. hacer no tienen un atributo DebuggerTypeProxy
4. System.Core.dll se carga en el proceso depurando un programa que

En este caso BitArray implementa tanto IEnumerable y ICollection . Este último lo descalifica para que no se use con la vista de resultados.

Una forma de evitar esto es utilizar el método de extensión Cast. Esto produce un valor IEnumerable<T> desde donde se puede utilizar la vista de los resultados

bitty.Cast<bool>(), results 

La razón de # 2 es una combinación de factores:

• la vista de resultados fue inventado originalmente para resolver un problema muy específico: la experiencia de depuración de los iteradores de C# (y por extensión de consultas LINQ) fue deficiente. Simplemente no había una buena manera de ver el contenido del IEnumerable<T>.
• La vista de resultados no es gratis y tiene riesgos muy específicos. En particular, cargará ansiosa y sincrónicamente toda la colección en la memoria. Esto puede causar problemas con las colecciones respaldadas por las consultas de bases de datos, extremadamente grandes o infinitas colecciones
• Cada conocido IList/<T> y ICollection<T> tipo ya tienen un método que le permite ver el contenido

ahí la C# equipo decidió minimizar el riesgo y no agregue IEnumerable<T> a los tipos que ya sentían bien mostrados. VB.Net eligió la otra dirección y la mostrará para cualquier IEnumerable<T>.

Puede preguntarse legítimamente cómo dos equipos pueden ver los mismos datos y tomar decisiones diferentes. Todo se reduce a la perspectiva y, por supuesto, al tiempo. El VB.El equipo de red estuvo muy interesado en brindar una excelente experiencia de depuración de LINQ. VB.Net tiene una larga historia de proporcionar una experiencia rica en depuración + ENC y, por lo tanto, estaba más acostumbrada/dispuesta a asumir este tipo de riesgo y, además, tenía el ancho de banda para probarlo. C# fue simplemente más reacio al riesgo, muy ajustado en el cronograma y pragmáticamente decidió no hacerlo.

Nota: Mi confusión anterior sobre IEnumerable no es compatible porque es realmente el caso en el evaluador de expresiones VB. El evaluador de expresiones C# admite IEnumerable y según las reglas anteriores.