Molti hosting Windows ospitano applicazioni ASP.NET Core su IIS. La pubblicazione è semplice, ma quando l'app non parte gli errori sono poco parlanti. Ecco cosa abbiamo imparato in produzione.

Framework-dependent o self-contained?

• Framework-dependent: pacchetto piccolo, ma sul server deve essere installato il runtime giusto (Hosting Bundle).
• Self-contained: il runtime viaggia con l'applicazione. Pacchetto più grande, ma nessuna dipendenza dal server: ideale su hosting condivisi.

dotnet publish -c Release -r win-x64 --self-contained true -o ./publish

In-process

Con il modello in-process l'applicazione gira dentro il processo di IIS: è il più veloce. Il file web.config generato dalla pubblicazione indica al modulo ASP.NET Core quale eseguibile avviare.

Aggiornare senza file bloccati

Copiando un file app_offline.htm nella cartella del sito, il modulo arresta l'applicazione e mostra quella pagina: si sostituiscono le DLL e poi si rimuove il file. Prima di toglierlo, verifica che i file copiati siano completi.

Quando compare 500.30

L'errore 500.30 significa che l'applicazione è stata avviata ma è fallita durante l'avvio. Per capire dove:

1. Attiva i log stdout nel web.config (stdoutLogEnabled="true") in una cartella scrivibile.
2. Scrivi un log su file come prima istruzione di Program.cs: se non compare, il problema è prima del tuo codice.
3. Per i problemi di caricamento del runtime, la variabile d'ambiente COREHOST_TRACE produce una traccia dettagliata dell'host.

Una lezione sulle dipendenze

Rimuovere un pacchetto NuGet può cambiare la versione di librerie che arrivavano indirettamente da quel pacchetto, e quindi il binario prodotto. Prima di ogni rilascio confronta il file deps.json e i riferimenti della DLL con la versione in produzione, e se serve fissa esplicitamente le versioni delle dipendenze transitive nel progetto.