Implementar una aplicación web de ASP.NET con SQL Server Compact mediante Visual Studio o Visual Web Developer: Transformaciones de archivo Web.Config: 3 de 12

de Tom Dykstra

Descargar el proyecto de inicio

En esta serie de tutoriales se muestra cómo implementar (publicar) un proyecto de aplicación web de ASP.NET que incluye una base de datos de SQL Server Compact mediante Visual Studio 2012 RC o Visual Studio Express 2012 RC para la web. También puede usar Visual Studio 2010 si instala la actualización de publicación web. Para obtener una introducción a la serie, consulte el primer tutorial de la serie.

Para ver un tutorial que muestra las características de implementación introducidas después de la versión RC de Visual Studio 2012, muestra cómo implementar ediciones de SQL Server distintas de SQL Server Compact y muestra cómo implementar en Azure App Service Web Apps, consulte Implementación web de ASP.NET con Visual Studio.

Información general

En este tutorial se muestra cómo automatizar el proceso de cambio del archivo Web.config al implementarlo en diferentes entornos de destino. La mayoría de las aplicaciones tienen valores en el archivo Web.config que deben ser diferentes cuando se implementa la aplicación. La automatización del proceso de realización de estos cambios le evita tener que hacerlos manualmente en cada implementación, lo que sería tedioso y propenso a errores.

Aviso: si recibe un mensaje de error o algo no funciona mientras recorre el tutorial, visite la página de solución de problemas.

Diferencias entre transformaciones de Web.config y parámetros de Web Deploy

Hay dos maneras de automatizar el proceso de cambiar los valores del archivo Web.config: transformaciones Web.configy parámetros de Web Deploy. Un archivo de transformación de Web.config contiene marcado XML que especifica cómo cambiar el archivo Web.config cuando se implementa. Puede especificar diferentes cambios para configuraciones de compilación perfiles de publicación específicos. Las configuraciones de compilación predeterminadas son Depuración y Versión, y puede crear configuraciones de compilación personalizadas. Normalmente, un perfil de publicación se corresponde a un entorno de destino. (Obtendrá más información sobre los perfiles de publicación en el tutorial Implementación en IIS como un entorno de prueba).

Los parámetros de Web Deploy se pueden usar para especificar muchos tipos diferentes de valores que se deben configurar durante la implementación, incluidos los que se encuentran en los archivosWeb.config. Cuando se usan para especificar cambios en el archivo Web.config, los parámetros de Web Deploy son más complejos de configurar, pero son útiles cuando no se sabe el valor que se va a establecer hasta que se implemente. Por ejemplo, en un entorno empresarial, es posible que cree un paquete de implementación y se lo asigne a una persona del departamento de TI para que lo instale en producción, y que esa persona tenga que escribir cadenas de conexión o contraseñas que no conoce.

Para el escenario que se describe en esta serie de tutoriales, imaginemos que ya sabe de antemano todo lo que se debe hacer en el archivo Web.config, por lo que no es necesario usar parámetros de Web Deploy. Configurará algunas transformaciones que difieren en función de la configuración de compilación usada y otras en función del perfil de publicación.

Crear archivos de transformación para perfiles de publicación

En el Explorador de soluciones, expanda Web.config para ver los archivos de transformación Web.Debug.config y Web.Release.config que se crean de forma predeterminada para las dos configuraciones de compilación predeterminadas.

Para crear archivos de transformación para configuraciones de compilación personalizadas, haga clic con el botón derecho en el archivo Web.config y elija Agregar transformaciones de configuración en el menú contextual, pero para este tutorial esto no será necesario.

Necesita dos archivos de transformación más para configurar los cambios relacionados con el destino de la implementación en lugar de con la configuración de compilación. Un ejemplo típico de este tipo de configuración es un punto de conexión WCF diferente para pruebas frente a producción. En tutoriales posteriores, creará perfiles de publicación denominados Test and Production, por lo que necesitará un archivo Web.Test.config y un archivo Web.Production.config.

Los archivos de transformación que están asociados a perfiles de publicación se deben crear manualmente. En Explorador de soluciones, haga clic con el botón derecho en el proyecto ContosoUniversity y seleccione Abrir carpeta en el explorador de Windows.

En el Explorador de Windows, seleccione el archivo Web.Release.config, copie el archivo y, a continuación, pegue dos copias de él. Cambie el nombre de las copias Web.Production.config y Web.Test.config y cierre el Explorador de Windows.

En Explorador de soluciones, haga clic en Actualizar para ver los nuevos archivos.

Seleccione los nuevos archivos, haga clic con el botón derecho y, a continuación, haga clic en Incluir en proyecto en el menú contextual.

Para evitar que estos archivos se implementen, selecciónelos en Explorador de soluciones y, a continuación, en la ventana Propiedades, cambie la propiedad Acción de compilación de Contenido a Ninguno. (Se impide automáticamente el despliegue de los archivos de transformación basados en configuraciones de compilación).

Ya está listo para escribir transformaciones Web.config en los archivos de transformación Web.config.

Limitar el acceso al registro de errores a los administradores

Si se produce un error mientras se ejecuta la aplicación, seta muestra una página de error genérica en lugar de la página de error generada por el sistema y usa el paquete NuGet Elmah para el registro de errores y los informes. El elemento customErrors del archivo Web.config especifica la página de error:

<customErrors mode="RemoteOnly" defaultRedirect="~/GenericErrorPage.aspx">
  <error statusCode="404" redirect="~/GenericErrorPage.aspx" />
</customErrors>

Para ver la página de error, cambie temporalmente el atributo mode del elemento customErrors de "RemoteOnly" a "Activado" y ejecute la aplicación desde Visual Studio. Provoque un error mediante la solicitud de una dirección URL no válida, como Studentsxxx.aspx. En lugar de una página de error "página no encontrada" generada por IIS, verá la página GenericErrorPage.aspx.

Para ver el registro de errores, reemplace todo lo que aparece en la dirección URL después del número de puerto por elmah.axd (por ejemplo en la captura de pantalla, http://localhost:51130/elmah.axd) y presione Entrar:

No olvide volver a establecer el elemento customErrors en el modo "RemoteOnly" cuando haya terminado.

En el equipo de desarrollo, es conveniente permitir el acceso libre a la página del registro de errores, pero en producción sería un riesgo de seguridad. Para el sitio de producción, puede agregar una regla de autorización que restrinja el acceso del registro de errores solo a los administradores configurando una transformación en el archivo Web.Production.config.

Abra Web.Production.config y agregue un nuevo elemento location inmediatamente después de la etiqueta de apertura configuration, como se muestra aquí. (Asegúrese de agregar solo el elemento location y no el marcado circundante que se muestra aquí solo para proporcionar algún contexto).

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
    <location path="elmah.axd" xdt:Transform="Insert">
      <system.web>
        <authorization>
          <allow roles="Administrator" />
          <deny users="*" />
        </authorization>
      </system.web>
    </location>
</configuration>

El valor de atributo Transform de "Insert" hace que este elemento location se agregue como un elemento relacionado con cualquier elemento location existente en el archivo Web.config. (Ya hay un elemento location que especifica reglas de autorización para la página Actualizar créditos). Al probar el sitio de producción después de la implementación, lo probará para comprobar que la regla de autorización es efectiva.

No es necesario restringir el acceso al registro de errores en el entorno de prueba, por lo que no tiene que agregar este código al archivo Web.Test.config.

Nota:

Nota de seguridad No muestre nunca los detalles del error al público en una aplicación de producción, ni almacene esa información en una ubicación pública. Los atacantes pueden usar la información de error para detectar vulnerabilidades en un sitio. Si usa ELMAH en su propia aplicación, asegúrese de investigar las formas en que ELMAH se puede configurar para minimizar los riesgos de seguridad. El ejemplo de ELMAH de este tutorial no se debe considerar una configuración recomendada. Se trata de un ejemplo elegido para ilustrar cómo controlar una carpeta en la que la aplicación debe poder crear archivos.

Establecer un indicador de entorno

Un escenario común es tener los valores del archivo Web.config diferentes para cada entorno en el que se implemente. Por ejemplo, una aplicación que llama a un servicio WCF podría necesitar un punto de conexión diferente en entornos de prueba y producción. La aplicación Contoso University también incluye un valor de este tipo. Este valor controla un indicador visible en las páginas de un sitio que le indica en qué entorno está, como el de desarrollo, prueba o producción. El valor determina si la aplicación anexará "(Dev)" o "(Test)" al título principal de la página maestra Site.Master:

El indicador de entorno se omite cuando la aplicación se ejecuta en producción.

Las páginas web de Contoso University leen un valor establecido en appSettings en el archivo Web.config para determinar en qué entorno se ejecuta la aplicación:

<appSettings>
    <add key="Environment" value="Dev" />
</appSettings>

El valor debe ser "Test" en el entorno de prueba y "Prod" en el entorno de producción.

Abra Web.Production.config y agregue un elemento appSettings inmediatamente antes de la etiqueta de apertura del elemento location que agregó anteriormente:

<appSettings>
    <add key="Environment" value="Prod" xdt:Transform="SetAttributes" xdt:Locator="Match(key)"/>
</appSettings>

El valor de atributo "SetAttributes" de xdt:Transform indica que el propósito de esta transformación es cambiar los valores de atributo de un elemento existente en el archivo Web.config. El valor de atributo "Match(key)" de xdt:Locator indica que el elemento que se va a modificar es aquel cuyo atributokey coincide con el atributo key especificado aquí. El único atributo restante del elemento add es valuey es lo que se cambiará en el archivo Web.config implementado. El código hace que el atributo value del elemento EnvironmentappSettings se establezca en "Prod" en el archivo Web.config implementado para producción.

A continuación, aplique el mismo cambio al archivo Web.Test.config, pero establezca value en "Test" en lugar de "Prod". Cuando haya terminado, la sección appSettings en Web.Test.config tendrá el siguiente aspecto:

<appSettings>
    <add key="Environment" value="Test" xdt:Transform="SetAttributes" xdt:Locator="Match(key)"/>
</appSettings>

Deshabilitar el modo de depuración

Para una compilación de versión, normalmente querrá deshabilitar la depuración independientemente del entorno en el que se va a realizar la implementación. De forma predeterminada, el archivo de transformación Web.Release.config se crea automáticamente con código que quita el atributo debug del elemento compilation:

<system.web>
  <compilation xdt:Transform="RemoveAttributes(debug)" />
</system.web>

El atributo Transform hace que el atributo debug se omita desde el archivo Web.config implementado siempre que implemente una compilación de versión.

Esta misma transformación se encuentra en los archivos de transformación de prueba y producción porque los creó copiando el archivo de transformación de versión. No es necesario duplicarlo allí, así que abra cada uno de esos archivos, quite el elemento de compilación y guarde y cierre cada archivo.

Actualizar cadenas de conexión

En la mayoría de los casos no es necesario configurar transformaciones de cadena de conexión, ya que puede especificar cadena de conexión en el perfil de publicación. Pero hay una excepción cuando se implementa una base de datos de SQL Server Compact y se usa Migraciones de Entity Framework Code First para actualizar la base de datos en el servidor de destino. En este escenario, debe especificar un cadena de conexión adicional que se usará en el servidor para actualizar el esquema de la base de datos. Para configurar esta transformación, agregue un elemento <connectionStrings> inmediatamente después de la etiqueta de <configuración> de apertura en los archivos de transformación Web.Test.config y Web.Production.config:

<connectionStrings>
  <add name="SchoolContext_DatabasePublish" connectionString="Data Source=|DataDirectory|School-Prod.sdf" providerName="System.Data.SqlServerCe.4.0" xdt:Transform="Insert"/>
</connectionStrings>

El Transform atributo especifica que este cadena de conexión se agregará al elemento connectionStrings en el archivo Web.config implementado. (El proceso de publicación crea automáticamente esta cadena de conexión adicional si no existe, pero de forma predeterminada el atributo providerName se establece en System.Data.SqlClient, que no funciona para SQL Server Compact. Al agregar manualmente la cadena de conexión, se impide que el proceso de implementación cree un elemento de cadena de conexión con el nombre de proveedor incorrecto).

Ahora ha especificado todas las transformaciones Web.config que necesita para implementar la aplicación Contoso University para probar y producir. En el siguiente tutorial, se ocupará de las tareas de configuración de implementación que necesitan la configuración de propiedades del proyecto.

Más información

Para obtener más información sobre los temas tratados en este tutorial, consulte el escenario de transformación Web.config en el Mapa de contenido de implementación ASP.NET.

AnteriorSiguiente