c# - subprocesos - ¿Qué hace que el depurador de Visual Studio deje de evaluar una anulación de ToString?

la evaluación de la función requiere que se ejecuten todos los subprocesos entity framework

Question

Entorno: Visual Studio 2015 RTM. (No he probado versiones anteriores).

Recientemente, he estado depurando parte de mi código Noda Time , y me di cuenta de que cuando tengo una variable local de tipo NodaTime.Instant (uno de los tipos de struct centrales en Noda Time), los "Locales" y Las ventanas "Watch" no parecen llamar a su ToString() . Si llamo a ToString() explícitamente en la ventana de observación, veo la representación apropiada, pero de lo contrario solo veo:

variableName {NodaTime.Instant}

lo cual no es muy útil

Si cambio la anulación para devolver una cadena constante, la cadena se muestra en el depurador, por lo que es claramente capaz de detectar que está allí, simplemente no quiere usarla en su estado "normal".

Decidí reproducir esto localmente en una pequeña aplicación de demostración, y esto es lo que se me ocurrió. (Tenga en cuenta que en una versión anterior de esta publicación, DemoStruct era una clase y DemoClass no existía en absoluto, es mi culpa, pero explica algunos comentarios que parecen extraños ahora ...)

using System;
using System.Diagnostics;
using System.Threading;
public struct DemoStruct
{
public string Name { get; }
public DemoStruct(string name)
{
Name = name;
}
public override string ToString()
{
Thread.Sleep(1000); // Vary this to see different results
return $"Struct: {Name}";
}
}
public class DemoClass
{
public string Name { get; }
public DemoClass(string name)
{
Name = name;
}
public override string ToString()
{
Thread.Sleep(1000); // Vary this to see different results
return $"Class: {Name}";
}
}
public class Program
{
static void Main()
{
var demoClass = new DemoClass("Foo");
var demoStruct = new DemoStruct("Bar");
Debugger.Break();
}
}

En el depurador, ahora veo:

demoClass {DemoClass}
demoStruct {Struct: Bar}

Sin embargo, si reduzco la llamada Thread.Sleep de 1 segundo a 900ms, todavía hay una breve pausa, pero luego veo Class: Foo como el valor. No parece importar cuánto tiempo la llamada Thread.Sleep esté en DemoStruct.ToString() , siempre se muestra correctamente, y el depurador muestra el valor antes de que el sueño se haya completado. (Es como si Thread.Sleep está desactivado).

Ahora Instant.ToString() en Noda Time hace una buena cantidad de trabajo, pero ciertamente no toma un segundo completo, por lo que presumiblemente hay más condiciones que hacen que el depurador deje de evaluar una llamada ToString() . Y, por supuesto, es una estructura de todos modos.

He intentado recurrir para ver si es un límite de pila, pero ese no parece ser el caso.

Entonces, ¿cómo puedo averiguar qué impide que VS evalúe completamente Instant.ToString() ? Como se señala a continuación, DebuggerDisplayAttribute parece ayudar, pero sin saber por qué , nunca tendré plena confianza en cuándo lo necesito y cuándo no.

Actualizar

Si uso DebuggerDisplayAttribute , las cosas cambian:

// For the sample code in the question...
[DebuggerDisplay("{ToString()}")]
public class DemoClass

me da

demoClass Evaluation timed out

Mientras que cuando lo aplico en Noda Time:

[DebuggerDisplay("{ToString()}")]
public struct Instant

una aplicación de prueba simple me muestra el resultado correcto:

instant "1970-01-01T00:00:00Z"

Entonces, presumiblemente, el problema en Noda Time es una condición por la que DebuggerDisplayAttribute , a pesar de que no se impone durante los tiempos de espera. (Esto estaría en línea con mi expectativa de que Instant.ToString sea ​​lo suficientemente rápido como para evitar un tiempo de espera).

Esta puede ser una solución lo suficientemente buena, pero aún así me gustaría saber qué está pasando y si puedo cambiar el código simplemente para evitar tener que poner el atributo en todos los diversos tipos de valores en Noda Time.

Más curioso y más curioso

Lo que sea confuso para el depurador solo lo confunde a veces. ToString() una clase que contenga un Instant y lo use para su propio método ToString() :

using NodaTime;
using System.Diagnostics;
public class InstantWrapper
{
private readonly Instant instant;
public InstantWrapper(Instant instant)
{
this.instant = instant;
}
public override string ToString() => instant.ToString();
}
public class Program
{
static void Main()
{
var instant = NodaConstants.UnixEpoch;
var wrapper = new InstantWrapper(instant);
Debugger.Break();
}
}

Ahora termino viendo:

instant {NodaTime.Instant}
wrapper {1970-01-01T00:00:00Z}

Sin embargo, a sugerencia de Eren en los comentarios, si cambio InstantWrapper para que sea una estructura, obtengo:

instant {NodaTime.Instant}
wrapper {InstantWrapper}

Por lo tanto, puede evaluar Instant.ToString() , siempre que sea invocado por otro método ToString ... que está dentro de una clase. La parte de clase / estructura parece ser importante en función del tipo de variable que se muestra, no del código que debe ejecutarse para obtener el resultado.

Como otro ejemplo de esto, si usamos:

object boxed = NodaConstants.UnixEpoch;

... entonces funciona bien, mostrando el valor correcto. Coloreame confundido.

Answer 1

Actualizar:

Este error se ha solucionado en Visual Studio 2015 Update 2. Avíseme si todavía tiene problemas para evaluar ToString en valores de estructura utilizando la Actualización 2 o posterior.

Respuesta original

Se encuentra con una limitación de error / diseño conocida con Visual Studio 2015 y está llamando a ToString en tipos de estructura. Esto también se puede observar cuando se trata de System.DateTimeSpan . System.DateTimeSpan.ToString() funciona en las ventanas de evaluación con Visual Studio 2013, pero no siempre funciona en 2015.

Si está interesado en los detalles de bajo nivel, esto es lo que está sucediendo:

Para evaluar ToString , el depurador hace lo que se conoce como "evaluación de funciones". En términos muy simplificados, el depurador suspende todos los hilos del proceso, excepto el hilo actual, cambia el contexto del hilo actual a la función ToString , establece un punto de interrupción de protección oculto y luego permite que el proceso continúe. Cuando se alcanza el punto de interrupción de la protección, el depurador restaura el proceso a su estado anterior y el valor de retorno de la función se utiliza para llenar la ventana.

Para admitir expresiones lambda, tuvimos que reescribir completamente el Evaluador de expresiones CLR en Visual Studio 2015. En un nivel alto, la implementación es:

1. Roslyn genera código MSIL para expresiones / variables locales para obtener los valores que se mostrarán en las distintas ventanas de inspección.
2. El depurador interpreta el IL para obtener el resultado.
3. Si hay instrucciones de "llamada", el depurador ejecuta una evaluación de la función como se describió anteriormente.
4. El depurador / roslyn toma este resultado y lo formatea en la vista de árbol que se muestra al usuario.

Debido a la ejecución de IL, el depurador siempre está lidiando con una mezcla complicada de valores "reales" y "falsos". Los valores reales realmente existen en el proceso que se está depurando. Los valores falsos solo existen en el proceso del depurador. Para implementar una semántica de estructura adecuada, el depurador siempre necesita hacer una copia del valor al insertar un valor de estructura en la pila IL. El valor copiado ya no es un valor "real" y ahora solo existe en el proceso del depurador. Eso significa que si luego necesitamos realizar una evaluación de la función de ToString , no podemos porque el valor no existe en el proceso. Para intentar obtener el valor, necesitamos emular la ejecución del método ToString . Si bien podemos emular algunas cosas, existen muchas limitaciones. Por ejemplo, no podemos emular código nativo y no podemos ejecutar llamadas a valores delegados "reales" o llamadas a valores de reflexión.

Con todo eso en mente, esto es lo que está causando los diversos comportamientos que estás viendo:

1. El depurador no está evaluando NodaTime.Instant.ToString -> Esto se debe a que es de tipo estructura y el depurador no puede emular la implementación de ToString como se describió anteriormente.
2. Thread.Sleep parece tomar tiempo cero cuando ToString llama en una estructura -> Esto se debe a que el emulador está ejecutando ToString . Thread.Sleep es un método nativo, pero el emulador lo sabe y simplemente ignora la llamada. Hacemos esto para tratar de obtener un valor para mostrar al usuario. Un retraso no sería útil en este caso.
3. DisplayAttibute("ToString()") funciona. -> Eso es confuso. La única diferencia entre la llamada implícita de ToString y DebuggerDisplay es que cualquier tiempo de espera de la evaluación implícita de ToString deshabilitará todas las evaluaciones implícitas de ToString para ese tipo hasta la próxima sesión de depuración. Puede estar observando ese comportamiento.

En términos del problema / error de diseño, esto es algo que estamos planeando abordar en una versión futura de Visual Studio.

Esperemos que eso aclare las cosas. Avísame si tienes más preguntas. :-)