Nelle “puntate” precedenti si è conclusa una prima parte in cui si è finalmente realizzata una continuos integration di un progetto consistente nella compilazione con autogenerazione di numero di versione, pubblicazione dell’ultimo compilato e archiviazione delle build. Il passo successivo è iniziare ad utilizzare tool di analisi del codice che siano in grado di darci delle metriche del nostro progetto. Una discussione sulle metriche del codice esula dallo scopo di questo tutorial per cui si vedrà l’aspetto prettamente pratico.
La prima metrica che si vuole avere è quella data da FxCop, un tool in grado di analizzare il codice compilato per verificare che sia conforme a tutta una serie di guidelines microsoft che riguardano il codice .NET. Il risultato di questa analisi non trova dei bug, ma indica con diversi livelli di gravità alcune caratteristiche non standard del nostro codice. La prima cosa da sapere è che CC.NET è in grado di analizzare l’output di alcuni tool base, tra cui FxCop, l’unica cosa da fare è indicare nel file di configurazione ccnet.config i file di log che debbono essere esaminati.
<publishers>
<merge>
<files>
<file>F:\Dati\Tutorials\Tutorials\CCNET\projects\CCNetTest\WorkingFolder\OutputLogs\FxCop.xml</file>
</files>
</merge>
<xmllogger/>
</publishers>
La sezione publishers infatti viene utilizzata per indicare a CC.NET dove trovare i vari file di log per la nostra build. Per il nostro esempio si è scelto di utilizzare una cartella chiamata OutputLogs nella Working folder del progetto. Il passo successivo è creare un task di nant che sia in grado di eseguire FxCop generando il file di output nella apposita cartella.
<!--FxCop reporting-->
<target name="FxCop" depends="CompileDebug">
<setenv name="PATH" path="${BuildToolsDir}\FxCop\;%PATH%" verbose="true" />
<fxcop
projectFile="${ProjectDir}\FxCopProject.FxCop"
analysisReportFilename="${OutputLogsDir}\FxCop.xml"
failonerror="false"
/>
</target>
Come si può notare NAnt ha un apposito task fxcop che funziona solamente quando la directory contenente l’eseguibile di FxCop è inclusa nel path, per questa ragione è necessario inserire preventivamente un task setenv in modo da impostare nel path anche la directory in cui è contenuto fxcop, dato che per una buona pratica tutti gli eseguibili di FxCop sono stati copiati all’interno della cartella BuildTools. Il task di fxcop è veramente banale, basta infatti creare preventivamente un file di progetto aprendo FxCop tramite menu, impostando le dll da caricare e salvando il progetto in formato .FxCop nella Workingfolder del progetto, in questo modo si può specificare direttamente il progetto con l’attributo projectFile dal task di NANT impostando FxCop direttamente dalla sua interfaccia. Per far si che CC.NET possa leggere l’output di FxCop si deve poi far generare il risultato nella cartella OutputLogs.
Una volta impostato il tutto si può verificare che ora nella pagina di dettaglio delle build viene automaticamente riportato l’output di FxCop.
In questo caso è presente un errore critico, il nostro assembly non ha uno strong name più 3 warning non critici per la classe Class1, tutti localizzati nel metodo Test().
Nel subversion di DotNetMarche la versione che si riferisce a questo esempio è la 117, non dimenticate che nel subversion non sono inclusi gli eseguibili dei BuildTools che debbono essere scaricati separatamente.
Alk.