Estrategia de lanzamiento/actualización de aplicaciones para la aplicación empresarial Silverlight?

Question

Me resulta interesante escuchar si otros han abordado la gestión de versiones para las aplicaciones de Silverlight.

Tengo una aplicación de negocios que se lanzará en breve y se preocupa por cómo "lanzar" las actualizaciones de esta aplicación. Normalmente, los usuarios de esta aplicación dejarán la aplicación abierta todo el día (y posiblemente toda la noche) sin tener que volver a cargarla.

¿Qué ocurre si es necesario liberar un cambio que incluye un cambio en la interfaz del servicio web? ¿Cómo se puede implementar esto sin causar errores en el lado del cliente?

Nos hemos acostumbrado a implementar aplicaciones ASP.Net simplemente colocando el código más reciente en el servidor. Mi única idea actualmente implica un número de versión de cliente y un temporizador periódico para verificar las actualizaciones.

Me encantaría saber qué han hecho otros antes de implementar esto.

Gracias, Mike

Answer 1

yo sólo respondió a una pregunta sobre cómo asegurarse de que los archivos .xap no se almacenan en caché por el navegador, lo que podría ser de alguna ayuda:
Prevent Silverlight xap from being cached by proxy server

Pero eso no es use si los usuarios nunca vuelven a cargar su aplicación. En mi propia aplicación, esto no es un problema ya que los usuarios se descartarán automáticamente cada vez que implementemos una actualización del servicio web. Pero me gusta tu idea con el temporizador, yo iría con eso.

Answer 2

Indicando lo obvio, pero no hagas nada para molestar a tus usuarios. P.ej. ¿podrían pasar veinte minutos ingresando datos, desconectarse de la máquina de café y volver a hacer clic en Enviar para encontrar que el temporizador ha expirado, notado una actualización y su trabajo se pierde debido a un reinicio forzado?

Si es así, y admito que esto no ha tenido mucho en cuenta, si, por ejemplo, tiene que hacer cambios en el servicio web que rompe la versión actual, ¿podría tener la nueva versión del servicio web una al lado de la otra para que los usuarios no sean expulsados ​​hasta que el temporizador haya expirado y la unidad de trabajo esté completa? ¿O esto también indica lo obvio?

Answer 3

Para el código del servidor, es decir, los puntos finales solo hacen lo normal. para los xap's creo que tiene algunas opciones dependiendo de cómo maneje las comunicaciones. Puede haber pedido que contenga un número de versión y si el servidor se ha actualizado, entonces fuerce un poco de código para volver a cargar el cliente, poco cojo, desordenado pero factible. Tal vez una solución más limpia sería controlar la sesión de los clientes, que presumiblemente es parte de las solicitudes al respaldado. Cuando implementa una nueva versión, puede invalidar la sesión del cliente, quizás forzando una actualización de página con lógica personalizada. Si su protocolo es base de inserción, puede enviar un comando al cliente para hacer lo que quiera, para muchos sistemas que están en todo el día es probable que exista esta infraestructura (si la ha construido muy bien :)). Por ejemplo, nuestra capa de servicios se abstrae de los modelos de repositorios y modelos de visualización, en nuestro caso podríamos enviar un cierre de sesión o quizás un comando específico para activar una lógica personalizada en el cliente informando que la aplicación se está actualizando y actualizar su navegador cuando haya terminado Nuestro caparazón es ligero, por lo que nuestros módulos (básicamente otros xap) se pueden actualizar a tiempo para la actualización.

Answer 4

yo le recomendaría utilizar una solución como se ha mencionado en la Guía de aplicaciones Arco:

The Guide Chapter I mean ver Consideraciones de implementación.

• dividir la solicitud en módulos lógicos que se pueden almacenar en caché separado, y que pueden ser reemplazados fácilmente sin requerir que el usuario descarga toda la aplicación de nuevo.
• Versión de sus componentes.

Answer 5

¿Ha considerado mantener en funcionamiento un canal WCF polling duplex que alerta a la aplicación cuando necesita volver a cargar? Además, puede hacer que sus llamadas WCF se dirijan a un directorio virtual que contenga llamadas 'conectadas'. Por ejemplo:

aplicación Silverlight alojado en "xxxx \ Default.aspx" conversaciones Silverlight para WCF en "xxxx \ Version2 \ DataPortal.svc" DataPortal.svc habla con un GAC (o de lo contrario base) de montaje que puede identificar qué versión puede manejar qué llamadas.

De esta forma, si actualiza a "x.x.x.x \ Version3 \ DataPortal.svc", puede seguir realizando llamadas contra Version2, suponiendo que esas llamadas tengan código para convertirlas a un concepto de Versión3.

Esto ayuda en los casos en que la aplicación de su línea de negocio tiene descargas dinámicas xap ('principal', 'cliente', 'inventario', etc.) y desea liberarlos de forma independiente.