ASP.NET mette a disposizione degli sviluppatori, finalmente, un sistema di debugging e tracing davvero efficiente.
Fino ad oggi, uno sviluppatore ASP è stato costretto ad utilizzare miriade di
response.write
Con questo articolo vedremo come ASP.NET ci venga incontro da questo punto di vista, permettendoci di utilizzare strumenti avanzati e soprattutto sicuri.
Il tracing
Partiamo dal tracing degli errori, letteralmente "tracciato". Ci sono due metodi per abilitarlo:
- a livello di dominio (dove per dominio si intende quello che con le classic ASP è l' applicazione )
- a livello di singola pagina
Come vedremo, la soluzione più pratica per gestire il tracing a livello locale consiste nell'utilizzare la prima opzione, mentre la seconda si rivela utile per verificare in maniera rapida, ad esempio su un server di produzione, che tutto stia funzionando per il meglio.
Per abilitare il tracing a livello di dominio ASP.NET, basta utilizzare nella sezione system.web del file web.config questa istruzione:
<trace enabled="true" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" />
Nota: tutto quello che scrivete nel web.config è CAse SeNtiVE . Ciò significa che dovete utilizzare esattamente lo stesso modo di scrivere di maiuscole e minusole, pena un funzionamento non corretto delle vostre istruzioni.
La proprietà enabled, indica se il tracing è attivo, requestLimit invece il numero di richieste da mostrare (10 nel nostro esempio), pageOutput ci consente di specificare se l'output deve essere visualizzato alla fine di ogni pagina, oppure, come abbiamo scelto, in un file separato, traceMode indica la tipologia di ordinamento (qui abbiamo scelto per ordine di richiesta) e localOnly ci permette di impostare il tracing come attivo solo se visualizzato da un browser appartenente alla rete locale.
Con una istruzione del genere, potremo raggiungere comodamente il tracing all'indirizzo http://localhost/trace.axd dove localhost è il nome della nostra macchina o l'indirizzo web del nostro sito.
Appare subito chiaro che lasciare attivo il tracing su un server di produzione può risultare abbastanza controproducente...
Viceversa, il tracing a livello di singola pagina, ci permetterà di visualizzare il contenuto direttamente a seguito dell'output classico.
Oltre che dal web.config, è possibile attivare questa opzione aggiungendo alla direttiva
<%@Page %>
<%@Page Language="VB" Trace="true"%>
Trace.write
Per inserire un'informazione nel tracing, bisognerà utilizzare questa istruzione:
trace.write (nomesezione, valore)
Il primo parametro, nomesezione, è opzionale, ma il suo utilizzo permette di avere un output più chiaro. In linea di massima, queste due istruzioni hanno lo stesso effetto, come si può notare dalla seguente figura:
trace.write ("Stringa di connessione", strConn) trace.write (strConn)
Dunque, siamo di fronte ad un sistema di tracing molto potente e di facile utilizzo.
Come avrete sicuramente notato, il tracing contiene tutta una serie di informazioni sulla richiesta, come headers, cookies, server variables, controlli della pagina e tempo di esecuzione, che possono rivelarsi davvero utili in fase di debugging del codice.
Il grosso vantaggio di utilizzare trace.write anzichè response.write è che una volta disabilitato il tracing, queste istruzioni vengono letteralmente ignorate e dunque non si corre il rischio di mandare in output qualcosa che in realtà sarebbe dovuto restare privato.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.