2008-09-02 14 views
36

¿Hay una buena manera de depurar errores en el Diseñador de Visual Studio?Buena manera de depurar errores de Visual Studio Designer

En nuestro proyecto tenemos toneladas de UserControls y muchos formularios complejos. Para los complejos, el Diseñador a menudo arroja varias excepciones que no ayudan mucho, y me preguntaba si hay alguna forma agradable de averiguar qué salió mal.

El lenguaje es C#, y estamos utilizando Visual Studio 2005.

Respuesta

0

Cada uno es diferente y que a veces puede ser oscuro. Como primer paso, haría lo siguiente:

  • Utilice el control de fuente y ahorre a menudo. Cuando se produce un error de diseñador, obtenga una lista de todos los cambios efectuados recientemente en los controles afectados y pruebe cada uno hasta encontrar el culpable
  • Asegúrese de verificar las rutinas de inicialización de los controles involucrados. Muy a menudo estos errores ocurrirán debido a algún error o mala dependencia que se llama a través del constructor predeterminado para un control (un error que solo puede manifestarse en VS)
1

He tenido esto muchas veces y es un verdadero dolor

En primer lugar, sugiero tratar de seguir el rastro de la pila proporcionado por el diseñador, aunque me parece que a menudo simplemente enumera un montón de cosas internas que no son de mucha utilidad.

Si eso no funciona, intente compilar y determinar la excepción desde allí. Realmente estás volando a ciegas, que es el problema. A continuación, puede intentar simplemente ejecutar el código y ver qué excepción se genera al ejecutarlo, eso debería proporcionarle más información.

Un enfoque de última hora podría ser eliminar todo el código no generado del formulario y volver a introducirlo gradualmente para determinar el error.

Si está utilizando controles personalizados, también puede eliminar manualmente el código generado relacionado con los controles personalizados si el método anterior aún produce un error. A continuación, puede volver a introducir este paso a paso de la misma manera para determinar qué control personalizado está causando el problema, luego vaya a depurarlo por separado.

Básicamente, por lo que puedo ver, ¡no hay otra forma de resolver el problema que no sea un poco de esfuerzo!

38

He podido depurar algunos problemas del diseñador de control ejecutando una segunda instancia de VS, luego de su primera instancia VS hago una "Depuración -> Adjuntar al proceso" y selecciono "devenv".

La primera instancia de VS es donde establecerá sus puntos de interrupción. Use la segunda instancia para cargar el diseñador y hacer que se ejecute el código "diseñador".

+0

no se rompe ... – serhio

+0

¡Qué solución más simple! Me encanta, me ayudó mucho. – Mohgeroth

+0

** ¿Por qué utilizar una segunda instancia para hacer que se ejecute el código de diseñador **? No entiendo por qué no comenta el atributo '' en el método 'InitializeComponent()'? –

0

Puede ejecutar una segunda instancia de VS y adjuntarla a la primera instancia de VS (Ctrl + Alt + P). En la primera instancia, configure los puntos de interrupción, en la segunda instancia ejecute el diseñador, y el punto de interrupción se disparará. Puede recorrer el código, pero Editar-y-Continuar no funcionará.

Para que Edit-and-Continue funcione, configure las opciones de depuración de la biblioteca de control para ejecutar un VS con el argumento de línea de comando como el nombre de archivo de la solución.Luego puede simplemente establecer los puntos de interrupción y presionar F5. Se depurará al igual que el código de usuario! Como nota al margen, puede hacer esto también los complementos VS y Office.

+0

"en la segunda instancia ejecute el diseñador, y el punto de interrupción se disparará" ... no se dispara ... – serhio

1

Descubrí por qué a veces los puntos de interrupción no se alcanzan. En el cuadro de diálogo Adjuntar al proceso, el tipo "Adjuntar a:" tiene que ser "Seleccionar ..." 'd.

Una vez que cambié a "Managed 4.0, 4.5", se golpearon los puntos de interrupción para una aplicación WinRT. Fuente: Designer Debugging in WinRT.

2

Ha sido un dolor en 2005 y todavía lo es en 2015. Los puntos de interrupción a menudo no funcionarán, probablemente debido a que el ensamblado está siendo copiado por la sombra o algo por el diseñador (?). Lo mejor que puede hacer es interrumpir manualmente al introducir una llamada al Debugger.Break(). Puede envolverlo en un compilador condicional de la siguiente manera:

#if DEBUG 
    System.Diagnostics.Debugger.Break(); 
#endif 
int line_to = break; // <- if a simple breakpoint here does not suffice 
+0

Pero, ¿es mejor en 2016? ; ^) – Mogsdad

+0

¡Por supuesto! :) ... –

+0

¿Pero es mejor en 2017? De grosor no ... Sigue siendo un error molesto como siempre y no es una forma fácil de resolverlo. Más de un recurso de Microsoft dijo en realidad que "por diseño" están ocurriendo estos errores, y eso es lo más molesto de todo, que Microsoft se niega a reconocerlo como su problema. –

Cuestiones relacionadas