.net - net - Escribiendo mi propio Auto Updater

vb net update application

Question

Al escribir mi propio actualizador automático, ¿hay un marco general que debería seguir?

Hace un tiempo estaba leyendo sobre cómo se debe crear un "cargador de arranque" que se cargará primero antes que la aplicación principal (ya que una aplicación en ejecución no se puede actualizar debido a bloqueos de archivos, etc.)

¿Alguna sugerencia / mejores prácticas para esto?

Answer 1

ClickOnce no funcionó bien para nosotros. Instalamos la base de datos en el servidor de nuestro cliente. La base de datos en su extremo necesita ser actualizada antes de hacer una actualización. Tenemos mucho más que solo 2 o 3 clientes, por lo que hacer ClickOnce para nuestra aplicación no es realmente la mejor idea, a menos que me pierda algo importante sobre ClickOnce.

Lo que hice fue agregar un campo a la base de datos para el número de versión. En nuestro sitio ftp, tengo una carpeta de versiones que tiene una carpeta para cada número de versión de nuestra aplicación. Dentro de la carpeta de esa versión en particular, colocamos un archivo zip con setup.exe y el archivo msi que ejecutará setup.exe. Todos los prerrequisitos se descargan desde el sitio de los proveedores para garantizar que nuestro sitio FTP no reciba descargas enormes (.Net 3.5 cuando nos mudemos a él). Cuando se inicia nuestra aplicación, comprueba el campo en la base de datos para el número de versión y, si es diferente de la versión del ensamblaje de las versiones actuales, se conectará al sitio ftp, descargará el archivo zip de la carpeta de la nueva versión, lo descomprimirá y ejecutar la configuración. Esto instalará las versiones más nuevas de .Net o cualquier otro requisito que hayamos agregado, luego iniciará el MSI para instalar nuestra aplicación y todo lo que el usuario tiene que hacer es hacer clic en "Siguiente" algunas veces.

Answer 2

Codifiqué un actualizador para una aplicación en la que trabajé en C ++, pero la estructura general sería la misma.

1. La aplicación verifica una URL para ver el número de versión u otro cambio de identificador
2. La aplicación retira la nueva aplicación de actualización de la red
3. La aplicación ejecuta una nueva aplicación de actualización (que podría incluir código para cambios imprevistos en el proceso de actualización) y luego sale de la aplicación
4. El nuevo actualizador espera que la aplicación salga, luego descarga e instala nuevas "cosas", etc.

Esto funcionó bastante bien para nosotros, y como siempre descargó un nuevo "actualizador" como lo primero que hizo, pudimos manejar algunas cosas funky que, de lo contrario, no funcionarían.

Answer 3

Hace diez años escribí un actualizador automático (no en .NET), pero la esencia era que la aplicación tenía una identificación de versión que se comprobó al inicio. En este caso, la aplicación consultó una tabla de base de datos que tenía la versión actual y si la versión en ejecución era menor que la versión actual, se le solicitó al usuario descargar la última versión. Lo mismo podría lograrse al marcar una URL.

Answer 4

Hay un artículo sobre esto en CodeProject: "Actualización automática de la aplicación en VB.NET" en https://secure.codeproject.com/KB/vb/autoupdate.aspx y https://secure.codeproject.com/KB/vb/ Auto_Update_Revisited.aspx

Y otra buena aquí: actualización automática de aplicaciones personalizadas ": https://secure.codeproject.com/KB/vb/CustomAppAutoUpdate.aspx

Answer 5

Lamentablemente, no hay Sparkle o motor de actualización para .NET. Existe el Bloque de la aplicación de actualización para .NET lanzado por Microsoft, esa es su mejor opción si no quiere rodar completamente su propia solución (aún hay un montón de código que necesitará para escribir).

Answer 6

Probablemente tendrás que escribir el tuyo. Como mencionó FOR, la idea básica es poner la última versión de tu programa (supongo que un EXE) en el servidor, y luego hacer que tu aplicación verifique con el servidor cuando se inicie, y descargar el EXE del servidor si es una versión más nueva.

Usualmente lo implementé como un servicio web que la aplicación llama al inicio. Un par de advertencias sobre este enfoque:

1. El método de servicio web necesita obtener el número de versión del EXE en el servidor y compararlo con el número de versión de la persona que llama. Si usa la clase Assembly para leer el número de versión del servidor EXE, esto bloqueará el archivo mientras se esté ejecutando la instancia del servicio web (al menos 20 minutos). Como resultado, a veces puede tener problemas para reemplazar EXE en el servidor con una versión más nueva. Utilice la clase AssemblyName en su lugar: esto le permite leer la información del conjunto sin cargar el conjunto (y bloquearlo).

2. La aplicación de llamada no puede reemplazar su propio archivo con la nueva versión; no puede eliminar o actualizar un archivo de aplicación en ejecución. Lo que sí puede hacer, sin embargo, es cambiar el nombre de su propio archivo mientras se ejecuta. Entonces, el truco de una actualización automática es que la aplicación cambie su nombre (por ejemplo, "MyApplication.exe" a "MyApplication_OLD.exe"), descargue la nueva versión en la carpeta de la aplicación (llamada "MyApplication.exe"), notifique al usuario que se ha producido una actualización que requiere un reinicio de la aplicación y luego finaliza. Cuando el usuario reinicia la aplicación, se iniciará la versión más nueva: esta versión verifica y elimina la versión anterior.

Hacer una actualización automática que reinicie automáticamente la aplicación después de una actualización como esta es muy complicada (implica iniciar otro proceso y luego finalizar su propio proceso antes de que comience el proceso de reinicio automático). Nunca he tenido un usuario que se queja de tener que reiniciar la aplicación.

Answer 7

Si usa .Net, ¿por qué no utiliza ClickOnce? Hará todo lo que está hablando de la caja y requiere una configuración casi nula.

Answer 8

Este archivo comprimido contiene el código fuente de una herramienta del generador de búsqueda de palabras que incluye el código repetitivo de AppUpdater.
http://cid-842434ebe9688900.skydrive.live.com/self.aspx/Games/WordSearchGenerator-src-v1.3.zip

Busque los 3 módulos fuente que tienen "AppUpdater" en el nombre.

Es muy simplista y funciona solo para aplicaciones de ensamblaje único. No hay archivo MSI. Solo un EXE. La filosofía es que las comprobaciones de actualizaciones se realizan automáticamente, pero las actualizaciones se instalan solo después de la confirmación del usuario.

La forma en que funciona el actualizador:

Carga un documento XML desde una URL que contiene la información de "última versión", así como una segunda URL donde se encuentra la nueva versión. La lógica de actualización verifica la firma en el documento XML, pero es posible que eso no le importe. El actualizador compara la versión actual con la última versión y puede indicarle a la aplicación si hay una actualización disponible. El actualizador también maneja el problema de reemplazo en el lugar.

En este modelo, hay tres "etapas del ciclo de vida" de una aplicación durante una actualización. En el curso normal, la aplicación busca actualizaciones y luego se ejecuta normalmente. En algún momento, el usuario puede confirmar que desea instalar la actualización disponible, y Updater descarga la aplicación a una ubicación temporal y luego inicia un proceso utilizando el ejecutable recién descargado. La lógica de actualización luego sale del primer proceso. El segundo proceso, basado en los argumentos de línea de comandos que le dio el primer proceso, se da cuenta de que es una copia recién descargada y necesita replicarse. Se copia en la ubicación original (especificada en la línea de comandos), inicia ese exe y sale. El tercer proceso comienza normalmente, ve que ha habido una actualización y elimina la copia del exe de la función. A continuación, se ejecuta de forma normal, incluida la comprobación de actualizaciones. Descubrirá que no hay actualizaciones, y que luego se ejecutará normalmente. Eso cubre el funcionamiento de la lógica de actualización en el lugar.

Esto es manejado por estas líneas en el constructor de Windows Form o WPF Window:

  _Updater = new AppUpdater.SimpleAppUpdater(_MyManifestUrl);
  _Updater.Startup(App.CommandLineArgs);

El problema de comprobación de actualización también se maneja con unas pocas líneas de código en el constructor, que crean y ejecutan un hilo de trabajador de fondo:

  _Worker = new System.ComponentModel.BackgroundWorker();
  _Worker.DoWork += CheckLatest;
  _Worker.RunWorkerCompleted += CheckCompleted;
  _Worker.RunWorkerAsync();

El CheckLatest es esto:

    void CheckLatest(object sender, System.ComponentModel.DoWorkEventArgs e)
    {
        lock (_Updater)
        {
            if (_Updater.UpdateIsAvailable) // Checks for update
            {
                // can update a textbox (etc) here.  Be careful of InvokeRequired.
            }
        }
    }

El evento completo es este:

void CheckCompleted(object sender, System.ComponentModel.RunWorkerCompletedEventArgs e)
{
    if (!e.Cancelled && e.Error == null)
    {
        lock (_Updater)
        {
            // only display the about box if there is an update available.
            if (_Updater.HaveCheckedForUpdate && _Updater.UpdateIsAvailable)
            {
                // do whatever you want here.  Eg, pop a dialog saying 
                // "an update is available"
                About about = new About();
                about.Message= "An update is available";
                about.ShowDialog();
            }
        }
    }
}

Funciona desde aplicaciones WinForms o WPF. Supongo que funcionaría también desde las aplicaciones de la consola, pero nunca lo intenté.

Crear el archivo de manifiesto (posiblemente firmado) es una tarea separada, que no se trata aquí.

Pensando en ello, esto podría ser mejor empaquetado como una clase base AutoUpdatingForm (para WinForms) o AutoUpdatingWindow (para WPF). Pero nunca di ese paso.

Answer 9

Escribió nuestro propio software de actualización automática. Así que este es mi consejo ... ¡No lo hagas! Por supuesto, todo esto depende de su situación específica, pero aquí están los problemas que mi empresa encontró:

• Difícil de mantener de forma continua, especialmente si dirige Win2k a Windows 7.
• Retos con permisos. WinVista / 7 UAC puede ser un verdadero dolor.
• La flexibilidad es un requisito, pero no podrá prever todos los problemas. Por ejemplo, iniciar / detener servicios, iniciar archivos, etc. son todas tareas que PUEDE hacer para sus actualizaciones automáticas, pero que no necesariamente prevé.

El problema con nuestro software es que necesitábamos mucha flexibilidad y soporte en todas las plataformas de Windows. La solución que escribimos funcionaba bien, pero no escalaba y comenzaba a fallar cuando las versiones de Windows cambiaban o no eran exactamente como las de nuestro laboratorio. Finalmente compramos software y te recomiendo que hagas lo mismo. Si está interesado, compramos un producto llamado AutoUpdate + ( texto del enlace ).

Answer 10

Aquí hay una solución de código abierto que escribí para abordar las necesidades específicas que teníamos para las aplicaciones WinForms y WPF. La idea general es tener la mayor flexibilidad, a la menor sobrecarga posible.

Por lo tanto, la integración es súper fácil, y la biblioteca hace prácticamente todo por usted, incluidas las operaciones de sincronización. También es muy flexible y le permite determinar qué tareas ejecutar y en qué condiciones: usted crea las reglas (o usa algunas que ya existen). Por último, no menos importante es el soporte para cualquier fuente de actualizaciones (web, BitTorrent, etc.) y cualquier formato de alimentación ; lo que no esté implementado, puede simplemente escribirlo usted mismo.

Las actualizaciones en frío (que requieren el reinicio de una aplicación) también se admiten y se realizan automáticamente a menos que se especifique "intercambio en caliente" para la tarea.

Esto se reduce a una DLL, menos de 70kb de tamaño.

Más detalles en http://www.code972.com/blog/2010/08/nappupdate-application-auto-update-framework-for-dotnet/

El código está en http://github.com/synhershko/NAppUpdate (Licencia bajo la licencia de Apache 2.0)

Planeo extenderlo más cuando tenga más tiempo, pero sinceramente, debes ser capaz de mejorarlo rápidamente por lo que actualmente no es compatible.

Answer 11

Una de las soluciones que aún tengo que probar es tener un instalador que pueda ejecutarse en modo silencioso.

La aplicación llama al servidor y, si necesita actualizarse, descarga el último instalador y luego lo ejecuta con un indicador silencioso o de actualización.

Tiene muchos beneficios:

• flexibilidad: puede hacer cualquier cosa que haría para una instalación normal
• sin paquete adicional: el instalador y la actualización son la misma cosa
• si desinstala y luego reinstala, puede manejar reversiones
• la actualización es un proceso separado, por lo que puede iniciar la aplicación cuando se complete la instalación
• tienes herramientas para manejar vista UAC

Answer 12

Ok, antes que nada, si alguno de los productos de instalador / actualizador en el mercado se ajusta a su necesidad, probablemente debería usarlos. Dicho esto, he tenido el placer de construir un sistema como este yo no hace mucho tiempo. Sí, nuestro instalador / actualizador incluyó dos partes en el lado del cliente para que:

~ La Parte A se conectaría a los servidores donde se almacena y publica la última versión; si una versión más nueva de la Parte B estuviera disponible, se descargaría y se lanzaría

~ La Parte B se enfocaría en la instalación / actualización de la aplicación real (y podría descargar e instalar actualizaciones en la Parte A).

Aparte de eso, recomendaría siempre considerar las siguientes 4 operaciones en el instalador / actualizador:

• Instalar y Desinstalar

• Actualización y reversión (es decir, deshacer la última actualización)

El Rollback One es crítico cuando sus usuarios tienen un sistema que se actualiza automáticamente de la noche a la mañana. Si una actualización falla, pueden deshacerse y seguir trabajando mientras usted resuelve el problema.

Finalmente, el instalador / actualizador debe probar y ser independiente de la aplicación que instala / actualiza, de modo que, cuando esa aplicación cambie, el sistema instalador / actualizador se vea afectado la menor cantidad posible.