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 -