Spesso (troppo) vedo un gran numero di progetti web che finiscono in produzione senza le dovute precauzioni.
La cosa peggiore che si può fare è, quasi certamente, dimenticarsi di cambiare l’attributo “debug” nel web.config quando si pubblica. Vedere
<compilation debug=”true”>
..
</compilation>
nei web.config dei server di produzione dei miei clienti ormai mi da istinti omicidi :)
Molti non lo fanno per pigrizia o perchè “così se c’è un errore, ho informazioni più dettagliate”. Questo approccio è _assolutamente sbagliato_: una forte politica di logging mette al sicuro dagli errori sconosciuti e, se proprio è necessario, si riabilita il debug ma solo per il tempo necessario ad ottenere le dovute informazioni.
Questo perchè, anche se purtroppo molti lo ignorano, tenere il debug abilitato ha un sacco di effetti deleteri, tra cui:
- I file creati nella directory temporanea di ASP.NET sono molti di più in debug che in release, quindi il framework deve gestire piu accessi al file system;
- La batch compilation non funziona. Quindi, invece di compilare tutte le pagine in una cartella, ASP.NET compila file per file... finchè qualcuno non "vede" la pagina questa non viene compilata!
- Le pagine non hanno timeout applicativo. Moooolto pericoloso se ci sono errori di qualsiasi genere che possono inchiodare le richieste (contando che ASP.NET ha richieste limitate, se 10 utenti chiedono una pagina che va in attesa di qualcosa, non viene tirato giù il processo e il server diventa autistico....)
Direi che già questi sono un ottimo motivo per levare quell’inutile direttiva :)