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

¿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?

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.}

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.

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.

¿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.

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 .

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

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.

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.

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.