18 messaggi dal 06 settembre 2002
Ai miei clienti con budget limitato ho sempre proposto il servizio di hosting per la gestione del loro sito.

Con ASP.NET WebForms non ci sono stati mai problemi di aggiornamento: bastava sostituire la pagina.

Con ASP.NET Core credo che le cose siano invece cambiate.

L'aggiornamento di un'applicazione ASP.NET Core comporta la sostituzione della .dll dell'applicazione, operazione che puo' essere effettuata arrestando il sito.

Dato che con il servizio di hosting non e' possibile arrestare il sito, per le applicazioni ASP.NET Core devo necessariamente ricorrere al servizio di housing?

E' corretto questo ragionamento? Ci sono altre opzioni?

Grazie
salvo
11.097 messaggi dal 09 febbraio 2002
Contributi
Ciao,
è vero, non puoi sostituire le .dll "a caldo", cioè mentre l'applicazione è in esecuzione.
Se l'applicazione è ospitata in IIS, puoi arrestarla creando un file chiamato app_offline.html che si trova nella root del sito, cioè nella stessa directory in cui si trova anche il file web.config. A questo punto puoi sostituire le .dll e quando hai fatto puoi eliminare il file app_offline.hmtl.
https://blogs.msdn.microsoft.com/amb/2012/02/03/easiest-way-to-take-your-web-site-offline-iis-6-0-or-iis-7-5-with-net-4-0/

Un'altra tecnica consiste nel trasferire le .dll in una directory differente e poi modificare il percorso alla .dll principale nel file web.config. Nel momento in cui il file web.config viene salvato, IIS si accorge che qualcosa è cambiato e riavvia l'applicazione per il minimo downtime.

In questa issue GitHub c'è una discussione in merito di compilazione a runtime (anche chiamata dynamic compilation), che è la tecnica usata dai vecchi WebSite ASP.NET per ricompilare il sorgente delle pagine aspx nel momento in cui vengono aggiornate.
https://github.com/aspnet/Mvc/issues/6760

David Fowler del team di sviluppo dice che la dynamic compilation non verrà introdotta in ASP.NET Core.

There's no runtime compilation of .cs files.
...
We're not going to be adding runtime compilation for C# files.
...
There's no model for deploying "sources", this isn't like PHP or asp classic. Once you have .cs files, you need to do a full build to get a .dll. [...] C# is a compiled language


Comunque, non è un grosso problema. Per progetti a basso budget si può tollerare un disservizio di qualche secondo, tempo in cui l'applicazione deve essere fermata e riavviata dopo l'aggiornamento.
Per applicazioni mission-critical esistono altre tecniche di aggiornamento a zero downtime come i deployment slots di Azure. In pratica, l'applicazione viene aggiornata in uno slot differente definito di "staging" che ti dà l'opportunità di provare l'applicazione prima che venga messa in produzione. Questo passaggio è necessario per verificare che l'aggiornamento funzioni bene anche sul server, cosa non sempre scontata per via delle diversità con l'ambiente di sviluppo. Solo quando si è certi che l'applicazione funziona bene, allora si scambiano gli slot e quello che era lo slot di Staging diventa di Produzione (e viceversa).
Lo vedi in questo video:
http://media.aspitalia.com/events/aspilive-VS-online-continuous-deployment-Azure.media

ciao,
Moreno
Modificato da BrightSoul il 08 ottobre 2018 22.08 -

Enjoy learning and just keep making

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.