Implementación de aplicaciones de Windows Forms con ClickOnce

18 de Julio de 2005

Publicado: Diciembre de 2004

Mauro Sant'Anna

Director regional de Microsoft

Resumen: en este artículo se examina la tecnología ClickOnce, se compara con otras tecnologías de implementación y se muestra cómo se puede utilizar en sus aplicaciones. (11 páginas impresas.) (Este artículo contiene vínculos a páginas en inglés.)

En esta página

Introducción Introducción
¿Por qué Windows Forms? ¿Por qué Windows Forms?
.NET Framework 1.x: HREFing .EXEs .NET Framework 1.x: HREFing .EXEs
Updater Application Block (UAB) Updater Application Block (UAB)
ClickOnce ClickOnce
Aplicación ClickOnce Aplicación ClickOnce
Detalles de implementación Detalles de implementación
Ejecución de la aplicación Ejecución de la aplicación
Conclusión Conclusión

En esta página

Introducción Introducción
¿Por qué Windows Forms? ¿Por qué Windows Forms?
.NET Framework 1.x: HREFing .EXEs .NET Framework 1.x: HREFing .EXEs
Updater Application Block (UAB) Updater Application Block (UAB)
ClickOnce ClickOnce
Aplicación ClickOnce Aplicación ClickOnce
Detalles de implementación Detalles de implementación
Ejecución de la aplicación Ejecución de la aplicación
Conclusión Conclusión

Introducción

ClickOnce es una nueva tecnología de implementación de Windows Forms que se incluirá con Visual Studio 2005. Esta tecnología facilita el proceso de instalación de aplicaciones, así como de actualización de aplicaciones Web con clientes inteligentes. La implementación de aplicaciones de Windows Forms a través de HTTP ha estado disponible desde la primera versión de .NET Framework y desde entonces no ha dejado de evolucionar. En este artículo se describen las ventajas de las aplicaciones de Windows Forms y la evolución de esta tecnología hacia ClickOnce. También se mostrará un ejemplo sencillo con la versión Beta 1 pública de Visual Studio 2005.

¿Por qué Windows Forms?

Desde que apareció el World Wide Web, la mayor parte de los usuarios y desarrolladores han demostrado un mayor interés en las aplicaciones Web que en las aplicaciones "normales" de Windows. Además de estar de moda, las aplicaciones Web cuentan con características especiales e interesantes:

  • Se puede tener acceso a una aplicación Web desde cualquier parte del mundo en el que haya disponible una conexión a Internet; el cliente no necesita ni siquiera ejecutar Windows. Una aplicación "Web pura" es una tecnología estupenda cuando la aplicación necesita acceso ubicuo.

  • Las aplicaciones Web resultan fáciles de implementar y actualizar: basta con copiar los archivos de la aplicación en un directorio del servidor Web y todos los clientes podrán empezar a utilizar de inmediato la nueva aplicación. Se acabaron los infiernos de las bibliotecas DLL, los enredos en las entradas del registro, el registro de clases COM: ahora todo funciona.

Este artículo se centra en el segundo punto mencionado arriba: la implementación. El protocolo HTTP que utilizan las aplicaciones Web presenta varias ventajas con respecto a la tradicional implementación de aplicaciones de Windows.

Por un lado, aunque personalmente sea partidario del Web, resulta difícil afirmar que la experiencia del usuario en el mismo es estelar. Si se compara con las aplicaciones de Windows, el Web presenta varias desventajas:

  • La interfaz de usuario resulta bastante pobre. Funciones que se dan por sentado en una aplicación de Windows, como arrastrar y colocar o hacer clic con el botón secundario del mouse (ratón), se convierten en una difícil, si no imposible, tarea en una aplicación Web.

  • Incluso cuando se consiguen realizar diversos trucos con la interfaz, se exige normalmente una cantidad increíble de secuencias de comandos del cliente, un tipo de código que resulta especialmente difícil de escribir y depurar.

  • Las aplicaciones Web utilizan un gran número de recursos del servidor, un gran ancho de banda y mucha paciencia por parte del usuario, ya que la mayoría de las tareas se deben hacer en el servidor con un recorrido de ida y vuelta, lo que requiere cierto grado de paciencia.

  • La impresión se limita a la "tecnología de imprimir pantalla", con poco control sobre elementos como saltos de página debido a las distintas fuentes, márgenes y tamaño del papel.

  • Algunos de los problemas mencionados hasta ahora se pueden mitigar con el uso de complementos o controles ActiveX, pero estos, a su vez, tienden a presentar los mismos problemas de implementación que solían tener las antiguas aplicaciones que no eran Web.

¿Qué ocurriría si se pudiera unir la sencillez de distribución de las aplicaciones Web con la variada experiencia de los clientes de las aplicaciones de Windows? En realidad, se puede. Desde la primera versión, .NET Framework permite la distribución de las aplicaciones de Windows Forms a través de HTTP y sin los problemas habituales.

Este tipo de aplicaciones resulta especialmente interesante en escenarios de intranet/extranet, donde no es necesario el acceso ubicuo y se supone que el equipo del usuario final tendrá instalados tanto Internet Explorer como .NET Framework.

.NET Framework 1.x: HREFing .EXEs

Las versiones 1.0 y 1.1 de .NET Framework se distribuyeron desde el principio con la capacidad de implementar las aplicaciones de Windows Forms a través de HTTP. Básicamente se utiliza una etiqueta "HREF" para señalar a un ejecutable .EXE administrado. Internet Explorer y .NET Framework Runtime pueden descargar y ejecutar no sólo el ejecutable, sino también las DLL que pueda necesitar, a petición. Este tipo de implementación ha recibido el apodo de "hrefing EXEs".

A continuación, se muestra un ejemplo de dicha etiqueta:

<a href="MainProject.exe">Call MainProject</a>
			

Esta tarea resulta bastante sencilla y se ha descrito en los siguientes artículos recomendados:

Debido a que el ensamblado .NET (.EXE o .DLL) es la unidad de implementación básica, desea dividir la aplicación en un ejecutable .EXE principal y varias DLL. De este modo, si realiza cambios sencillos en una sola DLL, únicamente será necesario descargar dicha DLL.

Aunque resulta tan sencillo como parece, hay aún algunos trucos para que todo funcione correctamente:

  • .NET Framework deberá haberse instalado anteriormente en el cliente (aunque puede descargar un complemento de http://msdn.microsoft.com/vstudio/downloads/tools/bootstrapper/ que puede facilitar la instalación de Framework y su aplicación).

  • Su aplicación se ejecutará en el cliente como código de confianza parcial. Por un lado, esto es positivo, ya que la aplicación se ejecuta en un entorno de seguridad y tiene limitaciones con respecto a lo que puede hacer en el equipo cliente. Por otra parte, si necesita funcionalidades como abrir archivos locales o realizar llamadas a un objeto COM, debe encontrar una manera de configurar una directiva de seguridad en el cliente, una tarea nada trivial.

  • De forma predeterminada, es bastante probable que su ejecutable intente cargar varias DLL con los recursos de localización; debido a algunos problemas en la implementación actual, se verá mermado el rendimiento, especialmente en un vínculo de Internet lento.

  • Las actualizaciones se realizan archivo por archivo; así, por ejemplo, no hay forma de garantizar que la totalidad de los 10 archivos actualizados se hayan, de hecho, descargado. De este modo, puede que el cliente se quede con una aplicación actualizada a medias.

  • La aplicación se encuentra disponible sin conexión solamente si el usuario ha configurado manualmente "Trabajar sin conexión" en Internet Explorer; la propia aplicación no tiene control sobre esta opción.

  • De forma predeterminada, el archivo .config asociado al programa no está disponible (consulte aquí la forma de hacerlo).

  • Su aplicación no tendrá un acceso directo en el escritorio o en el menú Inicio.

Updater Application Block (UAB)

Para solucionar algunos de los problemas señalados anteriormente, Microsoft creó Updater Application Block (UAB). El bloque del actualizador es una biblioteca que puede agregar a su aplicación para administrar la descarga de las partes de la aplicación a través de HTTP.

Presenta algunas ventajas con respecto a la implementación original de Framework:

  • Se ejecuta como aplicación local y se encuentra disponible en todo momento sin penalizaciones de rendimiento.

  • Se procesan las actualizaciones, es decir, se deben descargar correctamente todos los archivos de una nueva versión para que esté disponible.

  • Todos los archivos de la aplicación se muestran en un manifiesto.

  • Se ejecuta como una aplicación de plena confianza, no son necesarias directivas de seguridad.

  • La aplicación puede tener algunos accesos directos en el menú Inicio.

Por otra parte, también presenta algunas desventajas:

  • Debe cambiar de forma considerable la aplicación para poder utilizarla.

  • Puesto que utiliza BITS para descargar las distintas partes de la aplicación, no se ejecuta con Windows 98/ME; es necesario Windows 2000 o una versión posterior.

  • Se ejecuta como una aplicación local de plena confianza, por lo que no tiene en cuenta en gran medida la seguridad de acceso al código.

  • No es compatible con Microsoft.

Para obtener más información acerca de UAB, consulte .NET Application Updater Component de Jamie Cool. También puede consultar la página principal de UAB en Gotdotnet. UAB no es compatible "oficialmente", aunque hay un foro en http://www.gotdotnet.com/. En cualquier caso, UAB se proporciona con el código fuente completo, por lo que puede modificarlo para que se ajuste a sus restricciones, como el requisito de BITS y Windows 2000.

ClickOnce

UAB se trata claramente de una medida temporal mientras Microsoft desarrolla una solución definitiva. Esta solución es ClickOnce. Básicamente, ClickOnce tiene todas las ventajas de UAB con algunos de sus inconvenientes, además de funcionalidad agregada. En mi opinión, una de las principales ventajas de ClickOnce es que restaura la seguridad de acceso al código.

Si se compara con HREF EXEs, una aplicación ClickOnce presenta las siguientes ventajas:

  • Las actualizaciones se procesan (es decir, se realizan en su totalidad o no se realizan).

  • La aplicación no sólo puede funcionar sin conexión sino que tiene un cierto grado de control sobre sí misma, hay API para que la aplicación pueda averiguar si está con o sin conexión; también permite controlar su propio proceso de actualización;

  • Tiene una buena integración con Visual Studio .NET, incluida la capacidad de generar las herramientas y archivos adicionales adecuados que permitirán adivinar los privilegios de seguridad que necesita su aplicación para poder ejecutarse.

  • Se suministra con un ejecutable "bootstraper" Win32 que puede descargar los componentes necesarios, incluso el propio .NET Framework.

  • Los archivos de la aplicación se pueden descargar a petición o en lotes;

  • Puede tener accesos directos al menú Inicio;

ClickOnce es una característica de Visual Studio 2005, anteriormente denominada "Whidbey" y .NET Framework 2.0. A continuación, examinemos un ejemplo con "Community Preview Beta 1" (Framework versión 2.0.40607).

Aplicación ClickOnce

Procederemos a crear una aplicación ClickOnce sencilla; para ello se deberán realizar los siguientes pasos.

  1. Inicie Visual Studio 2005.

  2. Seleccione File y, a continuación, New Project.

  3. Elija un lenguaje (C# o Visual Basic .NET) y seleccione Windows Application.

  4. Asigne el nombre MyClickOnceApp y haga clic en OK.

  5. Agregue un botón al formulario y cambie la propiedad Text por About.

  6. Haga doble clic en el botón. En la ventana de código, escriba el siguiente código.

Visual Basic .NET:

MsgBox("My First ClickOnce Application")

Visual Basic .NET:

MessageBox.Show("My First ClickOnce Application");

Presione F5 para ejecutar y probar la aplicación.

Todas las aplicaciones de Windows en Visual Studio 2005 tienen una página Publish en Project | MyClickOnceApp Properties para controlar los detalles de implementación:

Figura 1. Configuración de valores de publicación

Publishing Location indica la ubicación desde la que se implementará la aplicación. Puede ser la ubicación de un servidor Web (HTTP), como se muestra arriba, aunque también puede ser una ruta de red normal.

Install Mode and Settings controla varios detalles de la implementación, como:

  • Si la aplicación estará disponible en línea solamente o también sin conexión.

  • Application Files: el lugar donde se instalarán archivos individuales.

  • Prerequisites: si el programa de instalación instalará otros componentes, como Windows Installer 2.0, .NET Framework 2.0, J# Redistributable Package, SQL Server 2005 Express, Crystal Reports y Microsoft Data Access Components 2.8.

Figura 2. Configuración de requisitos previos

  • Updates: controla cuándo la aplicación debe buscar actualizaciones y cómo se deben traer éstas al cliente.

Figura 3. Configuración de actualizaciones

  • Options: ajusta detalles como el idioma de la aplicación, el nombre del recurso del acceso directo al menú Inicio, la página HTML utilizada para la implementación Web y el vale de directiva de implementación.

Figura 4. Configuración de opciones de publicación

La opción de publicación de versiones Publish Version ajusta el número de la versión de la aplicación, este número puede aumentar automáticamente en cada implementación.

El asistente para publicación Publish Wizard permite configurar distintas opciones de publicación. Este asistente también se puede abrir desde el menú Build | Publish. Todas las aplicaciones ClickOnce deben estar firmadas criptográficamente; el asistente solicita una clave existente (opción recomendada) o puede generar una nueva.

Figura 5. Firma de la aplicación

Después de que haya ejecutado el asistente una vez, puede hacer clic en Publish Now para publicar actualizaciones. En nuestro ejemplo se mostrará una página Web.

Figura 6. Aplicación publicada

Esta página Web contiene una secuencia de comandos que comprueba qué paquete de requisitos previos se debe instalar antes de instalar nuestra aplicación. Si no hay ningún requisito previo, se instalará la primera vez que se ejecute la aplicación.

Una vez que el usuario hace clic en el vínculo Install, puede que aparezcan varios cuadros de diálogo que requieran la intervención del usuario, al menos la primera vez que se ejecuta:

  • Advertencias de Windows XP SP2

  • Aceptación de las licencias de software

  • Falta de comprobación de la firma del editor

Detalles de implementación

Visual Studio .NET 2005 creará una nueva Web para nuestra aplicación con varios archivos y carpetas.

Figura 7. Carpetas de implementación

La carpeta dotnetfx contiene el redistribuible de .NET Framework, actualmente un ejecutable de 25 MB.

De forma predeterminada, Visual Studio aumentará el número de la versión cada vez que se implemente la aplicación; cada versión tendrá una nueva carpeta con el correspondiente número de la versión modificado

El archivo .application es el objetivo del vínculo mostrado en la página HTML publish.htm. Se trata de un archivo XML que contiene información como la carpeta correspondiente a la versión actual de la aplicación y firmas digitales.

Publish.htm es una página Web que no sólo contiene el vínculo al archivo .application, sino también parte de la secuencia de comandos que comprueba la versión y muestra los mensajes correspondientes. Por ejemplo, si su equipo no dispone de .NET Framework, el mensaje mostrado en Install MyClickOnceApp será diferente.

Setup.exe es un ejecutable Win32 capaz de instalar no sólo su aplicación, sino también todos los componentes necesarios como el propio .NET Framework y MDAC 2.8 en el orden correcto.

Cada carpeta de la aplicación contiene los archivos de ésta además de un archivo de manifiesto. Se trata de un archivo XML que contiene básicamente la siguiente información:

  • Identidad precisa de todos los archivos de la aplicación. Esta identidad incluye el nombre del archivo, número de la versión, referencia cultural y arquitectura del procesador ("msil" en nuestro caso).

  • Todos los permisos que necesita la aplicación.

  • Firmas digitales.

Ejecución de la aplicación

Una vez que se ha descargado la aplicación, puede ejecutarla sin necesidad de descargarla de nuevo. En nuestro ejemplo, se puede iniciar la aplicación si hace clic en el vínculo a la página Web o el acceso directo del menú Inicio. En ambos casos, se comprueba la existencia de una nueva versión según la configuración de las opciones del proyecto de Application Updates. Si es necesario, se descarga una nueva versión.

Para comprobar esta capacidad de actualización, haga lo siguiente:

  1. Realice un cambio visible en la aplicación, como modificar la ubicación del botón en el formulario.

  2. Vuelva a generarlo e implementarlo

  3. Ejecute la aplicación y compruebe el proceso de descarga.

Como nota final, es importante advertir que esta información está basada en la versión Beta 1 de Visual Studio .NET; puede que las versiones más recientes tengan características distintas.

Tabla comparativa

.

HREF .EXE

UAB

ClickOnce

No se necesitan cambios en la aplicación

X

.

X

Aislamiento de la aplicación

X

.

X

Totalmente compatible

X

.

X

Poco impacto en el sistema

X

.

X

Se mantiene la seguridad de acceso al código

X

.

X

Descarga de archivos a petición

X

.

X

Se manifiesta para mostrar mediante declaración los archivos necesarios

.

X

X

Manifiestos firmados criptográficamente

.

.

X

Descarga de archivos por lotes

.

X

X

Trabajar sin conexión

(*)

X

X

Instalaciones procesadas

.

X

X

Rendimiento óptimo

.

X

X

Se necesita Windows 2000 o posterior

.

X

(**)

Integración de shell de Windows

.

X

X

Control adecuado del proceso de actualización

.

X

X

API para trabajar sin conexión y controlar el proceso de descarga

.

.

X

Instalación automática de paquetes opcionales

.

.

X

(*) Requiere la intervención del usuario

(**) Demasiado pronto para afirmar de un producto beta

Conclusión

ClickOnce es una tecnología de gran eficacia para la implementación de aplicaciones. Supone la evolución natural de los modelos de implementación disponibles anteriormente, aportando solidez, seguridad, rendimiento y flexibilidad a la variada experiencia de clientes de las aplicaciones de Windows Forms.

Acerca del autor

Mauro Sant'Anna (mas_mauro@hotmail.com) es Director regional de Microsoft, MCSD, MCSE, desarrollador y profesor. Es un fiel creyente en .NET desde su aparición pública en PDC 2000 en Orlando.

Mostrar: