Diferencias de configuración comunes entre el desarrollo y la producción (C#)

  • Artículo

por Scott Mitchell

Descargar PDF

En tutoriales anteriores implementamos nuestro sitio web copiando todos los archivos pertinentes del entorno de desarrollo al entorno de producción. Sin embargo, no es raro que haya diferencias de configuración entre entornos, lo que requiere que cada entorno tenga un archivo Web.config único. En este tutorial se examinan las diferencias de configuración típicas y se examinan las estrategias para mantener información de configuración independiente.

Introducción

Los dos últimos tutoriales le guiaron por la implementación de una aplicación web sencilla. El tutorial Implementación del sitio mediante un cliente FTP mostró cómo usar un cliente FTP independiente para copiar los archivos necesarios desde el entorno de desarrollo hasta producción. En el tutorial anterior, Implementar el sitio con Visual Studio, se examinó la implementación mediante la herramienta Copiar sitio web y la opción Publicar de Visual Studio. En ambos tutoriales, todos los archivos del entorno de producción eran una copia de un archivo del entorno de desarrollo. Sin embargo, no es raro que los archivos de configuración del entorno de producción difieran de los del entorno de desarrollo. La configuración de una aplicación web se almacena en el archivo Web.config y normalmente incluye información sobre los recursos externos, como la base de datos, la web y los servidores de correo electrónico. También detalla el comportamiento de la aplicación en determinadas situaciones, como el curso de acción que se debe realizar cuando se produce una excepción no controlada.

Al implementar una aplicación web, es importante que la información de configuración correcta termine en el entorno de producción. En la mayoría de los casos, el archivo Web.config del entorno de desarrollo no se puede copiar en el entorno de producción tal como está. En su lugar, es necesario cargar una versión personalizada de Web.config en producción. En este tutorial se revisan brevemente algunas de las diferencias de configuración más comunes; también se resumen algunas técnicas para mantener información de configuración diferente entre los entornos.

Diferencias de configuración típicas entre los entornos de desarrollo y producción

El archivo Web.config incluye una gran variedad de información de configuración para una aplicación de ASP.NET. Parte de esta información de configuración es la misma independientemente del entorno. Por ejemplo, la configuración de autenticación y las reglas de autorización de direcciones URL escritas en los elementos <authentication> y <authorization> del archivo Web.config suelen ser las mismas independientemente del entorno. Pero otra información de configuración, como la de los recursos externos, suele diferir en función del entorno.

Las cadenas de conexiones de base de datos son un ejemplo excelente de información de configuración que difiere en función del entorno. Cuando una aplicación web se comunica con un servidor de bases de datos, primero debe establecer una conexión y eso se logra a través de una cadena de conexión. Aunque es posible codificar de forma rígida la cadena de conexión de la base de datos directamente en las páginas web o el código que se conecta a la base de datos, es mejor colocar el elemento <connectionStrings> de Web.config para que la información de la cadena de conexión esté en una sola ubicación centralizada. A menudo, se usa una base de datos diferente durante el desarrollo de la que se usa en producción; por tanto, la información de la cadena de conexión debe ser única para cada entorno.

Nota:

Los tutoriales futuros exploran la implementación de aplicaciones controladas por datos, en cuyo punto profundizaremos en los detalles de cómo se almacenan las cadenas de conexión de base de datos en el archivo de configuración.

El comportamiento previsto de los entornos de desarrollo y producción difiere sustancialmente. Se crea, prueba y depura una aplicación web en el entorno de desarrollo mediante un pequeño grupo de desarrolladores. En el entorno de producción, muchos usuarios simultáneos visitan la misma aplicación. ASP.NET incluye varias características que ayudan a los desarrolladores a probar y depurar una aplicación, pero estas características deben deshabilitarse por motivos de rendimiento y seguridad cuando se encuentra en el entorno de producción. Echemos un vistazo a algunos de estos valores de configuración.

Opciones de configuración que afectan al rendimiento

Cuando se visita una página ASP.NET por primera vez (o la primera vez desde que ha cambiado), su marcado declarativo debe convertirse en una clase, que se debe compilar. Si la aplicación web usa la compilación automática, también debe compilarse la clase de código subyacente de la página. Puede configurar una variedad de opciones de compilación a través del elemento <compilation> del archivo Web.config.

El atributo debug es uno de los atributos más importantes del elemento <compilation>. Si el atributo debug se establece en "true", los ensamblados compilados incluyen símbolos de depuración, que son necesarios al depurar una aplicación en Visual Studio. Pero los símbolos de depuración aumentan el tamaño del ensamblado e imponen requisitos de memoria adicionales al ejecutar el código. Además, cuando el atributo debug se establece en "true" no se almacena en caché ningún contenido devuelto por WebResource.axd, lo que significa que cada vez que un usuario visita una página, tendrá que volver a descargar el contenido estático devuelto por WebResource.axd.

Nota:

WebResource.axd es un controlador HTTP integrado introducido en ASP.NET 2.0 que los controles de servidor usan para recuperar recursos incrustados, como archivos de script, imágenes, archivos CSS y otro contenido. Para obtener más información sobre cómo funciona WebResource.axd y cómo se puede usar para acceder a los recursos incrustados desde los controles de servidor personalizados, consulte Acceso a los recursos incrustados a través de una dirección URL mediante WebResource.axd.

El atributo debug del elemento <compilation> normalmente se establece en "true" en el entorno de desarrollo. De hecho, este atributo debe establecerse en "true" para depurar una aplicación web; si intenta depurar una aplicación ASP.NET desde Visual Studio y el atributo debug se establece en "false", Visual Studio mostrará un mensaje que explica que la aplicación no se puede depurar hasta que el atributo debug esté establecido en "true" y ofrecerá realizar este cambio.

Nunca debe tener el atributo debug establecido en "true" en un entorno de producción debido a su impacto en el rendimiento. Para ver una explicación más detallada sobre este tema, consulte la entrada de blog de Scott Guthrie, Don't Run Production ASP.NET Applications With debug="true" Enabled.

Errores personalizados y seguimiento

Cuando se produce una excepción no controlada en una aplicación ASP.NET se propaga hasta el tiempo de ejecución en el que se produce una de las tres cosas:

  • Se muestra un mensaje de error genérico en tiempo de ejecución. Esta página informa al usuario de que se produjo un error en tiempo de ejecución, pero no proporciona detalles sobre el error.
  • Se muestra un mensaje de detalles de excepción, que incluye información sobre la excepción que se acaba de iniciar.
  • Se muestra una página de error personalizada, que es una página ASP.NET que crea que muestra cualquier mensaje que desee.

Lo que sucede ante una excepción no controlada depende de la sección <customErrors> del archivo Web.config.

Al desarrollar y probar una aplicación, ayuda a ver los detalles de cualquier excepción en el explorador. Sin embargo, mostrar los detalles de excepción en una aplicación en producción es un riesgo de seguridad potencial. Además, es poco favorecedor y hace que su sitio web parezca poco profesional. Idealmente, en caso de una excepción no controlada, una aplicación web en el entorno de desarrollo mostrará los detalles de la excepción, mientras que la misma aplicación en producción mostrará una página de error personalizada.

Nota:

La configuración predeterminada de la sección <customErrors> muestra el mensaje de detalles de excepción solo cuando la página se visita a través de localhost y muestra la página de error en tiempo de ejecución genérica en caso contrario. Esto no es ideal, pero se asegura de saber que el comportamiento predeterminado no revela los detalles de excepción a los visitantes no locales. Un tutorial futuro examina la sección <customErrors> con más detalle y muestra cómo tener una página de error personalizada que se muestra cuando se produce un error en producción.

Otra característica de ASP.NET que resulta útil durante el desarrollo es el seguimiento. El seguimiento, si está habilitado, registra información sobre cada solicitud entrante y proporciona una página web especial, Trace.axd, para ver los detalles recientes de la solicitud. Puede activar y configurar el seguimiento a través del elemento <trace> de Web.config.

Si habilita el seguimiento, asegúrese de que está deshabilitado en producción. Dado que la información de seguimiento incluye cookies, datos de sesión y otra información potencialmente confidencial, es importante deshabilitar el seguimiento en producción. La buena noticia es que, de forma predeterminada, el seguimiento está deshabilitado y el archivo Trace.axd solo es accesible a través de localhost. Si cambia esta configuración predeterminada en el desarrollo, asegúrese de que esté desactivada en producción.

Técnicas para mantener información de configuración independiente

Tener diferentes opciones de configuración en los entornos de desarrollo y producción complica el proceso de implementación. En los dos tutoriales anteriores, el proceso de implementación implicaba copiar todos los archivos necesarios de desarrollo a producción, pero ese enfoque solo funciona si la información de configuración es la misma en ambos entornos. Hay una variedad de técnicas para implementar una aplicación con información de configuración variable. Vamos a catalogar algunas de estas opciones para las aplicaciones web hospedadas.

Implementación manual del archivo de configuración del entorno de producción

El enfoque más sencillo es mantener dos versiones del archivo Web.config: una para el entorno de desarrollo y otra para el entorno de producción. La implementación de un sitio en producción implica copiar todos los archivos en el servidor de producción en el entorno de desarrollo, excepto para el archivo Web.config. En su lugar, el archivo Web.config específico del entorno de producción se copiaría en producción.

Este enfoque no es muy sofisticado, pero es fácil de implementar porque la información de configuración cambia con poca frecuencia. Funciona mejor para las aplicaciones con un equipo de desarrollo pequeño hospedado en un único servidor web y cuya información de configuración se cambia con poca frecuencia. Es más sostenible al implementar manualmente los archivos de aplicación mediante un cliente FTP independiente. Al usar la herramienta Copiar sitio web o la opción Publicar de Visual Studio, primero deberá intercambiar el archivo Web.config específico de la implementación con el específico de producción antes de la implementación y, a continuación, volver a intercambiarlos una vez completada la implementación.

Cambio de la configuración durante el proceso de compilación o implementación

Hasta ahora, los debates han asumido un proceso de implementación y compilación ad hoc. Muchos proyectos de software más grandes tienen procesos más formalizados que usan herramientas de código abierto, de desarrollo doméstico o de terceros. Para estos proyectos, es probable que pueda personalizar el proceso de compilación o implementación para modificar correctamente la información de configuración antes de insertarla en producción. Si compila la aplicación web con MSBuild, NAnt o alguna otra herramienta de compilación, es probable que pueda agregar un paso de compilación para modificar el archivo Web.config para incluir la configuración específica de producción. O bien, el flujo de trabajo de implementación podría conectarse mediante programación al servidor de control de código fuente y recuperar el archivo Web.config adecuado.

El enfoque real para obtener la información de configuración adecuada para producción varía ampliamente en función de las herramientas y el flujo de trabajo. Por lo tanto, no profundizaremos más en este tema. Si usa una herramienta de compilación popular como MSBuild o NAnt, puede encontrar artículos de implementación y tutoriales específicos de estas herramientas a través de una búsqueda web.

Administración de diferencias de configuración a través del complemento de proyecto de implementación web

En 2006, Microsoft publicó el complemento proyecto de desarrollo web para Visual Studio 2005. En 2008 se publicó un complemento para Visual Studio 2008. Este complemento permite a los desarrolladores de ASP.NET crear un proyecto de implementación web independiente junto con su proyecto de aplicación web que, cuando se compila, compila explícitamente la aplicación web y copia los archivos para implementarlos en un directorio de salida local. El proyecto de aplicación web usa MSBuild en segundo plano.

De forma predeterminada, el archivo Web.config del entorno de desarrollo se copia en el directorio de salida, pero puede configurar el proyecto de implementación web para personalizar la

información de configuración que se copia en este directorio de las maneras siguientes:

  • A través del reemplazo de sección de archivo Web.config, en el que se especifica la sección que se va a reemplazar y un archivo XML que contiene el texto de reemplazo.
  • Proporcionando una ruta de acceso a un archivo de origen de configuración externo. Con esta opción seleccionada, el proyecto de implementación web copia un archivo Web.config determinado en el directorio de salida (en lugar del archivo Web.config usado en el entorno de desarrollo).
  • Agregando reglas personalizadas al archivo de MSBuild usado por el proyecto de implementación web.

Para implementar la aplicación web, compile el proyecto de implementación web y, a continuación, copie los archivos de la carpeta de salida del proyecto en el entorno de producción.

Para obtener más información sobre el uso del proyecto de implementación web, consulte este artículo de proyectos de implementación web de la edición de abril de 2007 de MSDN Magazine, o consulte los vínculos de la sección Lectura adicional al final de este tutorial.

Nota:

No puede usar el proyecto de implementación web con Visual Web Developer porque el proyecto de implementación web se implementa como un complemento de Visual Studio y las ediciones de Visual Studio Express (incluido Visual Web Developer) no admiten complementos.

Resumen

Los recursos externos y el comportamiento de una aplicación web en desarrollo suelen ser diferentes de cuando la misma aplicación está en producción. Por ejemplo, las cadenas de conexión de base de datos, las opciones de compilación y el comportamiento cuando se produce una excepción no controlada suelen diferir entre entornos. El proceso de implementación debe adaptarse a estas diferencias. Como se explicó en este tutorial, el enfoque más sencillo es copiar manualmente un archivo de configuración alternativo en el entorno de producción. Puede haber soluciones más elegantes si se usa el complemento de proyecto de implementación web o con un proceso de compilación o implementación más formalizado que pueda dar cabida a estas personalizaciones.

¡Feliz programación!

Lecturas adicionales

Para obtener más información sobre los temas tratados en este tutorial, consulte los siguientes recursos:

AnteriorSiguiente