crear - generar ejecutable visual studio 2010 c#

Archivos PDB para la aplicación de producción y la marca "Optimizar código"

Question

¿Cuándo debería incluir archivos PDB para una versión de producción? ¿Debería usar el indicador de Optimize code y cómo afectaría eso la información que obtengo de una excepción?

Si hay un beneficio de rendimiento notable, me gustaría utilizar las optimizaciones, pero si no, prefiero tener información de depuración precisa. ¿Qué se suele hacer para una aplicación de producción?

Answer 1

Cuando desee ver nombres de archivos de origen y números de línea en sus stacktraces, genere PDB utilizando la opción pdb-only. La optimización es independiente de la generación de PDB, es decir, puede optimizar y generar PDB sin un golpe de rendimiento.

De la referencia del lenguaje C #

Si usa / debug: full, tenga en cuenta que existe un cierto impacto en la velocidad y el tamaño del código JIT optimizado y un pequeño impacto en la calidad del código con / debug: full. Recomendamos / depuramos: pdbonly o no PDB para generar código de lanzamiento.

Answer 2

No es necesario incluirlos en su distribución, pero definitivamente debe compilarlos y conservarlos. De lo contrario, la depuración de un volcado de emergencia es prácticamente imposible.

También activaría optimizaciones. Si bien dificulta la depuración, las ganancias de rendimiento generalmente no son triviales, dependiendo de la naturaleza de la aplicación. Vemos fácilmente un rendimiento superior a 10x en las compilaciones de versión frente a depuración para algunos algoritmos.

Answer 3

Para responder a su primera pregunta, solo necesita incluir PDB para una versión de producción si necesita números de línea para sus informes de excepción.

Para responder a su segunda pregunta, usar el indicador "Optimizar" con PDB significa que cualquier pila "colapsar" se reflejará en el seguimiento de la pila . No estoy seguro de si el número de línea real reportado puede estar equivocado, esto necesita más investigación.

Para responder a su tercera pregunta, puede obtener lo mejor de ambos mundos con un truco bastante ingenioso. Las principales diferencias entre la versión de depuración predeterminada y la versión de lanzamiento predeterminada son que cuando se realiza una versión de lanzamiento predeterminada, la optimización se activa y los símbolos de depuración no se emiten. Entonces, en cuatro pasos:

1. Cambie su configuración de lanzamiento para emitir símbolos de depuración. Esto prácticamente no tiene ningún efecto en el rendimiento de su aplicación, y es muy útil si (¿cuándo?) Necesita depurar una versión de lanzamiento de su aplicación.

2. Compile usando su nueva configuración de compilación de versión, es decir, con símbolos de depuración y con optimización. Tenga en cuenta que el 99% de la optimización del código la realiza el compilador JIT, no el compilador del lenguaje.

3. Cree un archivo de texto en la carpeta de su aplicación llamada xxxx.exe.ini (o dll o lo que sea), donde xxxx es el nombre de su ejecutable. Este archivo de texto debería tener el siguiente aspecto:

   [.NET Framework Debugging Control]
   GenerateTrackingInfo=0
   AllowOptimize=1

4. Con esta configuración, tu aplicación se ejecuta a toda velocidad. Cuando desee depurar su aplicación activando el seguimiento de depuración y posiblemente desactivando la optimización del código (CIL), solo use la siguiente configuración:

   [.NET Framework Debugging Control]
   GenerateTrackingInfo=1
   AllowOptimize=0 

EDITAR Según el comentario de cateye, esto también puede funcionar en un entorno alojado como ASP.NET.