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

Recientemente, he estado depurando parte de mi código de Noda Time , y he notado que cuando tengo una variable local de tipo NodaTime.Instant(uno de los structtipos centrales en Noda Time), las ventanas "Locals" y "Watch" no parece llamar a su ToString()anulación. Si llamo 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, DemoStructera una clase y DemoClassno existía en absoluto, es mi culpa, pero explica algunos comentarios que ahora parecen extraños ...)

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 Thread.Sleepllamada de 1 segundo a 900 ms, todavía hay una breve pausa, pero luego veo Class: Fooel valor. No parece importar cuánto tiempo Thread.Sleepesté la llamada DemoStruct.ToString(), siempre se muestra correctamente, y el depurador muestra el valor antes de que la suspensión se haya completado. (Es como si estuviera Thread.Sleepdeshabilitado).

Ahora Instant.ToString()en Noda Time hace una buena cantidad de trabajo, pero ciertamente no lleva un segundo entero, por lo que presumiblemente hay más condiciones que hacen que el depurador deje de evaluar una ToString()llamada. 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 por completo Instant.ToString()? Como se señala a continuación, DebuggerDisplayAttributeparece ayudar, pero sin saber por qué , nunca tendré plena confianza en cuándo lo necesito y cuándo no.

Actualizar

Si lo 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 alguna condición que DebuggerDisplayAttribute se impone, a pesar de que no se impone durante los tiempos de espera. (Esto estaría en línea con mi expectativa de que Instant.ToStringsea ​​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. Creemos una clase que contenga una Instanty la use para su propio ToString()método:

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 InstantWrapperpara ser una estructura, obtengo:

instant    {NodaTime.Instant}
wrapper    {InstantWrapper}

Por lo tanto, puede evaluar Instant.ToString(), siempre que sea invocado por otro ToStringmétodo ... 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.

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 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 ToStringfunción, 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 ToString, no podemos porque el valor no existe en el proceso. Para intentar obtener el valor, necesitamos emular la ejecución deToStringmétodo. 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 la implementación de ToString no puede ser emulada por el depurador como se describió anteriormente.
2. Thread.Sleepparece tomar tiempo cero cuando se lo llama ToStringen una estructura -> Esto se debe a que el emulador se 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()")trabajos. -> Eso es confuso. La única diferencia entre la llamada implícita de ToStringy DebuggerDisplayes que los tiempos de espera de la ToString evaluación implícita deshabilitarán todas las ToStringevaluaciones implícitas para ese tipo hasta la próxima sesión de depuración. Puedes estar observando ese comportamiento.

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

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