Figura 1   Diagrama de la arquitectura .NET

Los desarrolladores pueden diseñar una gran variedad de tipos de aplicaciones con .NET Framework, como por ejemplo:

• Aplicaciones Windows
• Bibliotecas de clases
• Bibliotecas de control de Windows
• Aplicaciones Web ASP .NET
• Servicios Web ASP .NET
• Bibliotecas de control de Web
• Aplicaciones de consola
• Servicios de Windows
• Proyectos de configuración
• Proyectos de configuración de Web
• Complementos de Visual Studio .NET

Estos tipos de aplicación requieren diferentes procedimientos de implementación, y este documento recoge las principales alternativas.

Ensamblados .NET

Para simplificar la implementación de aplicaciones y componentes, .NET Framework presenta el concepto de los ensamblados. En la plataforma .NET, un ensamblado es la unidad de reutilización, creación de versiones, seguridad e implementación. En otras palabras, un ensamblado es un grupo de archivos, de cualquier tipo, que deben implementarse conjuntamente. En algunos casos, un ensamblado es un solo archivo, como un componente empaquetado como archivo DLL o como aplicación ejecutable. Sin embargo, un ensamblado puede contener otros archivos, como páginas HTML, archivos XML, archivos multimedia o cualquier otro tipo de archivo.

Los desarrolladores pueden utilizar los ensamblados para desacoplar la unidad lógica de implementación de la composición física del paquete que debe implementarse. Estos ensamblados pueden ser parte de una sola aplicación y pueden implementarse con ella, o pueden ser ensamblados compartidos utilizados por múltiples aplicaciones.

La información de metadatos de ensamblado se almacena en el manifiesto, que se incluye automáticamente en cada ensamblado. El IDE de Visual Studio .NET construye soluciones automáticamente en archivos EXE o DLL, y puede utilizarse la herramienta ildasm.exe (parte del SDK de .NET Framework) para ver el manifiesto de ensamblado, como en el ejemplo siguiente (aplicado a una sencilla aplicación "Hola mundo" de VB .NET).

Figure 2   Desensamblado de un manifiesto de ensamblado con ildasm.exe

Implementación de .NET con XCOPY

La implementación de ensamblados .NET es tan sencilla en comparación con las versiones anteriores que podríamos hablar de implementación XCOPY. La implementación XCOPY significa que, en la mayoría de los casos, es posible implementar aplicaciones .NET simplemente copiando los directorios de la aplicación en la ubicación de destino.

Las siguientes funciones de .NET hacen que este sencillo procedimiento de implementación sea posible.

• Cada ensamblado se autodescribe, ya que el ensamblado contiene los metadatos que definen sus contenidos. Esta función elimina la necesidad de registrar interminablemente las entradas que definen la interfaz pública de cada componente.
• Todos los componentes que forman parte de cualquier ensamblado .NET utilizan ubicaciones estándar, de manera que no es necesario definirlos en entradas específicas en el registro.
• Los archivos de configuración pueden modificar la ubicación de componentes específicos, pero el ensamblado busca estos archivos de configuración en ubicaciones estándar, evitando procesos de registro innecesarios.

Sin embargo, existen otras situaciones en las cuales el proceso de implementación es más complejo, como por ejemplo:

• La interoperatividad de las aplicaciones .NET con los componentes COM todavía requiere el registro.
• La compilación previa de un ensamblado en el código nativo del equipo remoto requiere un procesamiento más complejo que la simple copia de archivos en el directorio de destino.
• La instalación de ensamblados en la caché global de ensamblados del equipo remoto requiere una serie de pasos adicionales para que el ensamblado sea un ensamblado compartido global.
• Al instalar los servicios de Windows desarrollados con .NET Framework, el servicio necesita ser registrado como tal en el sistema de destino.
• El proceso de instalación para las aplicaciones .NET que requieren la configuración de objetos en otros servicios, como Active Directory, Internet Information Server y .NET Enterprise Servers, debe ejecutarse en algunas otras aplicaciones o secuencias de comandos para crear y configurar estos objetos.
• Al personalizar un entorno de usuario, como las entradas del menú Inicio, los accesos directos del escritorio, los subprogramas del panel de control, las carpetas personalizadas y los complementos de Office, la configuración requiere una aplicación instalada para crear estas entidades de personalización.

Implementación de .NET con Windows Installer

Windows Installer proporciona una solución robusta para implementar todo tipo de aplicaciones y componentes. La implementación se completa a través de los archivos de Windows Installer, que tienen la extensión .msi y que contienen descripciones para instalar aplicaciones, incluyendo:

• Todos los archivos de la aplicación, en modo comprimido
• Todas las opciones disponibles a través del proceso de instalación, cuando se utiliza una interfaz gráfica de usuario o un modo desatendido automático
• La ubicación de los archivos de la aplicación
• La configuración del entorno de usuario, como las entradas del menú Inicio y los iconos y accesos directos del escritorio
• La información de desinstalación
• Los requisitos de registro, si es necesario
• Otros valores de configuración necesarios para instalar y registrar satisfactoriamente la aplicación

La implementación de aplicaciones .NET requiere Windows Installer versión 2.0 o posterior, que se proporciona con todas las versiones de Windows 2000, Windows XP, y Windows Server 2003. Más adelante en este mismo documento se proporcionan instrucciones detalladas acerca de la obtención de la versión actualizada de Windows Installer para otras plataformas.

Para crear archivos .msi, debe utilizar una herramienta de otro fabricante. Algunos proveedores de software independientes, como InstallShield Software Corporation (www.installshield.com) y Wise Solutions, Inc. (www.wise.com), proporcionan distintos productos que puede utilizar para crear paquetes .msi. Una alternativa a estas herramientas puede ser la utilización de Microsoft Visual Studio .NET, como se explica más adelante en este mismo documento.

Utilidades de base de datos de MSI

El SDK de Windows Installer (incluido en el SDK de la plataforma Windows) le permite ver y editar paquetes .msi ya existentes mediante la herramienta ORCA.EXE. Este SDK está disponible para descargar desde la dirección http://www.microsoft.com/msdownload/platformsdk/sdkupdate (en inglés).

Este SDK incluye la herramienta msidb.exe, que puede utilizarse para exportar e importar secuencias de datos y tablas de bases de datos, combinar bases de datos .msi y aplicar transformaciones a bases de datos de Windows Installer. Para obtener información adicional acerca de las herramientas ORCA y MSIDB, consulte la documentación del SDK de Windows Installer.

Implementación de .NET con Microsoft Application Center

Application Center 2000 proporciona herramientas para implementar aplicaciones .NET en un conjunto de servidores Web de carga equilibrada o en un clúster de servidores con conmutación por error. Todos los servidores de un clúster se administran como un único servidor en Application Center 2000. La sincronización de clúster garantiza que las imágenes de la aplicación se replican automáticamente en todos los servidores participantes.

Es posible actualizar las aplicaciones de servidor sin concluir ningún servicio, con lo que se mejora la disponibilidad. Application Center 2000 facilita la implementación de aplicaciones o versiones nuevas de estaciones de trabajo de desarrollo y permite deshacer estos cambios en caso de que falle la implementación. También es posible utilizar lenguajes de creación de secuencias de comandos para automatizar el proceso de implementación a través de Application Center 2000, gracias a su completa API.

Queda fuera del objetivo de este documento una descripción más a fondo de la funcionalidad de Application Center 2000. Para obtener información adicional acerca de este producto, visite la dirección http://www.microsoft.com/applicationcenter/ (en inglés).

Implementación de .NET con Microsoft System Management Server

Microsoft System Management Server (SMS) puede proporcionar funciones adicionales a los paquetes de Windows Installer, especialmente respecto a la distribución de aplicaciones Windows .NET a equipos cliente y servicios Web y ASP .NET a diversos servidores Web .NET.

Con la utilización de SMS, puede obtener beneficios de modificación y configuración adicionales, como por ejemplo:

• Distribución inteligente de software a equipos y usuarios de destino en base a reglas administrativas predefinidas
• Comprobación anticipada de los requisitos de hardware y software en sistemas de destino
• Medición avanzada de software para realizar un seguimiento del uso del software, para ayudar en el diseño de la infraestructura a controlar la carga de trabajo actual y prevista
• Herramientas avanzadas de diagnóstico y solución de problemas para ajustar la infraestructura de red y del sistema

Para implementar los paquetes de instalación de Windows Installer con SMS 2.0, debe realizar las siguientes tareas:

• Verificar la disponibilidad en tiempo de ejecución de Windows Installer en todos los equipos de destino.
• Configurar un directorio de origen del paquete mediante la instalación administrativa de Windows Installer.
• Crear un paquete.
• Configurar recursos resistentes (opcional).
• Crear un programa para el paquete mediante la sintaxis de línea de comandos de Windows Installer.
• Especificar puntos de distribución para el paquete.
• Especificar cuentas de acceso para el paquete (opcional).
• Crear un anuncio.

Para obtener información adicional acerca del uso de SMS para implementar paquetes de instalación de Windows Installer, lea el artículo “Deploying Windows Installer Setup Packages with Systems Management Server 2.0,” ("Implementar paquetes de instalación de Windows Installer con Systems Management Server 2.0"), disponible en la dirección http://www.microsoft.com/smserver/techinfo/deployment/20/deployosapps/deploymsi.asp (en inglés).

Sin embargo, la práctica recomendada es el uso de Microsoft Application Center para implementar servicios Web y aplicaciones ASP .NET en un clúster o en conjuntos de servidores Web.

Crear un plan de proyecto de implementación

Planear el proyecto de implementación es un paso importante en la progresión lógica de la implementación de una aplicación .NET. Debe diseñar el plan de proyecto para que se ajuste a las infraestructuras y requisitos empresariales Microsoft Operations Framework (MOF) proporciona las directrices del proceso de implementación. Para obtener información adicional acerca de MOF, visite el sitio Web de MOF en la dirección www.microsoft.com/mof (en inglés).

Algunos pasos importantes a tener en cuenta al crear un plan de proyecto son los siguientes:

• Crear el esquema del plan de proyecto:
  • Definir el propósito y el ámbito del proyecto
  • Decidir la línea temporal adecuada para la implementación
• Planear la implementación, como se define en las directrices MOF generales:
  • Determinar los requisitos personales y de recursos
  • Crear equipos de proyecto
  • Recopilar información acerca del entorno actual
  • Establecer estándares y directrices
  • Controlar los riesgos
  • Formación
  • Realizar pruebas introductorias
  • Determinar dependencias y consideraciones técnicas
  • Finalizar un plan de proyecto

El proceso de implementación de soluciones .NET a menudo resulta una tarea repetitiva debido a que la implementación de una nueva solución .NET no es muy distinta de la anterior. Sin embargo, a pesar de que muchas soluciones seguirán un proceso similar, el hecho de seguir un plan de implementación adecuado asegurará una implementación satisfactoria con un mínimo riesgo para las actividades empresariales.

La estructura de administración de la implementación debería integrarse sin problemas con la estructura de administración actual, pero la estructura de administración debería ser adecuada para administrar las fases siguientes:

• Planear la implementación de la solución .NET
• Diseñar y administrar un laboratorio de pruebas de .NET para probar la implementación de la solución .NET
• Completar la implementación final en el entorno de producción

Desarrollar el proceso de creación del plan de proyecto

El desarrollo de una solución .NET sigue un ciclo vital, desde la definición de las metas y objetivos a la implementación final en el entorno de producción. Planear un proyecto de implementación puede proporcionar una orientación razonable a seguir durante el proceso de implementación, con detalles acerca del diseño, la implementación, la prueba, la modificación y la ejecución de cada actividad.

Determinar metas y objetivos

Durante esta fase del proceso de planeamiento, debe decidir la configuración lógica principal de la solución .NET a implementar, y poner un énfasis especial en la seguridad y la disponibilidad de las funciones. La infraestructura de red juega un papel fundamental en esta fase, ya que esta infraestructura está diseñada para proporcionar la seguridad y la funcionalidad necesarias para la ejecución de las actividades empresariales.

El objetivo de esta fase es definir el marco del proyecto de implementación, para asegurar que se obtendrá la aprobación ejecutiva necesaria para seguir en el proceso de implementación. Esta primera fase debe dar respuesta a las preguntas relacionadas con el proyecto de implementación específico, como por ejemplo:

• ¿Por qué la organización está implementando esta solución .NET específica?
• ¿Cuándo debe estar disponible la solución?
• ¿Cuál es el ámbito detallado del proyecto?
• ¿A quién afecta el proyecto?
• ¿Qué podemos considerar como una implementación satisfactoria?
• ¿Existe alguna solución .NET anterior implementada en el sistema? En caso afirmativo, ¿hay alguna interacción potencial entre las soluciones ya existentes y la solución implementada en este proyecto?
• ¿Existen otras aplicaciones, sistemas o software que puedan verse afectados por la implementación de esta solución? En caso afirmativo, ¿es necesario integrarlos con esta nueva solución? ¿Cómo se conseguirá esta integración?
• ¿Cuáles son los riesgos?
• ¿Quién estará involucrado en el proceso?

Algunos de los documentos que deben crearse para esta fase son los siguientes:

• Documento acerca de metas y objetivos
• Esquema del entorno actual
• Valoración de riesgos

Esta fase es importante para crear la guía básica de la implementación Debe proporcionar a todos los equipos involucrados una idea clara de los motivos de la implementación de esta solución, de cómo afecta al entorno actual y de cómo va a implementarse.

Esquema lógico del proyecto: Cuestiones relacionadas con directivas

Una solución .NET típica involucra a un conjunto de entidades distintas:

• Servidores de servicios de fondo
• Servidores de aplicación
• Servidores Web
• Aplicaciones de usuario final
• Usuarios

La Figura 3 muestra una topología típica de red para una solución .NET.

Figura 3   Una solución .NET típica

Los usuarios pueden ser internos o externos, y en cada caso es extremadamente importante determinar la funcionalidad a la cual deben poder tener acceso desde esta solución. Los usuarios internos deben agruparse en funciones, dependiendo del nivel del acceso que tienen en relación con esta solución específica. Para usuarios externos, la situación es un poco más compleja debido a que debe diferenciarse entre clientes, proveedores y asociados; incluso empleados conectados desde fuera de la red. Es necesario elaborar meticulosamente el plan para definir los permisos de disponibilidad y no disponibilidad para cada grupo.

En muchos casos, las aplicaciones de usuario final serán aplicaciones basadas en ASP .NET alojadas en un servidor Web. Por lo tanto, será necesario determinar la funcionalidad que debería estar disponible desde los servidores Web internos detrás del servidor de seguridad interno, y la funcionalidad que debería estar disponible para los usuarios externos desde fuera del servidor de seguridad interno.

Estas aplicaciones ASP .NET o Windows pueden utilizar la funcionalidad que proporcionan los servicios Web .NET. En este caso, es muy importante determinar los servicios que serán únicamente locales (que proporcionaran servicio exclusivamente a los usuarios de la intranet) y los servicios Web que estarán disponibles desde el exterior de la intranet.

Sin embargo, el proceso de toma de decisiones no acaba aquí. El hecho de tener un servicio Web disponible no significa que deba estar disponible para darle cualquier tipo de uso. Debe determinar el significado de los servicios "privados" y "públicos" en este contexto. Por lo tanto, debe agrupar los servicios Web en diversos grupos principales:

• Servicios Web privados disponibles únicamente para aplicaciones ASP .NET predefinidas que se ejecuten en servidores Web seleccionados.
• Servicios Web privados disponibles exclusivamente para aplicaciones Windows .NET predefinidas. Este caso equivale conceptualmente al anterior, ya que se considera que las aplicaciones ASP .NET y Windows son simples consumidoras del mismo servicio Web.
• Servicios Web disponibles en cualquier aplicación diseñada para ejecutarse en la intranet.
• Servicios Web públicos disponibles exclusivamente en aplicaciones ASP .NET predefinidas que se ejecutan en servidores Web públicos seleccionados pero que no están disponibles para otras aplicaciones.
• Servicios Web públicos disponibles públicamente para cualquier aplicación capaz de tener acceso al servidor que aloja el servicio.

Los servicios Web que prestan servicio a los componentes de infraestructura y plataforma deben situarse en la intranet local. Pueden tener el descubrimiento completo habilitado, ya que la obtención de acceso a estos servicios ya está protegida dentro de la intranet. Sin embargo, los servicios Web públicos situados fuera de la LAN privada deben presentar una capacidad de descubrimiento limitada. Se aplican consideraciones parecidas a las aplicaciones Web .NET privadas y públicas, ya que debe acordar las que estarán disponibles únicamente para los usuarios corporativos y las que estarán disponibles para los usuarios externos.

En algunas situaciones, es posible que quiera utilizar .NET Remoting en lugar de los servicios Web para aplicaciones de intranet. Para obtener una comparativa de las posibilidades de .NET Remoting y de los servicios Web, vea el sitio Web http://msdn.microsoft.com/library/en-us/dnadvnet/html/vbnet10232001.asp (en inglés). Los servicios Web pueden ser la opción ideal para establecer una buena comunicación entre aplicaciones que se ejecuten en distintas plataformas, aunque .NET Remoting puede resultar más eficaz y confiable entre aplicaciones basadas en .NET.

En cualquier caso, la decisión del método de autenticación que utilizará cada componente y el modo en que se autorizarán los recursos que se utilizarán es también muy importante. Puede tomar la decisión de forma programática, en cuyo caso esta configuración no estará disponible para modificaciones durante la fase de implementación. Sin embargo, durante la fase de implementación, puede personalizar esta configuración modificando los archivos de configuración, como se tratará más adelante en este documento.

Diseñar y administrar un laboratorio de pruebas de .NET

Para probar la viabilidad de un plan de implementación, resulta conveniente ejecutar un proyecto de implementación de prueba. El objetivo de este proyecto de prueba es realizar un seguimiento y resolver cualquier problema potencial, así como afinar el proceso de implementación sin interferir en el entorno de producción. Esta fase resulta fundamental para conseguir los objetivos de implementación y para mantenerse dentro de los plazos temporales y los límites presupuestarios.

El laboratorio de pruebas .NET debe ser una copia lógica del entorno de producción, incluyendo todas las capas de la red y los sistemas involucrados en la implantación. Cuanto más cerca esté del entorno de producción, más eficaz será el proyecto de prueba.

Una vez que el proyecto de prueba ya sea estable, el equipo de implementación puede reunirse para evaluar la viabilidad de la implantación final. Las principales etapas de esta fase son:

• Una especificación funcional finalizada y estable
• La prueba de concepto finalizada
• La prueba previa a la producción finalizada
• La prueba piloto finalizada
• El plan de administración de riesgos actualizado

Es posible que quiera desarrollar documentos de implementación adicionales para asistir al equipo de operaciones que se encargará de la implementación. Estos documentos pueden incluir:

• El plan de formación
• El plan de soporte o asistencia técnica al cliente
• El plan de transferencia de operaciones
• El plan de recuperación ante desastres

Durante esta fase, el plan de implementación será un plan dinámico sujeto a cambios continuos basados en las pruebas realizadas durante el programa de pruebas. Debe prestar atención especial a un plan de recuperación ante desastres, que debería ser plenamente probado y que debería intentar predecir y resolver todos los problemas potenciales conocidos.

Obtener opiniones sobre el proyecto

Para ayudarle a tomar la decisión de seguir más allá del proyecto de prueba, es necesario que obtenga las opiniones al respecto de todos los grupos que hayan participado en la prueba. Puede utilizar distintas técnicas para obtener esas opiniones, como por ejemplo:

• Formularios de opinión del sitio Web
• Reuniones con los directores
• Informes de problemas
• Encuestas
• Observaciones del equipo de operaciones de la red y el proyecto de TI

Intente obtener el máximo de información posible desde todos los distintos ángulos de la implementación de esta solución .NET específica, como por ejemplo:

• Formación
• Proceso de implantación
• Soporte técnico
• Comunicaciones
• Problemas encontrados
• Sugerencias para mejorar

Implantación de la producción

La fase final del proceso de implementación es la implantación de la producción. En este punto, ha probado todas las tareas en el laboratorio de pruebas como parte del programa de prueba y ha definido también todos los riesgos y los planes de contingencias. Debido a las diferencias entre el laboratorio de pruebas y el proceso real de producción, debe continuar con las pruebas y el ajuste del proceso iniciado en el proyecto de prueba.

El proceso de implantación de la producción debería estar plenamente documentado en el plan de implantación de la producción, que incluye información detallada acerca de cómo se implantan los distintos componentes. Debe prestarse especial atención a las dependencias entre componentes, si existen, especificando claramente el orden de implementación. El plan de recuperación ante desastres, que ya debería haberse probado en el laboratorio de pruebas, puede afinarse en este momento del proceso para que coincida con la realidad del entorno de producción.

Una vez completada la implementación y preparado el informe de cierre del proyecto para el patrocinador ejecutivo, puede decidir la ejecución de una revisión del proyecto. La revisión el proyecto puede evaluar los puntos fuertes y débiles del proyecto completo de forma objetiva, así como analizar la posibilidad de mejorar las futuras implementaciones de infraestructuras, gracias al conocimiento obtenido de la experiencia acumulada.

Implementación de proyectos en Visual Studio .NET

Para implementar aplicaciones .NET con Windows Installer, puede utilizar uno de los proyectos de implementación e instalación de Visual Studio .NET, como se muestra en la Figura 4:

Si su explorador no admite los marcos en línea, haga clic aquí para abrir una página independiente.

Figure 4   Agregar un proyecto de instalación con Visual Studio .NET

Figure 4   Agregar un proyecto de instalación con Visual Studio .NET

• El proyecto de instalación, Setup Project, crea un proyecto de Windows Installer para una aplicación basada en Windows.
• El proyecto de instalación Web, Web Setup Project, crea un proyecto Web de Windows Installer, al cual pueden agregarse manualmente los archivos durante el proceso de implementación.
• El proyecto de módulo de combinación, Merge Module Project, empaqueta componentes que pueden ser compartidos por diversas aplicaciones.
• El asistente para la configuración, Setup Wizard, ayuda paso a paso a los desarrolladores durante la creación de un proyecto de instalación.
• El proyecto de contenedor, Cab Project, prepara un archivo de contenedor para descargar en un explorador Web antiguo.

Tras crear un proyecto para implementarlo en el Web (llamado Web Setup Project, proyecto de instalación Web, en el IDE de VS .NET) no puede cambiarlo a un proyecto de Windows Installer (llamado Setup Project, Proyecto de instalación, en el IDE de VS .NET), ni viceversa. Para tener esta funcionalidad dual, debe crear dos proyectos de instalación distintos. Utilice el asistente para la instalación para crear un programa de instalación sencillo; sin embargo, el resto de tipos de proyecto proporcionan una mayor flexibilidad.

Un proyecto de instalación proporciona diversos editores. Puede ver estos editores seleccionando la entrada de menú correspondiente desde el menú contextual de un proyecto de instalación, como se muestra en la Figura 5

Figura 5   Seleccionar el editor desde el menú View (Ver) del proyecto de instalación

A continuación se muestran los editores disponibles que puede elegir desde su aplicación específica:

Editor del sistema de archivos. Con este editor, puede personalizar el escritorio del usuario y el menú Inicio y agregar archivos y accesos directos a la carpeta de la aplicación.

Figure 6   Ver las opciones disponibles desde el editor del sistema de archivos

Editor del registro. Utilice este editor para agregar claves o valores al registro, que posteriormente puedan utilizarse para almacenar la configuración predeterminada.

Figure 7   Ver la opciones disponibles desde el registro

Tipos de archivos. Utilice este editor para agregar tipos de archivos y acciones para aplicar a estos tipos de archivos, que se definen por su extensión. Por ejemplo, en la figura siguiente se define el tipo de archivo FGG (con la extensión .fgg) que contiene la acción Open

Interfaz de usuario. Use este editor para ajustar el aspecto de la aplicación de instalación. Esta configuración puede ocultar algunas pantallas del asistente de instalación o puede agregar más pantallas de una colección de estilos de plantilla. En la figura siguiente, puede ver que es posible definir los textos que deben mostrarse o las partes específicas del asistente (tenga en cuenta que los textos de la figura no aparecen completamente porque son demasiado grandes, pero tiene acceso para editarlos completamente).

Figura 9   Definir el diálogo de interfaz de usuario

Editor de acciones personalizadas. Utilice este editor para especificar los programas que deben ejecutarse cuando se ha seleccionado una acción específica. Esta función puede resultar muy útil al instalar componentes adicionales o para crear objetos específicos de base de datos. Estas acciones pueden ejecutarse bajo sucesos específicos, como por ejemplo:

Figura 9   Definir el diálogo de interfaz de usuario

Editor de acciones personalizadas. Utilice este editor para especificar los programas que deben ejecutarse cuando se ha seleccionado una acción específica. Esta función puede resultar muy útil al instalar componentes adicionales o para crear objetos específicos de base de datos. Estas acciones pueden ejecutarse bajo sucesos específicos, como por ejemplo:

• Instalar la aplicación
• Confirmar
• Deshacer el proceso de instalación
• Desinstalar la aplicación

Figura 10   Definir las acciones personalizadas

Editor de inicio de condiciones. Utilice este editor para especificar las condiciones que se comprobarán en el equipo de destino

Figura 11   Definir el inicio de condiciones

Configuración del proyecto de instalación

Las páginas de propiedades del proyecto de instalación le proporcionan la obtención de acceso a los valores de configuración. Para obtener acceso a estas páginas, seleccione Properties (Propiedades) en el menú contextual del proyecto, como se muestra en la Figura 12:

Si su explorador no admite los marcos en línea, haga clic aquí para abrir una página independiente.

Figura 12   Página de propiedades de un proyecto de configuración

Mediante el uso de esta página de configuración, puede determinar la configuración de la versión y la carpeta donde se crearán los archivos resultantes. Estos archivos pueden crearse de diversas formas, como se muestra en la Figura 13.

Figure 13   Definir cómo empaquetar los archivos de instalación

Mediante el uso de la opción de inicio que aparece en la Figura 14, puede seleccionar el tipo de iniciador de Windows Installer que se proporcionará (en caso de que fuera requerido por el equipo de destino).

Y como en el caso de cualquier proyecto .NET, este proyecto de instalación podría optimizarse por velocidad o por tamaño, como se muestra en la Figura 15.

Archivos de instalación

El proceso de creación del proyecto de instalación crea los siguientes archivos en la carpeta Debug o Release (en función del tipo de versión seleccionada), mostrados en la Tabla 1:

Tabla 1   Archivos creados durante la instalación

Implementar .NET Framework

Para ejecutar aplicaciones o servicios diseñados para .NET Framework en un equipo específico, el sistema necesita tener .NET Framework instalado. Ya que ninguna de las plataformas actuales de Microsoft incluye .NET Framework, uno de los primeros pasos es asegurarse de que .NET Framework está disponible en el equipo de destino.

Los equipos que ejecuten cualquier versión de Microsoft Windows Server 2003 tienen .NET Framework instalado, ya que forma parte del proceso de instalación estándar del sistema operativo. Los equipos que ejecuten Microsoft Windows XP pueden instalar .NET Framework a través del sitio Web Microsoft Windows Update. El uso del sitio Web Microsoft Windows Update es el procedimiento recomendado para actualizar .NET Framework con las últimas versiones y Service Packs.

Para equipos que ejecuten otras plataformas, .la versión redistribuible de NET Framework está disponible como la aplicación Dotnetfx.exe. Esta versión redistribuible está disponible actualmente en los siguientes lugares y productos:

• El sitio Web MSDN Downloads, en la dirección http://msdn.microsoft.com/downloads/sample.asp?url=/MSDN-FILES/027/001/829/msdncompositedoc.xml (en inglés).
• El SDK de .NET Framework, bajo el directorio dotNETRedist. Puede descargar el SDK de .NET Framework desde MSDN, en la dirección http://msdn.microsoft.com/downloads/sample.asp?url=/msdn-files/027/000/976/msdncompositedoc.xml (en inglés).
• El CD Windows Component Update (Actualización de componentes de Windows) de Microsoft Visual Studio .NET en el directorio dotNetFramework.
• El DVD de Microsoft Visual Studio .NET, en el directorio \wcu\dotNetFramework.

No ponga la versión redistribuible de .NET Framework disponible en la intranet o en el sitio Web. La versión más actualizada de este componente se consigue dirigiendo a los usuarios al sitio Web Microsoft Windows Update.

Esta versión redistribuible instala todos los archivos necesarios por los componentes del servidor y el cliente. El paquete redistribuible para .NET Framework admite las plataformas siguientes:

• Windows 98
• Windows 98 Second Edition
• Windows Millennium Edition (Windows ME)
• Windows NT 4.0 (Workstation o Server) con Service Pack 6a
• Windows 2000 (Professional, Server, o Advanced Server)
• Windows XP (Home y Professional)
• Windows Server 2003

Para ejecutar componentes de .NET Framework, necesitará también:

• Internet Explorer 5.01 o posterior. También puede descargar la última versión de Internet Explorer desde:
  • El sitio Web Microsoft Windows Update en la dirección http://v4.windowsupdate.microsoft.com/en/default.asp (en inglés)
  • El sitio de descarga de Internet Explorer en la dirección http://www.microsoft.com/windows/ie/downloads/default.asp (en inglés)
• Windows Installer 2.0 o posterior. Puede descargar la última versión de Windows Installer desde:
  • El sitio Web Microsoft Windows Update en la dirección http://v4.windowsupdate.microsoft.com/en/default.asp (en inglés)
  • Microsoft Download Center:

    http://www.microsoft.com/downloads/release.asp?ReleaseID=32831 (en inglés) (Windows 95, 98, 98 SE, y Me)

    http://www.microsoft.com/downloads/release.asp?ReleaseID=32832 (en inglés) (Windows NT 4.0 y Windows 2000)

  Debe tenerse en cuenta que Windows XP y Windows Server 2003 ya incluyen esta nueva versión. Sin embargo, es una buena idea comprobar las actualizaciones del sitio Web Microsoft Windows Update.

• Componentes de acceso a los datos en el servidor (se recomienda MDAC 2.7). Puede obtener la última versión de estos componentes desde la dirección http://www.microsoft.com/data/download.htm (en inglés).
• Internet Information Services (IIS) instalado en Windows 2000, Windows XP (Professional) y Windows Server 2003 (para ejecutar aplicaciones ASP.NET).

Implementación en el servidor

Las aplicaciones ASP .NET y los servicios Web están diseñados para ejecutarse como componentes del servidor, que a menudo se ejecutan en un equipo central en algún lugar de una red local o remota. Para ejecutar estas aplicaciones y servicios, debe asegurarse de que se cumplan todos los requisitos previos. Los servidores que ejecutan los sistemas operativos Windows Server 2003 incluyen todos los requisitos previos para ejecutar aplicaciones .NET.

Si la aplicación que va a implementarse no utiliza componentes del cliente, la implementación en el servidor es la única que debe realizarse. En tal caso, las aplicaciones Windows o los exploradores de Internet utilizarán la funcionalidad proporcionada por estas aplicaciones, y las aplicaciones "de alojamiento" no participarán en ningún proceso relacionado con la aplicación .NET.

Determinar los requisitos

Para asegurarse de que la aplicación de servidor .NET se ejecuta con un rendimiento adecuado, debe tener en cuenta los requisitos siguientes que aparecen en la Tabla 2:

Tabla 2   Requisitos del servidor para implementar aplicaciones .NET

Implementación en el cliente

Las aplicaciones ASP .NET y los servicios Web están diseñados para ejecutarse como componentes del servidor. El dispositivo cliente utiliza una aplicación host, como Internet Explorer, para ejecutar estas aplicaciones .NET, o ejecutará una aplicación .NET para utilizar estos servicios de forma remota. Los servidores que ejecutan los sistemas operativos Windows Server 2003 incluyen todos los requisitos previos para ejecutar aplicaciones .NET como dispositivos cliente.

En algunos casos, las aplicaciones .NET requerirán la implementación de componentes del cliente, y en tal caso las consideraciones sobre la implementación serán muy parecidas a la implementación de las aplicaciones de servidor .NET.

Determinar los requisitos

Para asegurarse de que la aplicación de servidor .NET se ejecuta en el dispositivo cliente con un rendimiento y una funcionalidad adecuados, debe tener en cuenta los requisitos siguientes que aparecen en la Tabla 3:

Tabla 3   Requisitos de cliente para ejecutar .NET

Consideraciones acerca de la seguridad

La autenticación y autorización de los servicios Web siguen exactamente las mismas reglas que la autenticación y autorización de aplicaciones ASP .NET. La Tabla 4 resume los distintos métodos de autenticación.

Tabla 4   Métodos de autenticación

Archivos de configuración de seguridad. Los archivos de configuración de seguridad para aplicaciones .NET están instalados en las ubicaciones siguientes que aparecen en la Tabla 5.

Tabla 5   Dónde encontrar los archivos de configuración

Para evitar que el archivo de seguridad quede dañado, debe utilizar una de las herramientas siguientes:

• Herramienta de configuración de .NET Framework (Mscorcfg.msc)
• Herramienta de directiva de seguridad de acceso a código (Caspol.exe)

Configurar aplicaciones .NET

La configuración de aplicaciones .NET reside en diversos archivos, que se detallan en los apartados siguientes. El objetivo de este apartado es proporcionar información sobre dónde encontrar estos archivos y explicar su objetivo y sus apartados principales.

Los archivos de configuración son archivos XML estándar. Los valores de configuración se ordenan como un conjunto predefinido de elementos definidos mediante etiquetas XML. Debe estar familiarizado con XML si desea editar directamente los archivos de configuración, y recuerde que los atributos y las etiquetas XML son sensibles a las mayúsculas y minúsculas.

Cada archivo de configuración utiliza exactamente un elemento <configuration> en el formato:

<configuration>
   <!-- configuration settings -->
</configuration>

Puede que este elemento contenga varios elementos secundarios, como aparecen en la Tabla 6. Esta tabla muestra los distintos apartados que puede encontrar en estos archivos de configuración y los elementos que definen estos apartados.

Puede encontrar algunos ejemplos de estos archivos de configuración XML en las direcciones:

• http://msdn.microsoft.com/library/en-us/dndotnet/html/remotingconfig.asp (en inglés)
• http://msdn.microsoft.com/library/en-us/cpguide/html/cpconversioning.asp (en inglés)

Tabla 6   Contenido de los archivos de configuración de .NET

<startup>

<runtime>

<system.runtime.remoting>

<system.net>

<mscorlib>

<configSections>
<appSettings>
<MyCustomSettings>

<system.diagnostics>

<system.web>

Archivos de configuración del equipo. El archivo machine.config está disponible en el directorio %ruta de instalación en tiempo de ejecución%\Config y contiene la configuración que afecta al equipo completo en el cual .NET está instalado. Por este motivo, resulta más conveniente almacenar la configuración de las aplicaciones en lugares distintos, como se tratará más adelante en este mismo documento.

La utilización de Windows Installer para implementar aplicaciones .NET puede aplicar los cambios requeridos en el archivo machine.config de forma automática, pero no así la implementación XCOPY.

Archivos de configuración de la aplicación. CLR busca primero la configuración de la aplicación en los archivos de configuración de las aplicaciones, y posteriormente va a los archivos de configuración del equipo. El nombre y la ubicación del archivo de configuración de la aplicación dependen del host de la aplicación, que puede ser en uno de los siguientes:

• Aplicación alojada en un host ejecutable. El archivo de configuración de una aplicación alojada en el host ejecutable está en el mismo directorio que la aplicación. El nombre del archivo de configuración es el nombre de la aplicación con una extensión .config. Por ejemplo, una aplicación llamada miAplic.exe puede asociarse a un archivo de configuración llamado miAplic.exe.config.

  Este es un archivo de configuración de aplicación de ejemplo (caspol.exe.config):

  <?xml version ="1.0"?>
  <configuration>
      <startup>
          <requiredRuntime  safemode="true"  imageVersion="v1.0.3705" version="v1.0.3705"  />
      </startup>
      <runtime>
          <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
              <publisherPolicy apply="no"/>
          </assemblyBinding>
      </runtime>
  </configuration>

• Aplicación alojada en ASP.NET. Los archivos de configuración ASP.NET se llaman Web.config. Los archivos de configuración en aplicaciones ASP.NET heredan la configuración de los archivos de configuración en la ruta de acceso de la dirección URL. Por ejemplo, para la dirección URL www.nwtraders.msft/marketing/year2002, donde www.nwtraders.msft/marketing es la aplicación Web, el archivo de configuración asociado con la aplicación está ubicado en www.nwtraders.msft/marketing. Las páginas ASP.NET que se encuentran en el subdirectorio /year2002 utilizan la configuración que se encuentra en el archivo de configuración a nivel de la aplicación y la del archivo de configuración que se encuentra en /year2002. Para obtener más información acerca de los archivos de configuración de ASP .NET, vea http://msdn.microsoft.com/library/en-us/cpguide/html/cpconaspnetconfiguration.asp (en inglés).
• Aplicación alojada en Internet Explorer. Si una aplicación alojada en Internet Explorer tiene un archivo de configuración, la ubicación de este archivo está especificada en una etiqueta <link> con la sintaxis siguiente: <link rel="Configuration" href="location">.

  En esta etiqueta, href proporciona a Internet Explorer la dirección URL del archivo de configuración. El archivo de configuración debe estar ubicado en el mismo sitio Web que la aplicación.

Implementar servicios Web

Todos los comentarios anteriores se aplican a cualquier tipo de servicio y aplicación .NET. Sin embargo, existen algunas consideraciones especiales a tener en cuenta en relación con los servicios Web.

La implementación de un servicio Web XML implica la copia del archivo .asmx y los ensamblados utilizados por el servicio Web XML, pero no parte de Microsoft .NET Framework, en el servidor Web. Por ejemplo, si tiene un servicio Web XML denominado StockServices para implementar el servicio Web XML, creará un directorio virtual en el servidor Web y situará el archivo .asmx del servicio Web XML en el directorio. El directorio virtual puede ser también una aplicación Web de IIS, aunque no es indispensable. La estructura típica de árbol de una aplicación de este tipo podría ser:

\Inetpub
\Wwwroot
\StockServices
StockServices.asmx
\Bin

En \Bin, puede agregar referencias a todos los ensamblados utilizados por el servicio Web XML que no son parte de Microsoft .NET Framework.

Elementos implementados con un servicio Web

Al publicar un servicio Web XML, se implementan los elementos siguientes de la Tabla 7 en un servidor Web.

Tabla 7   Elementos implementados con un servicio Web

Implementar bases de datos SQL Server utilizadas por aplicaciones .NET

Algunas aplicaciones .NET y servicios Web utilizan una base de datos SQL Server para almacenar datos de la aplicación. El proceso de implementación debe definirse para instalar automáticamente todos los elementos de almacenamiento necesarios, y puede utilizar cualquiera de las estrategias siguientes:

• Utilizar cualquier servidor SQL Server disponible. Si SQL Server ya se ejecuta en un servidor disponible para la aplicación .NET, esta aplicación puede estar configurada para almacenar sus datos en este servidor. En este caso, el programa de instalación debe proporcionar una opción para especificar la configuración siguiente (a través de la interfaz de usuario o a través de los valores de configuración):
  • El servidor en el que se ejecuta SQL Server, incluyendo el nombre de la instancia, si es necesario. Debe ser posible escribir directamente el nombre de la instancia del servidor a la que conectarse (con el formato NombreServidor\NombreInstancia) o la dirección IP y el número de puerto (con el formato nnn.nnn.nnn.nnn, pppp). Opcionalmente, el programa puede proporcionar un botón de búsqueda para buscar instancias de SQL Server disponibles.
  • Nombre de la base de datos. En función de los requisitos de la aplicación, puede ser una base de datos existente o una nueva. Si se necesita una nueva base de datos, el programa de instalación puede conectar un archivo de base de datos existente (implementado como parte del programa de instalación).
  • Método de autenticación. Debe ser posible seleccionar la autenticación de SQL Server (suministrando el nombre de usuario y la contraseña) o la autenticación integrada de Windows.
• Instalar una nueva instancia de SQL Server. Esta instalación debe pasarse en base a una entrada específica durante los valores de configuración o instalación. Para obtener instrucciones específicas acerca de la configuración de SQL Server, consulte el sitio Web que trata sobre la implementación de SQL Server, en la dirección http://www.microsoft.com/sql/techinfo/deployment/2000/default.asp (en inglés)
• Instalar un nuevo SQL Server Desktop Engine (Motor de escritorio de SQL Server). Si el único objetivo de la base de datos que va a implementarse es proporcionar servicio a la aplicación .NET que se está implementando, puede resultar conveniente instalar el motor de escritorio de SQL Server, SQL Server Desktop Engine. Esta versión de SQL Server, sujeta a las directrices de uso definidas en la licencia, no requiere ninguna licencia de obtención de acceso de servidor o cliente. Mientras el desarrollador tenga una licencia válida para desarrollar aplicaciones con SQL Server Desktop Engine y el rendimiento necesario de la aplicación .NET sea compatible con las limitaciones de Desktop Engine, puede ser una solución excelente. Para obtener más información acerca de SQL Server Desktop Engine, visite el siguiente sitio Web: http://www.microsoft.com/sql/techinfo/development/2000/MSDE2000.asp (en inglés). Encontrará información específica acerca de cómo incrustar SQL Server Desktop Engine en aplicaciones personalizadas en la dirección http://www.microsoft.com/sql/techinfo/development/2000/embeddingmsde.asp (en inglés).

Conectar una base de datos SQL Server

Si la implementación de una aplicación .NET incluye una base de datos SQL Server, el método más sencillo para conseguir la implementación consiste en utilizar la función para conectar bases de datos de SQL Server. A continuación se muestran los pasos que deben seguirse para implementar una base de datos SQL Server que debe conectarse a un SQL Server ya existente o instalado de nuevo:

• Cree la base de datos SQL Server completa durante la fase de desarrollo de la aplicación. Esta base de datos debe contener todos los objetos, usuarios, permisos y datos predeterminados necesarios para iniciar la aplicación. Utilice cualquier instancia de SQL Server 2000 existente para crear esta base de datos.
• Desconecte la base de datos. Utilice el procedimiento sp_detach_db almacenado para desconectar la base de datos de SQL Server. Puede encontrar la sintaxis de este procedimiento almacenado del sistema en la dirección http://msdn.microsoft.com/library/en-us/tsqlref/ts_sp_da-di_83fm.asp (en inglés).
• Incluya el archivo de base de datos en el proyecto de implementación. Para la implementación, únicamente es necesario implementar el archivo o los archivos de datos. Normalmente estos archivos tienen la extensión .mdf para el archivo principal y .ndf para cualquier archivo secundario, si existe alguno. Los archivos de registro, con la extensión .ldf, no son necesarios para esta implementación, porque el proceso para conectar la base de datos creará un archivo de registro de transacciones vacío.
• Diseñe la aplicación de instalación para conectar la base de datos al sistema de destino. Siga las directrices detalladas anteriormente en este documento para seleccionar la instancia de SQL Server a la cual debe conectarse la base de datos. Conecte la base de datos al servidor de destino mediante el procedimiento almacenado sp_attach_db. Puede encontrar la sintaxis de este procedimiento almacenado del sistema en la dirección http://msdn.microsoft.com/library/en-us/tsqlref/ts_sp_ae-az_52oy.asp (en inglés).

Conclusión

Microsoft .NET Framework proporciona a los desarrolladores una plataforma robusta y ampliable para crear soluciones escalables y seguras. .NET Framework también amplía las posibilidades ya disponibles en Windows 2000, IIS y SQL Server, pero la implementación de estas nuevas soluciones es muy distinta de la de sus predecesores. Este documento ofrece instrucciones detalladas acerca de cómo preparar aplicaciones .NET para implementarlas mediante Windows Installer y la implementación XCOPY. Sin embargo, el objetivo más importante de este documento es resaltar la importancia de probar y diseñar cuidadosamente el proceso de implementación para lograr una implementación satisfactoria en el entorno de producción final.

Basado en Documentación de technet