Tengo una aplicación VB.net. Actualmente, la versión de lanzamiento de la aplicación se produce sin un archivo PDB. Esto me da registros de errores que carecen de detalles útiles, como números de línea. Estoy buscando incluir los archivos PDB con compilaciones futuras pero me gustaría saber cuáles son las ventajas y desventajas de esto (rendimiento, tamaño, seguridad de código)Ventajas y desventajas de incluir archivos PDB con su aplicación de lanzamiento
Cuando despliega sus símbolos de depuración para En su aplicación, es muy fácil que alguien venga y haga ingeniería inversa en su trabajo, algo que algunas personas consideran indeseable. Del mismo modo, debe desplegar más archivos y su proyecto desplegable se hace más grande. Los propios archivos PDB no hacen que la aplicación sea más lenta, ya que el envío de un PDB no siempre excluye el abandono de las optimizaciones (solo hay que tener cuidado: la configuración predeterminada del proyecto "Depurar" tiende a no optimizar sus resultados cuando generar PDB).
sé que voy a conseguir una paliza por esto, pero ...
Estoy de acuerdo con Dave Markle, pero me gustaría añadir que una ventaja de la publicación de los archivos PDB es, como bien dice , MUY bueno para la depuración.
Dicho esto, no vendo software, y el código que escribo es para uso interno en nuestra compañía. En este contexto, no veo un problema para poner código de depuración en producción, junto con los archivos PDB. Nunca he visto un golpe de rendimiento, y honestamente, nuestros usuarios rara vez nos dan la información correcta si se encuentran con excepciones no controladas. Por supuesto, tratamos de manejar las excepciones correctamente, pero como usted sabe, los errores ocurrirán. Nuestra estrategia es agregar un manejador de excepción global a TODOS los proyectos y registrar esos eventos en la base de datos. Estos errores contienen los números de línea porque incluimos los archivos de depuración y, como resultado, podemos identificar y reaccionar rápidamente al código incorrecto, arreglarlo y obtener más aplicaciones libres de errores. Para mí (y para nuestros usuarios) este es un GRAN beneficio del que no me gustaría prescindir.
Así que si estás en una situación similar, digo olvida la postura oficial (en este caso) y sigue publicando los archivos pdb con UNA advertencia importante.
Asegúrese de que cualquier aplicación web que implemente con los archivos PDB, esté completamente seguro de que TODAS las excepciones se manejan correctamente, y no expone inadvertidamente las líneas de código en una página de error Asp.NET estándar.
Me parece útil tener también información de depuración creada para la versión de lanzamiento - ayuda a detectar errores. No hace que el programa se ejecute más lento. Pero no debe enviar el archivo PDB con su aplicación, si no desea que otros puedan realizar una ingeniería inversa más fácilmente. Solo déselo a los evaluadores.
La aplicación es una aplicación intencional. Solo se usará dentro de nuestra compañía.Las restricciones de usuario impiden que los usuarios puedan revertir el proceso de nuestro código – zeocrash
Crea pdbs para tu compilación de lanzamiento, pero no los envíes. Mantenga los pdbs en un lugar seguro con la compilación y el código fuente correspondientes. Si obtiene un bloqueo en vivo, o similar, puede usar los pdbs para realizar la depuración post-mortem usando el Debugging Tools for Windows o Visual Studio.
Intentamos mantener todas las excepciones manejadas. Entonces no hacemos la depuración post mortem. En las excepciones manejadas, registramos el seguimiento de la pila en la base de datos – zeocrash
La depuración post mortem también es útil cuando no se lanzan excepciones, por ejemplo, si su aplicación se cuelga. Puede capturar un mini volcado del proceso bloqueado y luego depurarlo de forma remota utilizando los pdbs y el código fuente. – Polyfun
¿Qué intenta exactamente lograr con los archivos PDB? A menos que ofusque el código, ya tiene buenos rastreos de pila con el código administrado (y supondría que el PDB hace que la ofuscación sea inútil de todos modos ...). La única ventaja que obtienes son los símbolos "ocultos" como locales y nombres de parámetros. – Krumelur
Drats. Me gusta esta pregunta, pero ya se ha preguntado aquí: http://stackoverflow.com/questions/1307482/whats-the-risk-of-deploying-debug-symbols-pdb-file-in-a-production-environment – David
Los nombres de parámetros y números de línea son muy útiles. Nuestra aplicación, es muy grande, construida por varios desarrolladores diferentes en varias versiones diferentes de VB. Actualmente tenemos el nombre de los procedimientos en la pila, pero sería bueno tener un poco más de datos. – zeocrash