Datapayasadas

octubre 20, 2009

Actualizador (1era Parte)

Filed under: .Net, C#, Desarrollo — Etiquetas: , — Matías @ 10:17 am

Buenas,

Esta es la primera parte de una serie de artículos en los que voy a mostrarles como hacer su propio Actualizador para utilizar en sus programas. Todavía no he decidido de cuantas partes va a constar, porque en realidad no he planificado nada, así que si después terminan siendo solo dos, ¡quedan avisados de antemano!.

Comencemos

Por lo general, siempre que creamos un programa y lo liberamos al público, vemos al (poco) tiempo la necesidad de hacerle algunos retoques ya sea por la aparición de bugs (si, si, aparecen de la nada, no es que estaban y los pasamos por alto, jajaja) que nos reportan nuestros usuarios o porque queremos agregarle nuevas funcionalidades. Sea por lo que sea, una parte importante para mantener un software estable es la capacidad del mismo para informar la existencia de nuevas versiones o mejor aún, auto actualizarse simplificándole la vida al usuario.

Como ya habrán visto en gran variedad de programas, hay distintas formas de manejar el tema de actualizaciones. Hay que saber poner en la balanza que es lo que queremos: facilitarnos la vida nosotros, como desarrolladores, o simplificarle la vida a nuestros usuarios.

En un extremo, podríamos solamente comprobar un archivo de texto online con la referencia a la última versión. Ese número lo comparamos con el assembly local y en caso de ser diferente redirigimos al usuario a la página de descarga para que él mismo se encargue de todo el proceso (o le preguntamos mejor si quiere ir allí). Como verán, esto es muy simple de implementar, sin embargo, lo más probable es que terminemos molestando al usuario.

Por otro lado también he visto programas donde lo que se hace luego de comprobar la versión online, es solicitar permiso al usuario para descargar el nuevo instalador, es decir, la versión actualizada, dentro del mismo programa. Cuando finaliza la descarga se cierra el programa principal, se ejecuta el instalador y listo. Sin embargo hay un pequeño problema en este escenario, ¿qué pasa si el usuario no tiene permisos suficientes para instalar un programa?. También podríamos decir que no es lo mejor cuando queremos que nuestro programa sea portable, aunque en este caso hay algunos work-around para hacer un falso instalador que no escriba en el registro de Windows.

Si bien existen algunas soluciones ya integradas en .Net y de simple aplicación con Visual Studio, como ser Click Once, hay veces que requerimos de algo más personalizado y que se ajuste mejor a nuestras necesidades. Por este motivo es que he decidido mostrarles la solución que encontré yo para uno de mis proyectos, con esto quiero decir que no lo tomen como una solución universal, cada caso requiere un detallado análisis para poder evaluar cuál se ajusta más.

Para empezar vamos a necesitar dejar en claro que es lo que hace o debería hacer un Actualizador:

  • Comparar versiones locales de archivos con algún repositorio remoto, y en caso de hacer falta descargar actualizaciones.
  • Armar un listado de los archivos a medida que se van reemplazando para hacer un rollback en el caso que algo salga mal.
  • Ser capaz no solo de actualizar otros programas, sino también, de actualizarse a si mismo.

Esos son los puntos básicos y necesarios sobre los cuales nos vamos a poner a trabajar.

Planteando la estructura

Nuestro programa va a contar con tres funciones principales:

  1. Comprobar actualizaciones
  2. Descargar actualizaciones
  3. Limpiar restos del proceso

Más adelante pasaré a detallar un poco más cada uno de ellos, por el momento todavía falta definir como se van a almacenar las versiones en el servidor remoto.

La forma más fácil sería definir un archivo donde vamos a detallar la ruta relativa de cada componente dentro de la carpeta principal de nuestro programa y la versión online.

Por ejemplo:

EjecutablePrincipal.exe - Versión online: 2.0.0.1
una_carpeta\OtroArchivo.dll - Versión online: 2.0.0.2
otro path con espacio\Lala.dll - Versión online: 1.3.0.0

Como verán, ésta puede no ser la mejor forma de hacerlo, primero porque ¿que pasaría si la ruta de acceso contiene el caracter (guión medio)?: no podríamos separar fácilmente la versión de ella. ¿Lo ven?, entonces podríamos mejorar un poco esto. Pensemos en los caracteres inválidos para la ruta de acceso, así podemos tomar uno y tener la certeza de que no nos va a afectar al intentar separar ambas partes.

Como sabrán, o posiblemente no, el caracter : (dos puntos) no es válido para nombres de archivo, por lo tanto, no va a existir en una ruta relativa. ¡Cuidado acá!, si ustedes desean mejorar este programa y utilizar rutas absolutas, dicho caracter puede aparecer luego de la letra de la unidad.

Pueden ver una lista de caracteres no válidos al intentar renombrar un archivo agregándole :.

Caracteres no válidos

Caracteres no válidos

Como se puede apreciar, el caracter | también lo podríamos utilizar.

Bueno, no nos vayamos por las ramas que después nos va a salir a perseguir Tarzán … estábamos buscando una forma de mejorar la estructura inicial que propuse para el archivo de actualización.

¿Qué les parece el siguiente?

EjecutablePrincipal.exe        : 2.0.0.1
una_carpeta\OtroArchivo.dll    : 2.0.0.2
otro path con espacio\Lala.dll : 1.3.0.0

Como verán, ahora no solo es más fácil identificar los archivos y rutas, sino también comparar las versiones, e incluso terminamos con un texto más fácil de parsear. Se habrán dado cuenta que estoy usando texto simple por comodidad y para que les resulte fácil a los que recién empiezan, pero si lo desean, podrían extender esto para utilizar XML, JSON, o algún otro formato que sea de su agrado.

También es bueno notar que hay infinitas formas de darle un formato a este archivo, incluso podrían usar un separador compuesto de múltiples caracteres, pero recuerden prestar especial atención para no generar algún conflicto con los posibles nombres de archivos y rutas de acceso.

EjecutablePrincipal.exe        |:==:| 2.0.0.1
una_carpeta\OtroArchivo.dll    |:==:| 2.0.0.2
otro path con espacio\Lala.dll |:==:| 1.3.0.0

Se podrían estar preguntando por qué es necesario especificar la versión remota, si en definitiva se puede consultar una vez descargado el archivo mediante Reflection; bien, ahí radica el problema, primero deberemos descargar el o los archivos. Si nos detenemos un momento a pensar esto, puede ser que no todos nuestros usuarios cuenten con una conexión de banda ancha, con lo cual hacerle descargar todo el paquete que conforma la actualización y luego preguntarle si la quiere sonaría, cuando menos, ridículo. En el caso que no desee aceptarla, los habremos descargado inútilmente generando una carga innecesaria en nuestro servidor de actualizaciones y además, consumiendo recursos que podrían llegar a ser limitados o escasos.

Continúa en Actualizador (2da Parte)

Anuncios

1 comentario »

  1. […] : "http%3A%2F%2Fdatapayasadas.wordpress.com%2F2009%2F10%2F25%2Factualizador-2da-parte%2F" } En el artículo previo (Actualizador 1era Parte) llegamos a definir la estructura iba a tener nuestro archivo de actualizaciones, ahora solo nos […]

    Pingback por Actualizador (2da Parte) « Datapayasadas — octubre 25, 2009 @ 12:12 am


RSS feed for comments on this post. TrackBack URI

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Blog de WordPress.com.

A %d blogueros les gusta esto: