c# - proyecto - visual studio 2017 generate release

¿Debo compilar compilaciones de liberación con información de depuración como "completa" o "pdb-only"?

Question

En Visual Studio 2010 para un proyecto C #, si va a Propiedades del proyecto> Compilar> Avanzado> Información de depuración, tiene tres opciones: ninguna, completa o solo pdb. En base a la respuesta a esta pregunta , creo que entiendo algunas de las diferencias entre completo y solo pdb. Sin embargo, ¿cuál es más apropiado para una compilación de lanzamiento? Si uso "completo" ¿habrá ramificaciones de rendimiento? Si uso "pdb-only", ¿será más difícil depurar problemas de producción?

¿Cuál es la diferencia entre "completo" y "pdbonly"? https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/debug-compiler-option

Answer 1

Estoy en el proceso de escribir un controlador de excepciones no manejado y el seguimiento de la pila incluye el número de línea cuando solo se usa pdb, de lo contrario solo obtengo el nombre de Sub / Function cuando elijo None.

Si no distribuyo el archivo .pdb, no obtengo el número de línea en el seguimiento de la pila, incluso con la compilación de solo pdb.

Entonces, estoy distribuyendo (XCOPY deploy en una LAN) el pdb junto con el exe de mi aplicación VB.

Answer 2

Solo deseará PDB, pero no querrá entregar los archivos PDB a los usuarios. Sin embargo, tenerlos para usted, junto con sus binarios, le da la capacidad de cargar volcados de memoria en un depurador como WinDbg y ver dónde falló realmente su programa. Esto puede ser útil cuando su código se bloquea en una máquina a la que no tiene acceso.

La depuración completa agrega el atributo [Debuggable] a su código. Esto tiene un gran impacto en la velocidad. Por ejemplo, algunas optimizaciones de bucle pueden desactivarse para facilitar el paso simple. Además, tiene un pequeño efecto en el proceso JIT, ya que activa el seguimiento.

Answer 3

ADVERTENCIA ¡La documentation MSDN para / debug switch (en Visual Studio es Debug Info) parece estar desactualizada! Esto es lo que tiene que es incorrecto

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.

Una diferencia entre / debug: pdbonly y / debug: full es que con / debug: full el compilador emite un DebuggableAttribute , que se usa para indicar al compilador JIT que la información de depuración está disponible.

Entonces, ¿qué es verdad ahora?

1. Pdb-only : antes de .NET 2.0, ayudó a investigar los volcados del producto lanzado (máquinas del cliente). Pero no dejó adjuntar el depurador. Este no es el caso de .NET 2.0. Es exactamente lo mismo que Completo .
2. Completo : esto nos ayuda a investigar volcados de error y también nos permite adjuntar depurador para liberar compilación. Pero a diferencia de las menciones de MSDN, no afecta el rendimiento (desde .NET 2.0). Hace exactamente lo mismo que Pdb-only .

Si son exactamente iguales, ¿por qué tenemos estas opciones? John Robbins (Windows depurando a dios) descubrió que están ahí por razones históricas.

De vuelta en .NET 1.0 hubo diferencias, pero en .NET 2.0 no. Parece que .NET 4.0 seguirá el mismo patrón. Después de verificarlo dos veces con el equipo de depuración de CLR, no hay ninguna diferencia.

Lo que controla si el JITter tiene una compilación de depuración es el modificador / optimize. <...>

La conclusión es que desea construir sus compilaciones de lanzamiento con / optimize + y cualquiera de los modificadores / debug para que pueda depurar con código fuente.

luego él continúa para probarlo.

Ahora la optimización es parte de un switch /optimize separado (en Visual Studio se llama Optimize code ).

En resumen, independientemente de la configuración de DebugInfo solo pdb o completa, tendremos los mismos resultados. La recomendación es evitar None, ya que le privaría de poder analizar los volcados del producto liberado o adjuntar el depurador.

Answer 4

Construiría con pdb-only . No podrá adjuntar un depurador al producto liberado, pero si obtiene un volcado de emergencia, puede usar Visual Studio o WinDBG para examinar los rastreos de pila y los volcados de memoria en el momento del bloqueo.

Si va con full lugar de pdb-only , obtendrá los mismos beneficios, excepto que el ejecutable se puede adjuntar directamente a un depurador. Tendrá que determinar si esto es razonable dado su producto y clientes.

Asegúrese de guardar los archivos PDB en algún lugar para que pueda hacer referencia a ellos cuando aparezca un informe de fallas. Si puede configurar un servidor de símbolos para almacenar esos símbolos de depuración, mucho mejor.

Si opta por construir sin none , no tendrá ningún recurso cuando se produzca un bloqueo en el campo. No podrá realizar ningún tipo de examen posterior al accidente, lo que podría obstaculizar seriamente su capacidad para rastrear el problema.

Una nota sobre el rendimiento:

Tanto John Robbins como Eric Lippert han escrito publicaciones en blogs sobre la bandera /debug , y ambos indican que esta configuración tiene un impacto cero en el rendimiento . Hay un indicador separado /optimize que dicta si el compilador debe realizar optimizaciones.