Lanzamiento de la generación de archivos .pdb, ¿por qué?

264

¿Por qué Visual Studio 2005 genera los .pdbarchivos al compilar en la versión? No voy a depurar una versión de lanzamiento, entonces, ¿por qué se generan?

m.edmondson
fuente
18
¿Por qué generar pdb en realease? Entonces, cuando llega un informe de bloqueo desde la naturaleza, tiene información para depurarlo. El otro valor es que los clientes pueden depurarlo cuando el autor original no lo haga.
Ian Boyd
@IanBoyd: La segunda oración de ese comentario implica que despliegas los PDB. Esto en la gran mayoría de los casos no es deseable.
Inspeccionable el
3
@II Inspectable O es deseable
Ian Boyd
@IanBoyd: La gran mayoría de los casos no incluye implementaciones de SO. Además, esos PDB no contienen símbolos privados, que se incluyen por defecto, cuando genera PDB.
Inspectable
@IInspectable Por otro lado, es deseable liberar PBD . Idealmente, sí, todos escribirían código compilado en IL, para que podamos obtener la información del símbolo nosotros mismos. Pero los compiladores de código nativo aún no tienen una manera fácil de admitir la depuración en el campo.
Ian Boyd

Respuestas:

416

Porque sin los archivos PDB, sería imposible depurar una compilación "Release" por otra cosa que no sea la depuración a nivel de dirección. Las optimizaciones realmente hacen un número en su código, lo que hace que sea muy difícil encontrar al culpable si algo sale mal (por ejemplo, se produce una excepción). Incluso establecer puntos de interrupción es extremadamente difícil, porque las líneas de código fuente no pueden coincidir uno a uno con (o incluso en el mismo orden que) el código de ensamblaje generado. Los archivos PDB lo ayudan a usted y al depurador, lo que facilita significativamente la depuración post-mortem.

Usted señala que si su software está listo para su lanzamiento, debería haber hecho toda su depuración para entonces. Si bien eso es cierto, hay un par de puntos importantes a tener en cuenta:

  1. Usted debe también probar y depurar la aplicación (antes de que lo suelte) utilizando la "liberación" de generación. Esto se debe a que activar las optimizaciones (están deshabilitadas de forma predeterminada en la configuración "Depurar") a veces puede provocar errores sutiles que de otro modo no se detectarían. Cuando realice esta depuración, querrá los símbolos PDB.

  2. Los clientes informan con frecuencia casos extremos y errores que solo surgen en condiciones "ideales". Estas son cosas que son casi imposibles de reproducir en el laboratorio porque dependen de una configuración poco convencional de la máquina de ese usuario. Si son clientes particularmente útiles, informarán la excepción que se produjo y le proporcionarán un seguimiento de la pila. O incluso le permitirán tomar prestada su máquina para depurar su software de forma remota. En cualquiera de esos casos, querrás que los archivos PDB te ayuden.

  3. La creación de perfiles siempre debe realizarse en las versiones "Release" con las optimizaciones habilitadas. Y una vez más, los archivos PDB son útiles, ya que permiten que las instrucciones de ensamblaje que se perfilan se vuelvan a asignar al código fuente que realmente escribió.

No puede volver atrás y generar los archivos PDB después de la compilación. * Si no los crea durante la construcción, ha perdido su oportunidad. No hace daño nada crearlos. Si no desea distribuirlos, simplemente puede omitirlos de sus archivos binarios. Pero si luego decides que los quieres, no tienes suerte. Es mejor siempre generarlos y archivar una copia, en caso de que los necesite.

Si realmente quieres desactivarlos, siempre es una opción. En la ventana Propiedades de su proyecto, configure la opción "Información de depuración" en "ninguna" para cualquier configuración que desee cambiar.

Sin embargo, tenga en cuenta que las configuraciones "Debug" y "Release" utilizan de manera predeterminada diferentes configuraciones para emitir información de depuración. Deberá mantener esta configuración. La opción "Información de depuración" está configurada como "completa" para una compilación de depuración, lo que significa que, además de un archivo PDB, la información del símbolo de depuración está incrustada en el ensamblado. También obtienes símbolos que admiten funciones interesantes como editar y continuar. En el modo Release, se selecciona la opción "pdb-only", que, como parece, incluye solo el archivo PDB, sin afectar el contenido del ensamblado. Por lo tanto, no es tan simple como la mera presencia o ausencia de archivos PDB en su /bindirectorio. Pero suponiendo que use la opción "pdb-only", el archivo PDB '

* Como Marc Sherman señala en un comentario , siempre que su código fuente no haya cambiado (o puede recuperar el código original de un sistema de control de versiones), puede reconstruirlo y generar un archivo PDB coincidente. Al menos, por lo general. Esto funciona bien la mayor parte del tiempo, pero no se garantiza que el compilador genere binarios idénticos cada vez que compila el mismo código , por lo que puede haber diferencias sutiles. Peor aún, si ha realizado alguna actualización a su cadena de herramientas mientras tanto (como aplicar un paquete de servicio para Visual Studio), es menos probable que los PDB coincidan. Para garantizar la generación confiable de ex postfactoPara los archivos PDB, necesitaría archivar no solo el código fuente en su sistema de control de versiones, sino también los archivos binarios de toda su cadena de herramientas de compilación para garantizar que pueda recrear con precisión la configuración de su entorno de compilación. No hace falta decir que es mucho más fácil simplemente crear y archivar los archivos PDB.

Cody Gray
fuente
19
"No se pueden generar los archivos PDB después de la compilación". - Si su código fuente no ha cambiado, puede reconstruirlo para generar un PDB utilizable después del hecho. Por defecto, windbg no cargará este PDB, pero puede forzarlo a cargar especificando la opción / i de esta manera .reload /i foo.dll. Eso cargará foo.pdb incluso si se creó foo.pdb después de lanzar foo.dll.
Marc Sherman
Noté que cada nueva compilación tiene un resumen de hash diferente, por lo que hay ligeras variaciones con cada compilación, incluso en el mismo entorno. ¿Podrían las direcciones de los PDB no cambiar con la variación, de ahí la necesidad de mantener el PDB de esa compilación? Solo pongo esto como una idea, ya que realmente no entiendo cómo funcionan los PDB o por qué cambian los hash entre las compilaciones.
thebunnyrules
1
@the En la nota al pie, hice un enlace a un artículo que explica que "el compilador C # por diseño nunca produce el mismo binario dos veces. El compilador C # incorpora un GUID recién generado en cada ensamblaje, cada vez que lo ejecuta, asegurando así que no haya dos ensamblajes siempre son idénticos bit por bit ". Eso explica por qué tiene un hash diferente y, por lo tanto, un archivo PDB diferente. Esto se puede solucionar con un editor hexadecimal, pero no es fácil de usar. Y también fuera del alcance de esta respuesta.
Cody Gray
3
Hay una nueva característica en Roslyn llamada compilaciones deterministas. "El indicador / determinista hace que el compilador emita exactamente el mismo EXE / DLL, byte por byte, cuando recibe las mismas entradas". Lo que esto significa es que un proyecto originalmente compilado con este indicador, se puede volver a compilar exactamente en el mismo binario, siempre que el código que está compilando sea el mismo. Una explicación más larga se puede encontrar en las construcciones deterministas en Roslyn
K Smith
92

PDB se puede generar Releasetanto como para Debug. Esto se establece en (en VS2010 pero en VS2005 debe ser similar):

Proyecto → Propiedades → Compilación → Avanzado → Información de depuración

Solo cámbialo a None.

Aliostad
fuente
2
¿Pero por qué harías eso? Si el software está listo para su lanzamiento a continuación, debe ha hecho toda su depuración para entonces
m.edmondson
44
Porque puedes depurar los problemas de producción. Una vez tuvimos que hacerlo.
Aliostad
21
La ventaja de encabezar PDB para el código de producción es que .NET usará estos archivos cuando arroje excepciones. Genera trazas de pila con nombres de archivo y números de línea, ¡lo cual a menudo es muy útil!
Steven
66
@ M. Edmondson: Sí, eso es correcto. Todavía se le informará cuál es la excepción lanzada era (como FileNotFoundException), pero usted no será capaz de ver un seguimiento de pila. Eso hace que sea muy difícil precisar exactamente qué línea de código provocó la excepción.
Cody Gray
2
@ m.edmondson Solo para agregar si está buscando una herramienta para depurar remotamente uno de los problemas en sus cuadros de producción, Windows SDK viene con una herramienta muy famosa llamada WinDbg que admite la depuración remota. Por favor, eche un vistazo al enlace mencionado a continuación. ¡Espero que esto ayude! msdn.microsoft.com/en-in/library/windows/hardware/…
RBT
8

Sin los archivos .pdb es prácticamente imposible pasar por el código de producción; debe confiar en otras herramientas que pueden ser costosas y lentas. Entiendo que puedes usar el rastreo o windbg, por ejemplo, pero realmente depende de lo que quieras lograr. En ciertos escenarios, solo desea pasar por el código remoto (sin errores ni excepciones) utilizando los datos de producción para observar un comportamiento particular, y aquí es donde los archivos .pdb son útiles. Sin ellos ejecutar el depurador en ese código es imposible.

usuario1714880
fuente
7

¿Por qué estás tan seguro de que no depurarás las versiones de lanzamiento? A veces (con suerte, raramente, pero sucede) puede recibir un informe de defectos de un cliente que no es reproducible en la versión de depuración por alguna razón (diferentes tiempos, pequeños comportamientos diferentes o lo que sea). Si ese problema parece ser reproducible en la versión de lanzamiento, estará feliz de tener el pdb correspondiente.

jdehaan
fuente
55
@ m.edmondson Obtenga acceso a la máquina remota utilizando RDP, Webex, etc. e instale windbg allí. Configura tu ruta de símbolos y bam, ¡eres dorado!
Marc Sherman
Un enlace a una guía más detallada hubiera sido más útil. Este tutorial de una línea podría llevar a las personas (como yo) por el camino equivocado. La mayoría de los desarrolladores de .NET no sabrán nada sobre Windbg, por ejemplo.
nuzzolilo
1
@ m.edmondson: algunas ediciones de Visual Studio tienen la capacidad de realizar depuración remota. Desde el menú de depuración se "adjunta al proceso" en la máquina remota.
Mateo
¿Es una buena idea depurar remotamente una instancia de aplicación de producción? ¿No romperá la ejecución paralela de subprocesos y los obligará a ejecutarse en serie durante la depuración?
Kaveh Hadjari
4

Además, puede utilizar volcados de memoria para depurar su software. El cliente se lo envía y luego puede usarlo para identificar la versión exacta de su fuente, y Visual Studio incluso extraerá el conjunto correcto de símbolos de depuración (y la fuente si está configurado correctamente) utilizando el volcado por caída. Consulte la documentación de Microsoft en las tiendas de símbolos .

rlranft
fuente
2

El archivo .PDB es el nombre corto de "Base de datos del programa". Contiene la información sobre el punto de depuración para el depurador y los recursos que se utilizan o de referencia. Se genera cuando construimos como modo de depuración. Permite a la aplicación depurar en tiempo de ejecución.

El tamaño es el aumento del archivo .PDB en modo de depuración. Se utiliza cuando estamos probando nuestra aplicación.

Buen artículo de archivo pdb.

http://www.codeproject.com/Articles/37456/How-To-Inspect-the-Content-of-a-Program-Database-P

Ajay2707
fuente
1
"No es necesario este archivo cuando se lanza o implementa", excepto cuando alguien experimenta un bloqueo en esa versión lanzada, y el informe de bloqueo que obtiene de ellos no contiene un seguimiento de pila utilizable ... entonces deseará haberlo incluido después todas.
Nyerguds
No es verdad. Sin archivos .pdb obtendrá un seguimiento completo de la pila, pero sin nombres de archivos fuente. Puede recuperarlo internamente después de recibir el informe de bloqueo. Si le preocupan sus derechos intelectuales y ofusca las fuentes, debe guardar los archivos .pdb pero no desplegarlos.
TOP KEK
1

En una solución multiproyecto, generalmente desea tener una configuración que no genere archivos PDB o XML. En lugar de cambiar la Debug Infopropiedad de cada proyecto a none, pensé que sería más conveniente agregar un evento posterior a la compilación que solo funciona en una configuración específica.

Desafortunadamente, Visual Studio no le permite especificar diferentes eventos posteriores a la compilación para diferentes configuraciones. Así que decidí hacer esto manualmente, editando el csprojarchivo del proyecto de inicio y agregando lo siguiente (en lugar de cualquier PostBuildEventetiqueta existente ):

  <PropertyGroup Condition="'$(Configuration)' == 'Publish'">
    <PostBuildEvent>
        del *.pdb
        del *.xml
    </PostBuildEvent>
  </PropertyGroup>

Desafortunadamente, esto hará que el cuadro de texto del evento posterior a la construcción esté en blanco y poner cualquier cosa en él puede tener resultados impredecibles.

GregRos
fuente
44
Esto eliminará TODOS los *.xmlarchivos, tenga cuidado con eso.
Mariusz Jamro
0

Los archivos de símbolos de depuración ( .pdb) y XML doc ( .xml) constituyen un gran porcentaje del tamaño total y no deberían formar parte del paquete de implementación normal. Pero debería ser posible acceder a ellos en caso de que sean necesarios.

Un enfoque posible: al final del proceso de compilación de TFS, muévalos a un artefacto separado.

Mark Johanes
fuente
-1

En realidad, sin los archivos PDB y la información simbólica que tienen, sería imposible crear un informe de bloqueo exitoso (archivos de volcado de memoria) y Microsoft no tendría la imagen completa de lo que causó el problema.

Y así tener PDB mejora los informes de fallas.

prosti
fuente
Pero, ¿qué faltará exactamente sin archivos .pdb?
TOP KEK
No puede generar los archivos PDB después de la compilación. Por lo tanto, todas las versiones del software major.minor [.build [.revision]] deberían haberse guardado en Microsoft para comprender correctamente lo que sucedió, pero esto no es todo.
prosti
No se garantiza que el compilador genere binarios idénticos cada vez que compila el mismo código.
prosti
La pregunta era qué faltaría en los informes de fallos y cómo se verían afectados los informes de fallos. Los archivos .NET pdb contienen solo nombres de variables privadas y nombres de archivos fuente. Todo lo demás (nombres de métodos, firmas, etc.) estará en stacktrace desde la información de metadatos.
TOP KEK
Ningún archivo PDB también contiene datos no privados: github.com/microsoft/microsoft-pdb .
prosti