Introduzione alla strumentazione e all'analisi
Aggiornamento: novembre 2007
Il termine strumentazione si riferisce alla possibilità di monitorare o misurare il livello delle prestazioni di un prodotto e di diagnosticare gli errori. In programmazione significa la possibilità di un'applicazione di incorporare:
Analisi del codice: ricezione di messaggi informativi sull'esecuzione di un'applicazione in fase di esecuzione.
Debug: registrazione e correzione di errori di programmazione in un'applicazione ancora in fase di sviluppo. Per ulteriori informazioni, vedere Debug.
Contatori prestazioni: componenti che consentono di tenere traccia delle prestazioni dell'applicazione. Per ulteriori informazioni, vedere Introduzione al monitoraggio dei valori limite delle prestazioni.
Log eventi: componenti che consentono di ricevere e tenere traccia degli eventi principali nell'esecuzione dell'applicazione. Per ulteriori informazioni, vedere la classe EventLog.
Le classi Trace e Debug consentono di monitorare ed esaminare le prestazioni dell'applicazione sia durante lo sviluppo che dopo la distribuzione. È ad esempio possibile utilizzare la classe Trace per tenere traccia all'interno di un'applicazione distribuita di particolari tipi di azioni, ad esempio la creazione di nuove connessioni a database, man mano che si verificano, e monitorare quindi l'efficienza dell'applicazione.
Debug e analisi del codice
Nella fase di sviluppo è possibile utilizzare i metodi di output della classe Debug per visualizzare messaggi nella finestra di output dell'ambiente di sviluppo integrato (IDE) di Visual Studio. Esempio:
Trace.WriteLine("Hello World!")
Debug.WriteLine("Hello World!")
System.Diagnostics.Trace.WriteLine("Hello World!");
System.Diagnostics.Debug.WriteLine("Hello World!");
System.Diagnostics.Trace.WriteLine("Hello World!");
System.Diagnostics.Debug.WriteLine("Hello World!");
In ciascuno di questi esempi viene visualizzato "Hello World!" nella finestra di output quando l'applicazione viene eseguita nel debugger.
È così possibile eseguire il debug delle applicazioni e ottimizzarne le prestazioni in base al loro comportamento nell'ambiente di verifica. Il debug dell'applicazione può essere eseguito nella build di debug, attivando l'attributo condizionale Debug in modo da ricevere tutto l'output di debug. Quando l'applicazione è pronta per il rilascio, è possibile compilare la build di rilascio senza attivare l'attributo condizionale Debug, in modo che il compilatore non includa il codice di debug nell'eseguibile finale. Per ulteriori informazioni, vedere Procedura: compilare in modo condizionale con analisi e debug. Per ulteriori informazioni sulle diverse configurazioni di generazione per l'applicazione, vedere Compilazione in Visual Studio.
È possibile anche analizzare l'esecuzione del codice in un'applicazione installata, utilizzando metodi della classe Trace. Inserendo Opzioni di analisi nel codice, è possibile controllare se l'analisi avviene e quanto sia approfondita. In questo modo è possibile monitorare lo stato dell'applicazione in un ambiente di produzione, il che si rivela particolarmente importante in un'applicazione aziendale che utilizza più componenti che vengono eseguiti in diversi computer. È possibile controllare il modo in cui vengono utilizzate le opzioni dopo la distribuzione tramite il file di configurazione. Per ulteriori informazioni, vedere Procedura: configurare opzioni di analisi.
Quando si sviluppa un'applicazione per cui si intende utilizzare la funzionalità di analisi, in genere vengono inclusi nel codice dell'applicazione sia messaggi di analisi che di debug. Al momento della distribuzione dell'applicazione, è possibile compilare la build di rilascio senza attivare l'attributo condizionale Debug. È tuttavia possibile attivare l'attributo condizionale Trace, in modo che il compilatore includa il codice di analisi nell'eseguibile. Per ulteriori informazioni, vedere Procedura: compilare in modo condizionale con analisi e debug.
Fasi dell'analisi del codice
L'analisi del codice è costituita da tre fasi:
Strumentazione: si aggiunge codice di analisi all'applicazione.
Analisi: tramite il codice di analisi vengono scritte informazioni nella destinazione specificata.
Valutazione: vengono valutate le informazioni di analisi per identificare e comprendere i problemi dell'applicazione.
Durante lo sviluppo, in base all'impostazione predefinita tutti i metodi di output di analisi e debug scrivono informazioni nella finestra di output di Visual Studio. In un'applicazione distribuita, tramite i metodi vengono scritte informazioni di analisi nelle destinazioni specificate. Per ulteriori informazioni su come specificare una destinazione di output per analisi o debug, vedere Listener di analisi.
Strumentazione di analisi e applicazioni distribuite
Quando si crea un'applicazione distribuita può risultare difficoltoso procedere alla verifica dell'applicazione nella stessa modalità in cui verrà utilizzata. È molto raro disporre delle funzionalità per verificare tutte le possibili combinazioni di sistemi operativi o browser, comprese tutte le opzioni nelle lingue localizzate, o simulare l'elevato numero di utenti che accederanno contemporaneamente all'applicazione. Non è quindi possibile verificare la risposta di un'applicazione distribuita a volumi elevati, installazioni diverse e comportamenti legati al singolo utente finale. Molte parti delle applicazioni distribuite non dispongono inoltre di interfaccia utente con cui è possibile interagire direttamente o visualizzare l'attività di tali parti.
È tuttavia possibile rimediare a questa mancanza abilitando le applicazioni distribuite alla descrizione di eventi di interesse per gli amministratori di sistema, in particolare per quanto riguarda gli errori e i malfunzionamenti, eseguendo la strumentazione dell'applicazione, vale a dire inserendo istruzioni di analisi in punti strategici del codice. In tal modo, se si verifica qualche imprevisto in fase di esecuzione, ad esempio un tempo di risposta eccessivamente lento, sarà possibile determinare una causa plausibile.
Grazie alle istruzioni di analisi, è possibile evitare la difficile operazione di esaminare, modificare e ricompilare il codice sorgente originale e di riprodurre l'errore verificatosi in fase di esecuzione all'interno dell'ambiente di debug. È importante ricordare che la strumentazione di un'applicazione può essere utile non solo per visualizzare gli errori, ma anche per monitorare le prestazioni.
Posizionamento strategico delle istruzioni di analisi
È necessario prestare molta attenzione durante il posizionamento delle istruzioni di analisi da utilizzare in fase di esecuzione. Si deve considerare quali informazioni di analisi sono necessarie nell'applicazione distribuita, in modo da comprendere tutti gli scenari di analisi. Tuttavia, poiché le applicazioni che utilizzano l'analisi possono essere molto diverse, non esistono regole generali per il posizionamento strategico dell'analisi. Per ulteriori informazioni sul posizionamento di istruzioni di analisi, vedere Procedura: aggiungere istruzioni di analisi al codice dell'applicazione.
Output di analisi
L'output di analisi viene ricevuto da oggetti chiamati listener. Un listener è un oggetto che riceve l'output di analisi e lo scrive in una periferica di output, in genere una finestra, un log o un file di testo. Quando viene creato un listener di analisi, esso viene in genere aggiunto all'insieme Trace.Listeners, in modo che possa ricevere tutti gli output di analisi.
Le informazioni di analisi vengono sempre scritte almeno nella destinazione di output Trace predefinita, ovvero in DefaultTraceListener. Se per qualche ragione DefaultTraceListener è stato eliminato senza aggiungere altri listener all'insieme Listeners, non si riceveranno messaggi di analisi. Per ulteriori informazioni, vedere Listener di analisi.
I sei membri di debug e metodi di analisi tramite i quali vengono scritte informazioni di analisi sono elencati nella tabella che segue.
Metodo |
Output |
|---|---|
Assert |
Il testo specificato o, se non è stato specificato alcun testo, lo stack di chiamate. L'output viene scritto solo se la condizione specificata come argomento nell'istruzione Assert è false. |
Fail |
Il testo specificato o, se non è stato specificato alcun testo, lo stack di chiamate. |
Write |
Il testo specificato. |
WriteIf |
Il testo specificato, se la condizione specificata come argomento nell'istruzione WriteIf viene soddisfatta. |
WriteLine |
Il testo specificato e un ritorno a capo. |
WriteLineIf |
Il testo specificato e un ritorno a capo, se la condizione specificata come argomento nell'istruzione WriteLineIf viene soddisfatta. |
Tutti i listener nell'insieme Listeners ricevono i messaggi descritti nella tabella precedente, ma l'azione intrapresa può variare in base al tipo di listener che riceve il messaggio. DefaultTraceListener visualizza ad esempio una finestra di dialogo di asserzione quando riceve una notifica Fail o una notifica Assert di errore, mentre TextWriterTraceListener scrive semplicemente l'output nel proprio flusso.
È possibile produrre risultati personalizzati implementando listener creati appositamente. Un listener di analisi personalizzato può, ad esempio, visualizzare i messaggi in una finestra di messaggio o connettersi a un database per aggiungere messaggi a una tabella. Tutti i listener personalizzati devono supportare i sei metodi sopra indicati. Per ulteriori informazioni sulla creazione di listener definiti dallo sviluppatore, vedere TraceListener nei riferimenti a .NET Framework.
.gif "Nota di Visual Basic") Nota di Visual Basic: |
|---|
In Visual Basic 2005 i metodi Debug.Write, Debug.WriteIf, Debug.WriteLine e Debug.WriteLineIf hanno sostituito il metodo Debug.Print disponibile nelle precedenti versioni di Visual Basic. |
I metodi Write e WriteLine scrivono sempre il testo specificato. Assert, WriteIf e WriteLineIf richiedono un argomento Boolean che controlli se debbano scrivere o meno il testo specificato. Il testo specificato viene scritto solo se l'espressione è true, per WriteIf e WriteLineIf, o false, per Assert. Il metodo Fail scrive sempre il testo specificato. Per ulteriori informazioni, vedere Procedura: aggiungere istruzioni di analisi al codice dell'applicazione e gli argomenti di riferimento su .NET Framework.
Aspetti relativi alla protezione
Se non si disattivano le funzionalità di analisi e di debug prima della distribuzione di un'applicazione ASP.NET, potrebbero rimanere accessibili al suo interno informazioni in grado di consentirne la violazione da parte di programmi dannosi. Per ulteriori informazioni, vedere Procedura: compilare in modo condizionale con analisi e debug, Compilazione in Visual Studio e Procedura: configurare opzioni di analisi. Il debug è inoltre configurabile tramite Internet Information Services (IIS).
Vedere anche
Attività
Procedura: aggiungere istruzioni di analisi al codice dell'applicazione
Procedura: configurare opzioni di analisi