Application Release/Upgrade Strategy per Silverlight Business Application?

Question

Sono interessante nel sentire se altri hanno affrontato la gestione del rilascio per le applicazioni Silverlight.

Ho un'applicazione aziendale che verrà rilasciata a breve e preoccupata di come "rilasciare" gli aggiornamenti a questa applicazione. In genere gli utenti di questa applicazione lasceranno l'applicazione aperta tutto il giorno (e potenzialmente tutta la notte) senza ricaricarla.

Cosa succede se è necessario rilasciare una modifica che include una modifica dell'interfaccia del servizio Web? Come può essere implementato senza causare errori sul lato client?

Siamo cresciuti così abituati a distribuire le app ASP.Net semplicemente lasciando cadere l'ultimo codice sul server. La mia unica idea al momento riguarda un numero di versione del client e un timer periodico per verificare la presenza di aggiornamenti.

Mi piacerebbe sapere cosa hanno fatto gli altri prima di implementare questo.

Grazie, Mike

Answer 1

ho solo risposto a una domanda su come fare in modo che i file Xap non vengono memorizzati nella cache dal browser, che potrebbe essere di qualche aiuto:
Prevent Silverlight xap from being cached by proxy server

Ma non è utilizzare se gli utenti mai ricaricare l'applicazione. Nella mia applicazione questo non è un problema poiché gli utenti verranno automaticamente espulsi ogni volta che distribuiamo un aggiornamento al servizio web. Ma mi piace la tua idea con il timer, vorrei andare con quello.

Answer 2

Dichiarare l'ovvio ma non fare nulla per infastidire gli utenti. Per esempio. potrebbero passare venti minuti a inserire dati, passare alla macchina da caffè e tornare a fare clic su Invia per trovare il timer scaduto, notato un aggiornamento e il loro lavoro è andato perso a causa di un riavvio forzato?

Se è così, e ammetto che questo non ha avuto molto pensiero, se ad es. è necessario apportare modifiche al servizio Web che interrompe la versione corrente, si potrebbe avere la nuova versione del servizio Web affiancata in modo tale che gli utenti non vengano espulsi fino a quando il timer non è scaduto e l'unità di lavoro è completa? O questo sta anche affermando l'ovvio?

Answer 3

Per il codice server, vale a dire che i punti finali funzionano come per la norma. per il xap credo che tu abbia poche opzioni a seconda di come gestisci le comunicazioni. È possibile che la richiesta contenga un numero di versione e, se il server è stato aggiornato, imporre un codice per ricaricare il client, bit lame, disordinato ma in grado di farlo. Forse una soluzione più pulita sarebbe quella di controllare la sessione dei clienti, che presumibilmente è parte integrante delle richieste al backedn. Quando si distribuisce una nuova versione, è possibile invalidare la sessione client, magari forzando l'aggiornamento di una pagina con logica personalizzata. Se il tuo protocollo è push base puoi inviare un comando al client per fare ciò che vuoi, per molti sistemi che sono attivi tutto il giorno è probabile che questa infrastruttura esisterebbe (se l'hai costruita bene :)). Ad esempio il nostro livello di servizio è astratto rispetto ai modelli di repository e ai modelli di visualizzazione, nel nostro caso potremmo inviare un logout o forse un comando specifico per dare il via ad alcune logiche personalizzate sul client informando che l'applicazione è in aggiornamento e per aggiornare il tuo browser quando fatto. La nostra shell è leggera, quindi i nostri moduli (in pratica altri xap) possono essere aggiornati in tempo per l'aggiornamento.

Answer 4

ti consiglierei di utilizzare una soluzione come indicato nella Guida App Arch:

The Guide Chapter I mean vedere Considerazioni sulla distribuzione.

• dividere la domanda in logiche moduli che possono essere memorizzati nella cache separatamente, e che possono essere sostituiti facilmente senza richiedere nuovamente l'utente al scaricare l'intera applicazione .
• Versione dei componenti.

Answer 5

Avete considerato di mantenere un canale WCF polling duplex che invia l'avviso all'app quando è necessario ricaricare? Inoltre, è possibile indirizzare le proprie chiamate WCF a una directory virtuale che contiene chiamate "interfacciate". Per esempio:

Silverlight app ospitata presso "xxxx \ Default.aspx" parla Silverlight per WCF in "xxxx \ Version2 \ DataPortal.svc" DataPortal.svc parla di un GAC (o altrimenti di base) di assemblaggio in grado di identificare quale versione può gestire le chiamate.

In questo modo, se si esegue l'aggiornamento a "x.x.x.x \ Versione3 \ DataPortal.svc", è ancora possibile effettuare chiamate contro Version2, supponendo che tali chiamate abbiano codice per convertirle in un concetto Version3.

Questo aiuta nei casi in cui l'app della linea di business ha download xap dinamici ('principale', 'cliente', 'inventario', ecc.) E si desidera rilasciarli in modo indipendente.