Aunque Visual Studio 2005 hace fácil el despliegue y prueba de un aplicativo Web sobre la maquina local, es importante recordar que eventualmente deberá ser desplegada sobre un servidor Web Real. Hay tres formas de despliegue en aplicaciones ASP.Net:
Copiar Manualmente los archivos desde la maquina de desarrollo a la maquina objetivo, usando XCOPY, FTP, Comandos Visual Studio’s Copy Web Site, o algún otro programa gestos de archivos.
Precompilar la aplicación y desplegar, usando cualquier herramienta de línea de comandos o comandos Visual Studio’s Publish Web Site. Puedes completamente controlar la precompilacion y despliegue de una aplicación Web usando el add-in Web Desployment Project para Visual Studio. Esto requiere que el add-in sea primero descargado e instalado.
Usar el Web Setup Project de Visual Studio’s o Setup Wizard Project para crear un archivo de instalación .msi que pueda ser ejecutada sobre la maquina objetivo.
Pero antes de estas opciones primero se debe examinar un paso importante que se necesita antes de comenzar el despliegue: cambiar a ‘off’ la depuración en el archivo web.config. Cuando desplegamos una aplicación, es común tener que usar el depurador cuando rastreas un error o una pieza de código no operacional. Para permitir la depuración sobre un site completo, ambos el desarrollador o Visual Studio deben tener permitido esto en el archivo Web.config. Desafortunadamente, esta agrega símbolos depurados al código compilado, el cual incrementa el tamaño del assembly resultante; estos símbolos depurados extra decrecen el performance del tiempo de ejecución. Así, para un site que esta siendo desplegado a un servidor de producción, deberás deshabilitar la depuración en el archivo Web.config:
COPIANDO ARCHIVOS MANUALMENTE DESDE UNA MAQUINA DE DESARROLLO A UNA DE DESPLIEGUE
Esta es ciertamente la forma más fácil de desplegar una aplicación Web. Esto requiere copiar todos los archivos del proyecto a algún lugar sobre el servidor Web destino, usando FTP, Windows Explorer, el comando DOS XCOPY, o algún otro programa gestor. La gran ventaja de esto método es que si un archivo cambia en el futuro, todo lo que necesitaras es subir el file modificado al servidor. El ASP. NET runtime y el CLR .NET maneja el resto (el parseo, compilación de assemblies, y la compilación JIT) automáticamente.
Puedes también copiar archivos desde la maquina de desarrollo al servidor Visual Studio usando comando Copy Web Site, el cual esta disponible en el explorador de solución y dentro de menú Website:
Cuando el Copy Web Site es invocado, Visual Studio despliega una interface (ver figura2) que es familiar a cualquiera que haya usado un programa FTP como el WS_FTP.
Sobre la izquierda de la interface esta una lista de los files para la aplicación Web sobre la maquina de desarrollo. Deberás conectarte a la maquina destino primero usando el botón Connect. Haciéndolo así desplegaras el dialogo familiar Open Web Site (ver figura 3), por el cual podrás conectarte a una directorio virtual IIS remoto o local o a un lugar FTP remoto.
Figura 2: Interface Copy Web Site
Figura3: Open Web Site
Después que estés conectado al site, podrás subir files seleccionados desde la maquina local a la destino, descargar files seleccionados desde la de destino a la local, o sincronizar el site. La sincronización examina las fechas de archivos sobre ambos sites local y remoto; y asegura que todos los files sobre ambos sites estén actualizados de fecha. La sincronización puede ser también útil para ambientes multiprogramador donde
Los programadores mantienen copias del Web Site sobre sus computadores locales. Los desarrolladores individuales pueden copiar sus últimos cambios hacia un servidor remoto compartido y al mismo tiempo actualizar su computador local con los archivos modificados de otros desarrolladores. Sin embargo, puesto que allí no hay un mecanismo check-in/check-on mediante la sincronización (el cual previene que dos desarrolladores estén haciendo cambios al mismo file), esta no reemplaza a un sistema de control de versiones como el Microsoft SourceSafe.
PRECOMPILANDO UN WEB SITE
ASP.Net provee dos opciones para precompilar un site. El site puede ser precompilado sobre la maquina de despliegue dentro de assemblies (también llamado pre compilacion in-place), o esta puede ser precompilada sobre la maquina de desarrollo y después desplegada al servidor (también llamada pre compilacion por despliegue)
Precompilacion In-Place
Eficazmente ejecuta la misma compilación que ocurre cuando los usuarios requieren paginas del site. Eliminando así el performance penal para el primer requerimiento al site, así bien como verificar que el código del site sobre el servidor esta libre de errores en tiempo de compilación. La precompilacion In-Place requiere ejecutar el programa de línea de comando aspnet_compiler.exe sobre el servidor (el cual reside en
\[Windows folder]\Microsoft.NET\Framework\[version]). La sintaxis para la precompilacion in-place es como sigue:
aspnet_compiler -v virtualPath -OtherSwitches
La tabla 1 muestra algunas de los switches importantes de línea de comando para la herramienta aspnet_compiler
Tabla 1: Switches importantes aspnet_compiler.exe para la Precompilacion In-Place
Por ejemplo si tienes tu aplicación en un directorio virtual llamado Chapter sobre el servidor, usaras el siguiente comando para precompilar el site:
aspnet_compiler –v /Chapter
El aspnet_compiler crea assemblies para todos los executables producidos y los coloca en un folder especial bajo el folder \[Windows folder]\Microsoft.NET\Framework\
[version]\Temporary, como muestra la figura 5.
ASP:NET usa los assemblies en este folder para todas las solicitudes subsecuentes para esta aplicación. Nota que todos los formularios Web en el folder están ubicados en un único assembly, mientras cada control de usuario esta contenido en su propio assembly, y los recursos globales y locales están también compilados dentro de assemblies separados.
La pre compilación In-place requiere acceder a la ejecución de lineas de comando sobre el servidor de despliegue, el cual no siempre esta disponible al desarrollador.
Entradas
