2011-09-03 14 views
7

Yo solía creer que si tenemos una acumulación Debug realmente no importa si:¿Qué difiere cuando la compilación de depuración se ejecuta con depuración y sin depuración?

  1. Nos encontramos con él.
  2. O lo depuramos.

todo sería igual.

Sin embargo, recientemente me encontré con 2 problemas diferentes, donde está claro que algo es diferente cuando el código se acaba de ejecutar, o cuando se depura, incluso si la versión del código es supuestamente la misma. (es decir, Fluent NHibernate cannot load MySql.Data from GAC in debug mode of a test y Npgsql - Specified method is not supported)

Me pregunto ¿cuál es la diferencia entre los dos en .NET 4.0? Comprender qué es diferente probablemente me ayude a resolver los problemas que estoy teniendo porque al menos sabré dónde buscar posibles causas de errores en esos casos diferentes. No entiendo cuando ejecuto las pruebas unitarias, todo es verde, pero cuando intento depurarlas, recibo varias excepciones.

Respuesta

4

El arma de elección para problemas de resolución de montaje es fuslogvw.exe, le muestra dónde buscaba un ensamblaje y qué configuración se usa para indicarle al CLR dónde encontrar el ensamblaje.

Hay un modo de falla secundaria con el tipo de ensamblajes con los que tiene problemas. Estos proveedores de dbase suelen ser contenedores administrados que dependen de archivos DLL no administrados para realizar el trabajo. Windows debe ser capaz de encontrar esos archivos DLL. Eso tiende a fallar si no se copian en un directorio que está en la RUTA o copiado en la misma carpeta que el EXE principal. Lea atentamente las instrucciones de implementación para estas envolturas.

+0

esto debe estar muy cerca de lo que está pasando, gracias. Pero, ¿podría explicar qué es el "modo de falla secundaria" y cuál es el "modo de falla primaria" (si es que existe)? No estoy seguro de si es su manera de decirlo, o ese es un nombre común para mi situación. –

+0

Principal = primer problema probable: configuración incorrecta, del tipo que fuslogvw.exe le mostrará. Secundario = próximo problema probable: DLL Hell. –

1

Al depurar, el tiempo del código será ligeramente diferente, más aún si se sienta las funciones internas son demasiado largas. Entonces, si el código es sensible al tiempo, podría encontrarse con errores extraños. Eso es todo lo que puedo pensar.

+0

sí, yo también en este momento, no lo mencioné, porque lo que estoy experimentando claramente no está conectado a esto de todos modos, y la diferencia es mucho mayor (si sigue las preguntas) –

+0

Esto es cierto, pero dudo NHibernate tiene un montón de código sensible al tiempo. – Phil

+0

No estoy seguro de que ambos problemas estén conectados a nhb con fluidez, uno parece estar relacionado principalmente con npgsql ... significa que ambos pueden estar fallando por diferentes motivos, porque npgsql no tiene nada que ver con GAC (creo) y fue la razón por la que mysql falló –

-1

Hay algunos problemas que hay que tener en cuenta.

1) Como dice codeninja, el orden de las operaciones puede ser diferente si se rompe el código.

2) Los archivos pueden estar en ubicaciones diferentes y las rutas pueden resolverse de manera diferente. Esto es muy importante cuando tiene recursos cargados dinámicamente o donde se crean y copian las DLL en el directorio de un complemento. En depuración, puede cargar accidentalmente el incorrecto.

3) Observar variables en el depurador puede causar una evaluación. Imagine una propiedad que incrementó estúpidamente su campo de respaldo y luego devolvió el valor incrementado.

+0

1) No, si conoce la aplicación de depuración muiltthread, simplemente rompa todos los demás subprocesos al depurar, de modo que solo se depure un subproceso. Esa será la misma secuencia de operaciones, si pones una ruptura en una línea fuente después de conectar a la aplicación en ejecución. –

+0

2) No, simplemente active la opción de depuración para encontrar la coincidencia exacta de la fuente mientras depura –

+0

3) No, simplemente apague la evaluación de propiedades y variables, eliminando los efectos secundarios –

1

La diferencia es que cuando el depurador está conectado, puede detenerse cuando se lanzan excepciones que de otro modo serían atrapadas.

Las opciones "Saltarse cuando las excepciones cruzan AppDomain o límites administrados/nativos (Administrados solamente)" y "Activar solo mi código" en Herramientas/Opciones/Depuración, y las opciones en Depurar/Excepciones ... determinarán en qué excepciones su depurador se romperá cuando se lanza.

+0

desafortunadamente esa configuración ya está desactivada en mi máquina, y probablemente ese sea el valor predeterminado porque no recuerdo haberlo configurado alguna vez. –

+0

¿Tiene algo marcado en Depurar/Excepciones ...? ¿Y tiene Just My Code marcado en Herramientas/Opciones/Depuración? – plodoc

+0

hmm en realidad tenía excepciones de Common Language Runtime (2 casillas de verificación), las he quitado y parece que el problema se ha ido. ¿Porqué es eso? Me gusta más esto que el enfoque fuslogvw. Entiendo un lanzamiento de excepción, no entiendo por qué la prueba falla después de eso, supongo que aún se lanza una excepción, pero dado que no lo estoy rompiendo, ¿obtengo una ruta de ejecución diferente? –

Cuestiones relacionadas