microsoft - Visual Studio: información de depuración en la versión de lanzamiento
visual studio installer (4)
Estoy tentado a incluir información de depuración en las compilaciones de lanzamiento que se envían a los clientes. Por lo que veo, el único inconveniente es un aumento del 25% en el tamaño del archivo binario. La ventaja es que puedo obtener un volcado instantáneo de uso, mucho más fácil de analizar. Estoy dispuesto a vivir con el aumento del 25%. ¿Hay alguna otra desventaja que me falta?
Este es un proyecto de C y todo lo que quiero hacer es Vincular / Depurar / Generar información de depuración
De acuerdo con la documentación de VS2005 en http://msdn.microsoft.com/en-us/library/xe4t6fc1(v=vs.80).aspx :
/ DEBUG cambia los valores predeterminados para la opción / OPT de REF a NOREF y de ICF a NOICF (por lo tanto, deberá especificar explícitamente / OPT: REF o / OPT: ICF).
En mi caso me ayudó cuando habilité tanto:
/O2 /DEBUG /OPT:REF /OPT:ICF
El tamaño del ejecutable debería aumentar mucho menos del 25%.
De hecho, me sorprende un poco que aumente mucho, pero algunas pruebas rápidas muestran que al menos un proyecto de ejemplo grande (ScummVM) aumenta el .exe de 10,205,184 bytes a 10,996,224 bytes simplemente agregando la opción /DEBUG al paso del enlace (aproximadamente un aumento del 8%). /DEBUG se especifica mediante la opción "Linker | Debugging | Generate Debug Info" en el IDE. Tenga en cuenta que esta configuración no debería afectar a las optimizaciones generadas por el compilador.
Sé que un puntero al archivo .pdb se coloca en el ejecutable, pero no hay mucho de eso. Experimenté un poco y descubrí que habilitar la opción del enlazador /OPT:NOREF cambió la diferencia de tamaño a 10,205,184 frente a 10,205,696. Por lo tanto, la compilación no /DEBUG mantuvo del mismo tamaño, pero la compilación /DEBUG redujo a solo 512 bytes (lo que podría deberse al puntero a .pdb, tal vez el enlazador redondea a un múltiplo de 512 o algo así). Mucho menos del 1% de aumento. Aparentemente, agregar /DEBUG hace que el enlazador mantenga objetos sin referencia a menos que también especifique /OPT:NOREF . (Opción "Linker | Optimization | References" en el IDE).
El programa funcionará bien sin el archivo .pdb: puede elegir enviarlo a los clientes si desea brindar una mejor experiencia de depuración en el sitio del cliente. Si solo desea poder obtener rastreos de pila decentes, no necesita tener el archivo .pdb en la máquina del cliente, ya que ellos (o alguna herramienta / funcionalidad que proporcione) pueden enviar un archivo de volcado que se puede cargar en un depurador en su sitio con el archivo .pdb disponible y obtenga la misma información de rastreo de la pila port-mortem.
Por supuesto, una cosa a tener en cuenta es que deberá archivar los archivos .pdb junto con sus versiones. El paquete "Herramientas de depuración para Windows" (que ahora se distribuye en el SDK de Windows) proporciona una herramienta de servidor de símbolos para que pueda archivar .pdbs y recuperarlos fácilmente para la depuración.
El único inconveniente que se me ocurre al distribuir archivos .pdb es que puede facilitar la ingeniería inversa de su aplicación, si eso le preocupa. Tenga en cuenta que Microsoft distribuye símbolos para Windows (mediante un servidor de símbolos público, así como paquetes de los conjuntos de símbolos completos para algunas versiones específicas). Sin embargo, los símbolos que distribuyen se ejecutan a través de un paso de desinfección que elimina ciertos elementos que consideran sensibles. Puede hacer lo mismo (o similar) utilizando la opción del enlazador /PDBSTRIPPED ( "Linker | Debugging | Strip Private Symbols" /PDBSTRIPPED "Linker | Debugging | Strip Private Symbols" en el IDE). Consulte la documentación de MSDN para obtener detalles sobre lo que elimina la opción. Si vas a distribuir símbolos, probablemente sea apropiado usar esa opción.
No mencionas en qué idioma estás, puede haber diferentes respuestas para C ++ en comparación con C #.
No estoy 100% seguro de qué cambio estás considerando hacer. ¿Le dirá a Visual Studio que haga su compilación de depuración estándar y la envíe, o editará un par de configuraciones en la compilación de la versión? Una modificación cuidadosa de un par de configuraciones en la versión Release me parece el mejor enfoque.
Independientemente de lo que termine, me aseguraría de que las optimizaciones estén activadas, ya que eso puede hacer una diferencia significativa en el rendimiento del código compilado.
Siempre envío la versión de depuración, nunca la versión de lanzamiento. No puedo pensar en ninguna desventaja, y las ventajas son las que mencionas.