¿Cómo le decimos a ASP.NET que estamos en etapa de desarrollo?

Por simplificar, podemos distinguir dos etapas básicas en el desarrollo de nuestras aplicaciones: la etapa de desarrollo y la etapa de producción.

La primera es aquella en la que estamos desarrollando nuestro programa, añadiendo, modificando e insertando cosas nuevas en todo momento. Nos conviene hacerle saber a nuestro compilador ASP.NET que estamos en etapa de desarrollo porque de este modo le estamos pidiendo que nos eche una mano, que nos vigile, y si ve que algo sale mal que sea comprensivo con nosotros (por ejemplo cuando estamos superando el tiempo máximo de espera) o que nos comente con la máxima precisión cual es el error o errores (mostrando el primer mensaje de error del compilador así como una completa traza con los últimos pasos realizados).

Aunque ya estemos acostumbrados a este comportamiento, en la época pre-ASP.NET, los programadores Web lo teníamos harto difícil para encontrar el más simple de los errores.

Como os podréis imaginar, la etapa de producción es aquella en la que nuestro programa es totalmente operativo, y lo tenemos expuesto en Internet o en una Intranet... y es en este momento donde no deseamos ni de lejos que se superen los límites marcados o se muestren completas intrucciones de cómo y por qué han surgido los errores.

Pero vale ya de palabrería, qué significa eso de "decirle a ASP.NET que estamos en etapa de desarrollo". Pues muy sencillo. Como todo en ASP.NET, es en el web.config donde informaremos al motor de ASP.NET en qué etapa estamos.

Para decirle que estamos en etapa de desarrollo añadiremos el elemento compilation con el atributo debug puesto a true, dentro del elemento system.web... ¿¿¿¿y esto como se come???? Más vale un ejemplo que mil palabras:

web.config (etapa de desarrollo)
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
    ...
    <system.web>
       ...
       <compilation debug="true"/>
       ...
    </system.web>
    ...
</configuration>


Donde los tres puntos significan "y ahí pueden estar otras cosas".

Así que como os podréis imaginar, cuando por el contrario estemos en etapa de producción, el atributo debug lo pondremos a false... aunque vamos a añadir otro elemento para dejar el tema bien cerradito:

web.config (etapa de producción)
<configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">
    ...
    <system.web>
       ...
        <compilation debug="false"/>
        <trace enabled="false" pageOutput="false"/>
       ...
    </system.web>
    ...
</configuration>


No quiero ser demasiado insistente, pero es que SUELE ocurrir que se nos olvide cambiar el atributo debug desde la etapa de desarrollo a la de producción... y eso produce resultados desastrosos, no sólo porque le estamos mostrando al usuario demasiada información en caso de error, sino porque la velocidad de ejecución de la aplicación se ve altamente dañada. Por poner un ejemplo claro, recuerdo que en cierto momento dejé varios minutos la web www.es-asp.net en el servidor de producción con el debug="true", y las páginas iban hasta 3 y 4 veces más lentas que con la configuración conveniente.

Para finalizar la diserción, comentaros que en el caso de que tengáis la suerte de poder acceder al fichero machine.config, bien por tener a vuestra disposición un servidor privado (caso de internet) o bien por ser responsables de una aplicación Web para Intranet, lo más conveniente es añadir el elemento "deployment" con el atributo "retail" pues a "true", dentro de vuestro system.web. Es decir:

machine.config
<configuration>
    ...
    <system.web>
    ...
          <deployment retail=”true”/>
    ...
    </system.web>
    ...
</configuration>