Información general sobre la implementación de proyectos de aplicación web ASP.NET

Después de haber creado un proyecto de aplicación web ASP.NET o un proyecto de sitio web ASP.NET en Visual Studio 2010, normalmente el proyecto se implementa en un servidor web donde otras personas pueden tener acceso a la aplicación. Normalmente, la implementación implica algo más que copiar los archivos de la aplicación de un servidor a otro. También podría tener que realizar otras tareas adicionales, como las siguientes:

• Cambiar la configuración del archivo Web.config que debe ser diferente en el entorno de destino, por ejemplo, la configuración de depuración o las cadenas de conexión de base de datos.

• Propagar los datos o estructuras de datos en las bases de datos que se usan en la aplicación web.

• Configurar los valores de IIS del equipo de destino, como el grupo de aplicaciones, el método de autenticación, si se permite o no el examen de directorios y el control de errores.

• Instalar certificados de seguridad.

• Establecer los valores del Registro del equipo de destino.

• Instalar los ensamblados de la aplicación en la memoria caché global de ensamblados (GAC) del equipo de destino.

Existe una extensión de Microsoft Internet Information Services (IIS), denominada Web Deploy, que puede automatizar la mayor parte de las tareas de implementación. Visual Studio proporciona herramientas que trabajan con Web Deploy para facilitar la implementación de un proyecto de aplicación web.

Nota

Este tema está orientado a las aplicaciones web que se crean con una plantilla de proyecto de aplicación web.También puede crear aplicaciones web mediante una plantilla de proyecto de sitio web.Para obtener más información acerca de la implementación de proyectos de sitio web, vea Información general sobre la implementación de proyectos de sitio web ASP.NET.

Este tema contiene las siguientes secciones:

• Paquetes de implementación web

• Publicación con un solo clic

• Escenarios de empresa

• Escenarios de hospedaje de otros fabricantes

• Transformación del archivo Web.config

• Implementar una base de datos de SQL Server

• Ampliar la canalización de publicación en Web

Para obtener más información sobre los temas que se mencionan en esta descripción general, vea Asignación de contenido de implementación ASP.NET.

Paquetes de implementación web

Para implementar un proyecto de aplicación web, puede usar Visual Studio para crear un paquete de implementación web e instalar el paquete en el servidor de destino. Un paquete de implementación es un archivo comprimido (.zip) que contiene información necesaria para configurar la aplicación en IIS, copiar archivos y configurar los recursos relacionados, como las bases de datos.

Puede crear el paquete de implementación e instalarlo en procesos independientes. Alternativamente, puede utilizar publicación con un solo clic, que permite realizar la implementación de forma remota en un solo paso. (De manera predeterminada, la publicación con un solo clic no crea un paquete. Sin embargo, si desea obtener un paquete, puede especificar que debe crearse con la publicación con un solo clic).

Además de los archivos de código fuente y los archivos binarios de la aplicación, un paquete de implementación normalmente contiene también archivos con los siguientes tipos de información:

• Valores de IIS, como el grupo de aplicaciones, el método de autenticación, si se permite el examen de directorios y el control de errores.

• Scripts de bases de datos que se usan para propagar los cambios a los datos o estructuras de la base de datos.

• Parámetros que contienen valores que tal vez haya que modificar cuando se instale el paquete, como la configuración de depuración, o cadenas de conexión.

El proceso de creación de paquetes de Visual Studio es extensible. Entre los ejemplos de información que tal vez desee incluir en un paquete pero que requieren extensiones personalizadas, están los siguientes:

• Certificados de seguridad.

• Valores del Registro de Windows.

• Ensamblados (archivos .dll) que se deben instalar en la GAC en el equipo de destino.

Especificar qué se va a incluir en un paquete de implementación

Visual Studio usa la configuración que se crea en la pestaña Empaquetar/publicar web de la página Propiedades del proyecto para determinar lo que se va a incluir en un paquete de implementación. La siguiente ilustración muestra la pestaña Empaquetar o publicar web.

La configuración relacionada con la base de datos que afecta a la creación del paquete se establece en la pestaña Empaquetar/publicar SQL, que se describe más adelante en este mismo tema.

Estas dos pestañas permiten actualizar la configuración que se usa habitualmente. Normalmente, los valores que se usan menos se almacenan en el archivo de proyecto (.csproj o .vbproj) de Visual Studio y se pueden cambiar editando ese archivo directamente.

Crear un paquete de implementación

Para crear un paquete, puede hacer lo siguiente:

• Usar las herramientas de Visual Studio.

• Usar el comando MSBuild directamente desde la línea de comandos.

• Usar el comando MSBuild de forma indirecta desde PowerShell o Team Build.

Instalar un paquete de implementación

Después de crear un paquete de implementación, lo instala en el equipo de destino. Web Deploy utiliza la información del paquete para configurar IIS, instalar bases de datos, crear estructuras de carpetas y copiar archivos en ellas; en definitiva, para hacer todo lo que sea necesario a fin de implementar la aplicación.

Puede instalar un paquete de las siguientes maneras:

• Usando Web Deploy en la línea de comandos.

• Usando un archivo .cmd creado en Visual Studio que contenga los comandos de Web Deploy que instalan el paquete. Los comandos de Web Deploy pueden ser largos y complejos. Este archivo se proporciona para facilitar la instalación de un paquete desde la línea de comandos.

• Usando el Administrador de IIS.

• Usando PowerShell para ejecutar los comandos de Web Deploy.

Puede incluir los parámetros en un paquete durante su creación. Estos parámetros son pares nombre-valor a los que proporciona un valor predeterminado cuando se crea el paquete, pero para los que puede proporcionarse un nuevo valor cuando se instala el paquete. Si usa el Administrador de IIS para instalar el paquete, los nombres de parámetro se muestran mediante cuadros de texto a fin de que puedan escribirse valores nuevos. Si la instalación se lleva a cabo utilizando Web Deploy desde la línea de comandos, puede especificar los valores de parámetro en un archivo XML.

Ubicación y contenido de la carpeta del paquete

De manera predeterminada, Visual Studio genera los paquetes de implementación en la carpeta identificada por la propiedad IntermediateOutputPath de MSBuild. La propiedad IntermediateOutputPath hace referencia a la carpeta obj\Configuración > del proyecto, como se muestra en la siguiente ilustración de la ventana Explorador de soluciones:

Los nombres predefinidos para Configuración son Debug (como se muestra en la ilustración anterior) y Release. Puede definir configuraciones de compilación adicionales.

El paquete se crea en una carpeta que se denomina Package. La carpeta Package contiene los siguientes archivos:

• nombreDeProyecto.zip. Se trata del paquete de implementación real.

• nombreDeProyecto.deploy.cmd. Es un archivo por lotes de la línea de comandos que invoca a Web Deploy para facilitar la instalación del paquete desde la línea de comandos.

• nombreDeProyecto.SetParameters.xml. Este archivo contiene parámetros que se pasan a Web Deploy cuando se usa el archivo deploy.cmd para instalar el paquete. En cada parámetro, se especifica un valor predeterminado que se establece en la configuración del paquete de Visual Studio. Por ejemplo, puede cambiar estos valores si desea instalar la aplicación web en varios servidores, pero desea usar una configuración distinta en cada servidor.

• nombreDeProyecto.SourceManifest.xml. Este archivo contiene la configuración que Visual Studio pasó a Web Deploy y que Web Deploy usó para crear el paquete web. Web Deploy necesita este archivo para poder crear el paquete. No se utiliza cuando el paquete está instalado.

Si opta por no crear el paquete como un archivo .zip, los archivos que pudieran estar almacenados en el archivo .zip estarán ubicados en una carpeta que se denomina Archive. En ese caso, el primer nodo de deploy.cmd es SetParameter.xml y el nombre de archivo de SourceManifest.xml es "Archivo" en lugar de NombreDeProyecto.

Las interrelaciones entre Visual Studio, Web Deploy y estos archivos se muestran en la siguiente ilustración:

Publicación con un solo clic

También puede realizar la implementación de forma remota utilizando la característica publicación con un solo clic de Visual Studio. En ese caso, debe especificar en un perfil de publicación cómo y dónde debe implementar Visual Studio la aplicación. En la ilustración siguiente se muestra el cuadro de diálogo Perfil de publicación.

Si usa la publicación con un solo clic para implementar la aplicación en una empresa de hospedaje de otro fabricante, la empresa de hospedaje normalmente le proporcionará los valores necesarios para el cuadro de diálogo Perfil de publicación.

Cuando termine de especificar la configuración pública, puede hacer clic en el botón Publicar de este cuadro de diálogo o en la barra de herramientas Publicación en Web con un solo clic. A continuación, Visual Studio implementa la aplicación en el equipo de destino. Si hace clic en el botón Publicar después de implementar el proyecto de aplicación web, Visual Studio solo implementa los elementos modificados.

Puede crear varios perfiles para que pueda publicar en distintos servidores o en el mismo servidor con valores diferentes.

Escenarios de empresa

En un entorno de empresa, la implementación se realiza normalmente desde un equipo de desarrollo en uno o más entornos intermedios, como un servidor de pruebas o un servidor de ensayo. Posteriormente, la implementación se realizará desde los entornos intermedios en el entorno de producción.

Los escenarios comunes para realizar la implementación inicial desde el entorno de desarrollo son, entre otros:

• Crear un paquete de implementación utilizando Visual Studio e instalarlo manualmente.

• Crear e instalar el paquete de implementación utilizando un proceso de la línea de comandos. Normalmente, esta operación se realiza por lotes desde un repositorio de control de código fuente utilizando MSBuild.

• Utilice la publicación con un solo clic. Esta opción está disponible si el equipo de desarrollo tiene acceso remoto al entorno del destino; si el equipo de destino está configurado para el método de publicación que seleccione, y si tiene los permisos adecuados en el equipo de destino. De forma predeterminada, la publicación con un solo clic no crea un paquete. Sin embargo, puede especificar que debe crearse un paquete para usarlo como archivo o copia de seguridad.

Para llevar la implementación de un entorno al siguiente después de la implementación inicial, puede usar el mismo paquete que se creó para la implementación inicial. Si lo desea, puede usar también Web Deploy para crear un nuevo paquete en el equipo desde el que está realizando la implementación.

La siguiente ilustración muestra algunos escenarios de empresa típicos.

Escenarios de hospedaje de otros fabricantes

Si utiliza una empresa de hospedaje de otro fabricante e implementa directamente desde el equipo de desarrollo en la empresa de hospedaje, tiene las siguientes opciones:

• Utilice la publicación con un solo clic de Visual Studio.

• Cree un paquete y utilice el Administrador de IIS para instalarlo de forma remota.

En la empresa de hospedaje, la aplicación puede estar en un entorno compartido o en servidores dedicados. Para las aplicaciones que se hospedan en entornos compartidos, existen normalmente limitaciones importantes en cuanto a su capacidad de configuración del entorno. Por ejemplo, normalmente no se le permite cambiar valores de IIS en un entorno de hospedaje compartido.

La siguiente ilustración muestra algunos escenarios típicos de host de otro fabricante.

Transformación del archivo Web.config

Los archivos Web.config suelen incluir valores que varían en función del entorno en el que se ejecuta la aplicación. Por ejemplo, es posible que tenga que realizar modificaciones como las siguientes al implementar un archivo Web.config en un servidor de destino:

• Cambiar la cadena de conexión de base de datos de modo que señale a la base de datos de producción.

• Deshabilitar la depuración en el entorno de producción.

• Quitar información confidencial, como cadenas de conexión, por ejemplo, si proporciona un paquete a un sitio de la comunidad.

Para administrar manualmente los cambios en un archivo Web.config, puede hacer lo siguiente:

• Modificar el archivo Web.config en el servidor de destino cada vez que se implemente el proyecto.

• Mantener versiones independientes del archivo Web.config para cada entorno (quizá en carpetas independientes o con nombres distintivos) y copiar solo la versión adecuada en el entorno de destino durante la implementación.

• Crear archivos XSLT para transformar el archivo Web.config y aplicar las transformaciones cuando la aplicación se implemente.

Para los proyectos de aplicación web, ASP.NET proporciona herramientas que automatizan el proceso de cambio (transformación) de archivos Web.config cuando se implementan. Para cada entorno en el que desee realizar una implementación, debe crear un archivo de transformación que especifique solo las diferencias en el archivo Web.config para ese entorno.

Los nombres de archivos de transformación incluyen el nombre del entorno de destino (el nombre de la configuración de compilación) como un nodo adicional entre "Web" y "config". Por ejemplo, el archivo de transformación de la configuración de compilación Debug se denomina Web.Debug.Config. En la ventana Explorador de soluciones de Visual Studio, estos archivos se agrupan automáticamente bajo el archivo Web.config, tal y como se muestra en la siguiente ilustración:

Un archivo de transformación es un archivo XML que especifica cómo se debería cambiar el archivo Web.config. Los archivos de transformación usan atributos XML diseñados específicamente para transformar los archivos Web.config de la implementación. Por ejemplo, suponga que su archivo Web.config tiene la siguiente sección de cadena de conexión:

<connectionStrings>
  <add name="ApplicationServices"
      connectionString="[TestDatabase]" />
</connectionStrings>

En el siguiente archivo de transformación se especifica que la cadena de conexión denominada ApplicationServices debe convertirse automáticamente para que señale a la base de datos de producción cuando se implemente la aplicación web.

<?xml version="1.0"?>
<configuration xmlns:xdt="https://schemas.microsoft.com/XML-Document-Transform">
  <connectionStrings>
    <add name="ApplicationServices" 
        connectionString="[ProductionDatabase]" 
        xdt:Transform="Replace" xdt:Locator="Match(name)"/>
  </connectionStrings>
</configuration>

En el ejemplo, el valor Match(name) del atributo Locator especifica que solo debe cambiarse el elemento add que tiene el mismo nombre (ApplicationServices). El valor Replace del atributo Transform especifica que el proceso de implementación debe reemplazar el elemento add completo.

Implementar una base de datos de SQL Server

Al implementar una aplicación web que usa una base de datos de SQL Server, es posible que tenga que propagar igualmente datos, estructuras de datos o ambas cosas. Para ello, Visual Studio puede crear automáticamente scripts (archivos .sql) en la base de datos de destino y estos scripts se pueden incluir en el paquete web. También puede incluir scripts de SQL Server personalizados y especificar el orden en el que se deben ejecutar los scripts. Web Deploy ejecuta los scripts en el servidor de destino cuando se instala el paquete.

Las opciones de implementación de SQL Server se especifican en la pestaña Empaquetar/publicar SQL de la página Propiedades del proyecto. La siguiente ilustración muestra la pestaña Empaquetar o publicar SQL.

Ampliar la canalización de publicación en Web

La canalización de publicación en Web (WPP) es el proceso que Visual Studio usa cuando se crea un paquete de implementación o una publicación con un solo clic. El trabajo que se realiza en WPP realmente lo llevan a cabo MSBuild y Web Deploy. Esta es la razón por la que está disponible la misma funcionalidad en Visual Studio o cuando se usan herramientas de línea de comandos para ejecutar la implementación.

Algunos aspectos de WPP se pueden extender modificando los archivos XML que controlan el comportamiento de MSBuild. Por ejemplo, algunas de las tareas que se pueden administrar modificando los archivos son:

• Excluir del paquete carpetas o archivos específicos de la aplicación web.

• Precompilar la aplicación web antes de crear el paquete.

• Instalar los ensamblados de la aplicación en la GAC del servidor de destino.

• Actualizar las claves del Registro en el servidor de destino.

• Instalar los certificados SSL en el servidor de destino.

Otras tareas requieren la ampliación de MSBuild y Web Deploy. Por ejemplo, suponga que su aplicación web usa MSMQ y desea automatizar la implementación de MSMQ. Para ello, puede crear un proveedor de MSMQ para Web Deploy y agregarlo a WPP modificando los archivos que controlan MSBuild.

Web Deploy usa el modelo de proveedor de .NET Framework. Un proveedor se encarga de cada tipo de información que debe administrarse para la implementación. Por ejemplo, hay un proveedor para la configuración de IIS, un proveedor para las bases de datos de SQL Server, un proveedor para contenido web, como los archivos .html y los archivos .aspx, etc.

Cuando Web Deploy crea un paquete, llama a cada proveedor para recopilar información que pertenece a la aplicación web que se va a implementar. Web Deploy invoca el proveedor para serializar la información y almacenarla en archivos. Cuando Web Deploy instala el paquete, el proveedor lee los archivos que creó para el paquete y deserializa la información del modo correspondiente para crear de nuevo la configuración original en el entorno de destino. Los proveedores deben ser capaces de administrar los parámetros en tiempo de instalación. Es decir, tienen que ser capaces de trabajar con los valores que se proporcionan en el tiempo de instalación en la interfaz de usuario del Administrador de IIS o en un archivo Parameters.xml.

En las ilustraciones siguientes se muestra el flujo de datos entre la información de una aplicación web, los proveedores de Web Deploy, la API de Web Deploy, un paquete de implementación y un archivo de parámetros. En la ilustración, Parameters.xml aparece junto al archivo .zip del paquete para dar cuenta de su rol. Sin embargo, Parameters.xml realmente está incluido en el archivo .zip del paquete.

Equipo de desarrollo

Servidor web

Web Deploy proporciona a los proveedores la mayoría de los tipos de recursos que pueden estar asociados a una aplicación web. Sin embargo, puede escribir un proveedor personalizado si ninguno de los proveedores integrados resulta adecuado para sus requisitos. Para obtener una lista de los proveedores disponibles, vea Web Deploy Providers en el sitio web de Microsoft TechNet.

En la ilustración siguiente se muestra una secuencia de pasos típica de WPP cuando se usa Web Deploy para empaquetar o publicar. Aquí se muestra una WPP que se ha extendido mediante los pasos siguientes:

• Se han excluido los archivos especificados.

• Se ha precompilado la aplicación web.

• Se han implementado los ensamblados de GAC, los ensamblados de COM y las claves del Registro.

• Se han implementado los certificados SSL.

Si decide realizar la implementación utilizando una publicación con un solo clic y usando un método distinto al de Web Deploy, puede extender solo las partes de WPP que no se apliquen a Web Deploy, como se muestra en la siguiente ilustración:

Para obtener ejemplos en los que se describe cómo se amplía la canalización de publicación en Web en determinados escenarios, vea las siguientes entradas en Visual Web Developer Team blog:

• How to extend the destination file to include registry settings for web deployment packages

• How to package and deploy COM components

• How to package .NET assemblies

Vea también

Conceptos

Asignación de contenido de implementación ASP.NET