Ripubblicazione di un'applicazione Web ASP.NET mentre il sito è attivo

Question

Sto cercando di capire come gestire gli aggiornamenti a un'applicazione ASP.NET (2.0 o successiva) funzionante, mentre ci sono utenti sul sito.

Ad esempio, supponiamo che SO sia un progetto di applicazione Web ASP.NET. Il codice del progetto si compila fino alla singola .DLL nella cartella BIN. Ora, ci sono utenti costantemente su SO, quindi cosa succederebbe alle azioni/sessioni degli utenti se si usasse la funzionalità "Pubblica" di Visual Studio .NET (o semplicemente tutto di nuovo manualmente) mentre stanno usando il sito?

Creazione di un sito Web ASP.NET, invece, alleviare eventuali problemi che potrebbero o non potrebbero esistere con lo scenario sopra? Sto iniziando a sviluppare un sito Web come applicazione Web guidata dall'utente, e voglio essere sicuro che la mia inesperienza con questo non possa potenzialmente infastidire [potenzialmente] molti utenti che [desidero] avere 24/7.

EDIT: Scusa, avrei dovuto inserirlo in un contesto più preciso. Supponiamo che questo sito sia ospitato da un servizio di web hosting con canoni mensili. Non gestirò il server stesso, solo ciò che l'host Web consente come utente dei loro servizi.

Answer 1

La modifica al modello del sito Web asp.net non avrà alcun effetto, poiché il riciclo avverrà anche, alcune delle modifiche che lo attivano di sicuro: web.config, global.asax, app_code.

Dopo il riciclo, l'utente sarà ancora loggato perché asp.net convaliderà solo la sintassi. Questo ti viene dato quando usi una chiave fissa, altrimenti cambierà su ogni riciclo. Questa è una cosa che si vuole fare comunque, poiché altre cose possono interrompersi se la chiave cambia tra le richieste, vale a dire la convalida di viewstate, le risorse incorporate (la decrittografia dell'URL fallisce).

Se è possibile mettere fuori sessione la sessione, come in SQL Server, si eviterà di perdere la sessione. Se non puoi, il tuo codice dovrà considerarlo. Esistono molti scenari in cui è possibile evitare l'uso della sessione, mentre altri erano in grado di avvolgerlo e recuperare nuovamente le informazioni se la sessione è stata pulita. Questo dovrebbe lasciarti con una manciata di casi specifici che sai possono dare problemi agli utenti, quindi per quelli che fai alcuni dei suggerimenti che altri hanno già fatto.

Answer 2

Una soluzione potrebbe essere la distribuzione dell'applicazione in un ambiente con bilanciamento del carico (web farm).
Quando si distribuisce una nuova versione si utilizza il bilanciamento del carico per reindirizzare le richieste al server su cui non si sta distribuendo.

Answer 3

Non sono sicuro di come SO lo gestisce .. Ma di solito mettiamo una pagina di attesa. Quindi ciò che l'utente ha fatto (aggiungendo domande o risposte alle domande) non viene aggiornato. Non appena aggiorna qualcosa, vedrà una pagina di attesa che gli chiederà di provare dopo un po '.

E se sono l'utente, di solito preme il pulsante Indietro per assicurarmi che ciò che ho inserito venga salvato nella cronologia del browser in modo che possa postare più tardi.

Alcuni uso del sito sono in ambiente cluster, quindi prendo un server offline e informo il servizio di bilanciamento del carico che non sarà disponibile e una volta che mi assicurerò che la nuova versione funzioni correttamente, lo realizzerò dal vivo. stessa cosa per il prossimo server.

Abbiamo qualche altra opzione?

Answer 4

App_offline.htm è un'ottima soluzione per questo, penso.

in SO vediamo la pagina dell'applicazione attualmente non disponibile all'avvio di una distribuzione.

Answer 5

Creo due siti Web in IIS. Uno è il sito Web di produzione e l'altro è un sito Web statico con HttpHandler che invia tutte le richieste a una singola pagina statica "Stiamo aggiornando" fornita con un servizio HTTP 503 non disponibile. In genere, il sito Web di aggiornamento è disattivato. Quando è il momento di aggiornare, interrompiamo il sito Web di produzione, avviamo il sito Web di aggiornamento e ora possiamo occuparci del sito Web di produzione tutto ciò che vogliamo senza preoccuparci che le DLL vengano bloccate o che i processi dei lavoratori debbano essere sottoposti a rotazione.

ho iniziato a fare questo perché

• app_offline.htm in realtà non funziona bene in Web giardini, che usiamo.
• App_Offline.htm pubblica la sua pagina come 404, il che è un male se sei giù per un periodo di tempo significativo.
• Possiamo avviare il sito Web di produzione aggiornato con le impostazioni modificate (solo ascoltando su localhost), dove possiamo eseguire un'accettazione/verifica dell'ultimo minuto che tutto funzioni prima di attivare l'interruttore, disattivare il sito Web di aggiornamento e -attivando il sito Web di produzione.

cose questo non risolve includere

• Qualsiasi manutenzione che richiede il riavvio del server - Hai ancora tempo di inattività in cui viene servita nessuna pagina.
• Qualsiasi manutenzione che abbia problemi con il runtime .NET, come l'aggiornamento al service pack più recente.

Altri approcci che ho visto includono

• Avere due server. Invia tutte le richieste di bilanciamento del carico a un server, aggiorna l'altro; quindi risciacquare e ripetere. La maggior parte di noi non ha questo lusso.
• Creazione di più directory bin, come bin-1.0.0.0 e bin-1.1.0.0 e indicazione di ASP.NET quale directory bin da utilizzare nel file web.config. (Un vantaggio di questo è che il ripristino di un binario precedente è solo la modifica di un file di configurazione. Uno svantaggio è che è più difficile ripristinare le risorse che non finiscono nei binari, come i modelli e le immagini e così via.) Io non ricorda come ha funzionato davvero - penso che l'applicazione abbia fatto un po 'di late assembly assembly nel suo Global.asax basato sulla sua sezione web.config (dato che hai toccato il web.config, l'app era stata riavviata, quindi era okay).

Se trovi un modo migliore, fammi sapere!

Answer 6

Non è una soluzione tecnica, ma imposta una finestra di manutenzione programmata. È possibile anticipare in anticipo fornendo alla vostra base di utenti un equo avviso che esiste la possibilità che l'applicazione non sia disponibile durante quel periodo di tempo.