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

Recientemente, he estado depurando algunos de mis códigos 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 inspección, veo la representación adecuada, pero de lo contrario, solo veo:

variableName       {NodaTime.Instant}

que no es muy útil.

Si cambio la anulación para devolver una cadena constante, la cadena se muestra en el depurador, por lo que claramente puede 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, 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 está la Thread.Sleepllamada DemoStruct.ToString(), siempre se muestra correctamente y el depurador muestra el valor antes de que se complete la suspensión. (Es como si estuviera Thread.Sleepdiscapacitado).

Ahora Instant.ToString()en Noda Time hace bastante trabajo, pero ciertamente no toma 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.

Intenté volver a ver si es un límite de pila, pero parece que no es el caso.

Entonces, ¿cómo puedo averiguar qué impide que VS realice una evaluación completa Instant.ToString()? Como se indica a continuación, DebuggerDisplayAttributeparece ayudar, pero sin saber por qué , nunca voy a estar completamente seguro de 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, aunque no obliga a superar 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 suficientemente buena, pero aún 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 tipos de valores en Noda Time.

Más curioso y más curioso

Lo que sea que confunda al depurador solo lo confunde a veces. Creemos una clase que contenga un Instanty lo 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, por sugerencia de Eren en los comentarios, si cambio InstantWrapperpara ser una estructura, obtengo:

instant    {NodaTime.Instant}
wrapper    {InstantWrapper}

Entonces 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 se debe ejecutar para obtener el resultado.

Como otro ejemplo de esto, si usamos:

object boxed = NodaConstants.UnixEpoch;

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

Actualizar:

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

Respuesta original:

Se encuentra con una limitación de error / diseño conocida con Visual Studio 2015 y llama 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 subprocesos del proceso excepto el subproceso actual, cambia el contexto del subproceso 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 completar la ventana.

Para admitir expresiones lambda, tuvimos que reescribir completamente CLR Expression Evaluator 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 alguna instrucción de "llamada", el depurador ejecuta una evaluación de función como se describe arriba.
4. El depurador / roslyn toma este resultado y lo formatea en la vista en forma 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 existen realmente en el proceso que se está depurando. Los valores falsos solo existen en el proceso de depuración. Para implementar la semántica de estructura adecuada, el depurador siempre necesita hacer una copia del valor cuando empuja un valor de estructura a la pila de IL. El valor copiado ya no es un valor "real" y ahora solo existe en el proceso de depuración. 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 del ToStringmé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á viendo:

1. El depurador no está evaluando NodaTime.Instant.ToString-> Esto se debe a que es un tipo de estructura y el depurador no puede emular la implementación de ToString como se describe anteriormente.
2. Thread.Sleepparece tomar cero tiempo cuando es llamado por ToStringuna 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 intentar obtener un valor para mostrárselo 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 cualquier tiempo de espera de la ToString evaluación implícita deshabilitará todas las ToStringevaluaciones implícitas 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.

Con suerte, eso aclara las cosas. Avísame si tienes más preguntas. :-)