¿Implementar la aplicación en producción usando el modo de depuración en lugar del modo de lanzamiento?

Question

Trabajo para una tienda que mantiene una aplicación relativamente nueva. La aplicación todavía tiene su parte justa de errores, con numerosos boletos que llegan diariamente. La información de error que recibimos con esos tickets no es tan útil como podría ser porque la aplicación se compiló en modo Release, que leo es más pequeña y más rápida (tiene sentido).

¿Existen ramificaciones en la implementación de una aplicación .NET en la producción compilada en el modo de depuración? Esperaría que fuera un poco más lento, pero he leído que la diferencia es nominal. Esto nos aseguraría que cuando tenemos errores en los tickets, tenemos el número de línea asociado con esos errores y esto, por supuesto, hace que la depuración sea mucho más fácil.

¿Alguna bandera roja importante que le impida hacer esto? Tengo la tarea de investigar la posibilidad. Así que gracias por cualquier comentario.

Answer 1

La implementación de su aplicación en DEBUG en lugar del modo de lanzamiento ralentizará su rendimiento. Por supuesto, se pueden hacer compromisos. Yo sugeriría una de las siguientes:

• mirada a la adición de un controlador de errores global a la OnError en su global.asax-
• mirada a un compromiso similar a uno this sugieren por Scott Hanselman

Answer 2

Todo depende de la importancia de su entorno de producción, negocio y requisitos de rendimiento. Nada es estricto

Answer 3

La implementación de compilaciones de depuración es una señal de advertencia para mí, aunque no es algo inaudito. ¿Es esta una aplicación de escritorio o servidor? Cualquier llamada al Debug.Assert que falle podría ser un problema, ya que pueden cerrar su aplicación y/o hacer que un depurador se adjunte (VS.NET no es el único depurador y si recuerdo .net fx instala un depurador liviano). Si bien eso puede ser útil como desarrollador, sin duda puede ser confuso para una persona normal.

Una opción que funciona bien es que las compilaciones de depuración se aseguran de que su mecanismo de informe de errores incluya (muestre o registre) la información de seguimiento de la pila de cualquier exceptions lanzado. Esta ayuda identifica errores muy bien sin necesidad de pdbs.

Answer 4

Mi experiencia es que esto puede funcionar bien si estás pensando en una aplicación de escritorio (winforms/WPF), pero bajo ninguna circunstancia deberías probar esto con una aplicación asp.net.

Answer 5

Has etiquetado esto [vb.net], no puedes enviar compilaciones de depuración o programas que usan WithEvents. Hay una pérdida de memoria conocida y afaik no resuelta para las instancias de WeakReference si no hay un depurador conectado. Se usan para admitir Edit + Continue.

Lo primero que puede hacer es enviar los archivos .pdb junto con sus aplicaciones. En C# IDE use Project + Properties, pestaña Build, Avanzado, cambie la información de depuración a "Completo". Obtendrá información del número de línea en el seguimiento de la pila de excepción.

No puede confiar completamente en el número de línea, el optimizador JIT moverá el código para que se ejecute más rápido. Y funciones cortas en línea como captadores de propiedades. Se puede añadir una yourapp.ini file en el mismo directorio que el ejecutable que desactiva el optimizador JIT

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

Answer 6

Si se trata de una aplicación de escritorio, puede probar con algunos clientes, pero prestar atención al consejo dado en otras respuestas. Pruebe con alguien que sea más un usuario avanzado o que tenga muchos problemas y esté dispuesto a ofrecerse como voluntario.