2013-03-28 8 views
11

Recentemente ho avuto un'intervista per una posizione .NET. Per quanto riguarda le domande poste, ho avuto dei grossi problemi nel rispondere a una domanda. Spero che qualcuno possa aiutarmi in questo.Applicare l'aggiornamento senza riavviare l'applicazione

Scenario (domanda): La prima versione di un'applicazione (che potrebbe essere l'applicazione UI winform/wpf) è già disponibile per il client e hanno iniziato a utilizzare l'applicazione. Sfortunatamente, il team di controllo qualità ha in seguito trovato un problema serio nella versione corrente. Ora la sfida è che dovremmo essere in grado di inviare e applicare la patch (correzione) senza forzare il riavvio dell'applicazione. L'assunto è che l'applicazione è un'applicazione in tempo reale che non può essere riavviata per applicare le patch.

Personalmente, ho avuto problemi a dare una risposta convincente che non influisce sull'applicazione in esecuzione mentre viene applicata la patch.

Risposta:

Grazie per aver contribuito finora. Sono riuscito a ottenere una soluzione per questo problema. Non sono sicuro se questo è ciò che l'intervistatore ha chiesto. Tuttavia, mi ha fatto piacere leggere su ClickOnce di microsoft, che fa quasi quello che volevo ..

+0

Quale parte del programma si applica la correzione? Solo l'interfaccia utente? Immagino che potresti usare qualcosa come MEF per scaricare e ricaricare il codice aggiornato. – eandersson

+0

Questa domanda potrebbe essere interpretata come consentire l'aggiornamento (es. Sovrascrivere i file) senza forzare una chiusura ma l'app non deve riflettere le modifiche fino a quando non viene chiusa e chiusa facoltativamente, il che è molto più semplice nella maggior parte dei casi dell'applicazione un percorso per un programma in esecuzione che dovrebbe essere visto immediatamente senza rieseguire il programma. –

+0

@eandersson: la posizione non era esplicita. Tuttavia, come ci si accosterà se si tratta di una correzione dell'interfaccia utente o di una correzione in una DLL che è già nello spazio virtuale del processo? – sophieJ

risposta

-1

Rinominare il vecchio file in qualcos'altro (come aggiungere "Vecchio" al nome file), e copiare nel nuovo eseguibile al suo posto, stesso nome di file. La prossima volta che verrà eseguito, il nuovo eseguibile verrà eseguito.

+0

Non è possibile rinominare qualcosa in uso. Funzionerebbe solo per i file di dati che vengono letti solo una volta durante il caricamento. – JeremyK

+0

@JeremyK Dipende da _how_ viene utilizzato, come si fa notare con i file di dati. Un eseguibile può spesso essere sovrascritto bene anche quando è in esecuzione. –

+0

Non sta rinominando alcun file. piuttosto, implementando una correzione in dll che è già stata caricata nello spazio processo/virtuale. Pensa a uno scenario in cui gli operatori commerciali utilizzano questa applicazione per acquisire il feed di mercato in cui il ritardo non è conveniente. Questo è solo un esempio arbitrario per l'utilizzo dell'applicazione. – sophieJ

0

Innanzitutto, è necessario sapere se questa app si basa su file di configurazione come xml, ini o qualsiasi tipo di file di testo. In tal caso, è possibile inserire la patch come configurazione fintanto che sono modificabili al di fuori del campo del processo corrente.

Se la prima soluzione non è valida, la seconda soluzione per scoprire se l'applicazione in esecuzione ha una dll affidabile e se iniettare una patch come dipendenza tramite la dll di riferimento risolverebbe temporaneamente il problema fino a quando non viene richiamato un riavvio.

+0

Come si "iniettare una patch" in fase di esecuzione? E come inseriresti una patch in un file di configurazione? –

+0

non è possibile modificare il file binario già avviato, l'unico modo in cui il comportamento previsto può essere modificato analizzando i parametri purché l'applicazione in esecuzione disponga di un'API pubblica capace, che estrae i parametri dall'esterno per modificarne il comportamento. È come usare uno script python per cambiare il comportamento su un'applicazione in esecuzione. – Jegan

+0

Non necessariamente vero; non è possibile modificare l'applicazione stessa, ma * è possibile * modificare le funzionalità di un'applicazione in esecuzione. La configurazione basata su testo non è l'unico modo. –

2

Per l'eseguibile attualmente in esecuzione, si è praticamente bloccati - non è possibile modificare sensibilmente il processo in esecuzione in memoria.

Tuttavia, le cose caricate dalle DLL sono molto più flessibili. Gli assembly possono essere caricati dinamicamente in fase di runtime ed è possibile creare più AppDomain all'interno di una singola applicazione. Una soluzione potrebbe essere qualcosa in queste righe:

  • vostro eseguibile è un wrapper sottile che passa tutte le funzionalità attraverso una DLL
  • la funzionalità DLL viene caricato ed eseguito attraverso un dominio di applicazione separata
  • quando una patch è richiesto, la nuova DLL viene copiata (affianco a quella esistente)
  • automaticamente o in risposta all'interazione dell'utente, un nuovo AppDomain viene avviato insieme a quello esistente, eseguendo la nuova patch
  • a un punto adatto nell'app (ad esempio, una schermata intera sw prurito o un aggiornamento a tempo), il nuovo AppDomain diventa il "live" un
  • il vecchio dominio di applicazione si spegne e scartato

Tuttavia, questo è molto di alto livello. In una situazione realistica è probabile che tu abbia un'app multi-tier con cache e dati live e molte altre considerazioni. Potrebbe essere necessario, ad esempio, separare la logica front-end dell'applicazione dalla cache o dalla parte di gestione dei dati, in modo che ogni singolo pezzo possa essere disattivato senza disturbare il resto.

Alcune tecniche poco comuni sono probabilmente utili qui, a seconda del requisito esatto. Il caching avanzato potrebbe consentire lo scambio del livello dati senza che il front-end perdesse la possibilità di visualizzare i dati. L'accodamento di comandi o meccanismi di messaggistica affidabili potrebbero consentire all'interfaccia utente di rimanere reattiva mentre il livello aziendale viene scambiato e il nuovo livello aziendale può quindi elaborare la coda. Se si presuppone un'app basata sul server (logicamente), la ridondanza su ciascun livello potrebbe consentire di aggiornare un "server" ridondante di un livello mentre l'altro server continua l'elaborazione ... ecc.

1

Se si dispone di questo requisito dall'inizio, puoi separare la tua app in due applicazioni distinte: l'interfaccia utente e un servizio che svolge tutto il lavoro nelle singole chiamate di funzioni atomiche. Molto probabilmente, il tuo bug è nel servizio, quindi saresti in grado di sostituire quell'applicazione in qualsiasi momento senza interrompere l'esperienza dell'utente.