Codeanalyse mit FX Cop für MS Visual Studio - Seminararbeit 2011
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
FACHHOCHSCHULE KÖLN – COLOGNE UNIVERSITY OF APPLIED SCIENCES
Codeanalyse mit FX Cop
für MS Visual Studio
Seminararbeit 2011
Michael Laudenberg, 11040923
26.05.2011
Die Codeanalyse wird im allgemeinen eingesetzt um Programmierfehler auszuschließen. Durch
Codierungsregeln, kann die Produktivität einzelner Softwareentwickler gesteigert werden. …
Fachhochschule Köln – Cologne University of Applied Sciences 2
Codeanalyse mit FX Cop für MS Visual Studio
1. Vorwort: .....................................................................................................................................3
2. Grundlagen Codeanalyse.............................................................................................................3
2.1. Das V-Modell .......................................................................................................................4
2.2. Statische Codeanalyse .........................................................................................................5
2.2.1. Manuelle formale Inspektion .......................................................................................6
2.2.2. Manuelle Reviewtechnik ..............................................................................................6
2.2.3. Stilanalyse....................................................................................................................7
2.2.4. Slicing ..........................................................................................................................8
2.2.5. Datenflussanomalien ...................................................................................................9
3. FX Cop....................................................................................................................................... 10
3.1. Systemvoraussetzungen .................................................................................................... 11
3.2. Introspection Code Model ................................................................................................. 11
4. CIL – Common Intermediate Language ...................................................................................... 12
5. Installation von FX Cop .............................................................................................................. 13
6. Erstellen eigener Regeln (Custom Rules) ................................................................................... 13
6.1. Metadata XML ................................................................................................................... 14
6.2. BaseCustomRule................................................................................................................ 16
6.3. Die erste Custom Rule ....................................................................................................... 17
6.4. Verwenden der Custom Rule ............................................................................................. 19
6.5. Testen der Custom Rule ..................................................................................................... 22
7. Alternativen / Ergänzungen ....................................................................................................... 23
8. Fazit .......................................................................................................................................... 24
9. Quellen ..................................................................................................................................... 25
Fachhochschule Köln – Cologne University of Applied Sciences 3
Codeanalyse mit FX Cop für MS Visual Studio
1. Vorwort:
Ich bin seit ca. zwei Jahren in der Softwareentwicklung der Firma „Oevermann Networks“ tätig. Da
die Firma stetig am expandieren ist, werden auch regelmäßig neue Programmierer eingestellt. Diese
kommen meist frisch aus dem Studium und haben kaum Berufserfahrung. Als ich in der Firma
angefangen habe zu programmieren, ist es mir so ergangen, dass ich nur Antworten auf gezielte
Fragen von den Experten bekommen habe. Es kam sehr selten vor, dass sich jemand die Zeit nehmen
konnte, gemeinsam mit mir meinen geschrieben Code zu analysieren. Fehler treten daher oft erst
kurz vor der Projektabnahme in Erscheinung. Ein frühzeitiges Hinweisen auf potentielle
Fehlerquellen im Code, würde einem Anfänger sehr großen Nutzen bringen.
Da die Firma ein eigenes Framework besitzt, ist es verboten gewisse Methoden aus dem .Net
Framework zu verwenden. Ebenso gibt es im .Net gewisse Stolpersteine, wie z.B. das man keine
„public const“-Variablen verwenden soll. Statt dessen „pubic readonly“. Eine „public const“-Variable
wird in einer geerbten Klasse durch einen festen Wert ersetzt. Wenn jetzt der Wert für die „public
const“-Variable in der Vaterklasse geändert wird, würde die Änderung erst nach einem Rebuild in
der geerbten Klasse ankommen. Dies kann in der Praxis zu einer sehr komplizierten Fehlersuche
führen. Damit nicht jeder Neuling der Firma solche Erfahrungen machen muss, wurden bei
Oevermann Networks Programmierungsregeln in Form einer statischen Codeanalyse eingeführt.
Verstöße gegen Programmierungsregeln, werden bereits beim kompilieren im Microsoft Visual
Studio inklusive Lösungsvorschlag angezeigt. Somit ist die Codeanalyse ein wichtiger Beitrag zur
Qualitätssicherung geworden.
Meine Zielsetzung dieser Seminarbeit umfasst eine Demonstration der Einsetzbarkeit und
Vielseitigkeit der Statischen Codeanalyse. Nachdem einige Grundlagen der Codeanalyse beschrieben
werden, wird die Erstellung eigener „Custom Rules“ anhand von Beispielen dargestellt.
2. Grundlagen Codeanalyse
Mit der stetig steigenden Komplexität und dem Umfang von Softwareprojekten, steigt auch die
Fehleranfälligkeit. Eine Methode um dieser entgegenzuwirken, ist der Einsatz von
Codeanalyseverfahren. Man unterscheidet hierbei zwischen statischer und dynamischer Codeanalyse
[Ligg02]. Der wesentliche Unterschied liegt darin, dass bei der statischen Analyse die Software nicht
ausgeführt wird. Es wird der geschriebene Quelltext oder Maschinencode auf Merkmale untersucht.
Bei der dynamischen Analyse hingegen, wird die Software gestartet und mit Testdaten gefüttert. Eine
Code Analyse soll Fehler erkennen und möglichst auch lokalisieren, um den Zeitaufwand beim
aufwändigen Debuggen zu minimieren.
Jedes große Softwareprojekt sollte nach einem im Voraus festgelegten Vorgehensmodell geplant
werden. Dabei sollte auch bereits das Testen integriert werden. Bekannt ist in diesem
Zusammenhang das V-Modell von Boehm [Spil07]. Es stellt die Testaktivitäten als gleichwertig zur
Entwicklung und Programmierung dar. Das Verständnis vom Softwaretest wurde damit nachhaltig
beeinflusst. Auch wenn im Projekt nach einem anderen Vorgehensmodell gearbeitet wird, lassen sich
die im Folgenden dargestellten Prinzipien übertragen.Fachhochschule Köln – Cologne University of Applied Sciences 4
Codeanalyse mit FX Cop für MS Visual Studio
2.1.Das V-Modell
Die Grundidee des allgemeinen V-Modells ist, dass Entwicklungsarbeiten und Testarbeiten
zueinander korrespondierende, gleichberechtigte Tätigkeiten sind. Bildlich dargestellt wird dies durch
die zwei Äste eines „V“s [Spil07].
Der linke Ast steht für die immer detaillierter werdenden Entwicklungsschritte, in deren Verlauf das
vom Kunden gewünschte System schrittweise entworfen und schließlich programmiert wird. Der
rechte Ast steht für Integrations- und Testarbeiten, in deren Verlauf elementare Programmbausteine
sukzessive zu größeren Teilsystemen zusammengesetzt (integriert) und jeweils auf richtige
Funktionen geprüft werden. Integration und Test enden mit der Abnahmeprüfung des auf diesem
Weg entstandenen Gesamtsystems.
Anforderungsdefinition Abnahmetest
Funktionaler Systemtest
Systementwurf
Technischer Systementwurf Integrationstest
Komponenten- Komponententest
spezifikation
Programmierung
Statische
Codeanalyse
Verifikation
Validierung
Konstruktion & Integration
Anforderungsdefinition: Die Wünsche und Anforderungen des Auftraggebers oder späteren
Systemanwenders werden gesammelt, spezifiziert und verabschiedet. Zweck und gewünschte
Leistungsmerkmale des zu erstellenden Softwaresystems liegen damit fest.
Funktionaler Systementwurf: Die Anforderungen werden auf Funktionen und Dialogabläufe des
neuen Systems abgebildet.
Technischer Entwurf: Die technische Realisierung des Systems wird entworfen (Schnittstellen,
Systemarchitektur).
Komponentenspezifikation: Für jedes Teilsystem werden Aufgabe, Verhalten, innerer Aufbau und
Schnittstelle zu anderen Teilsystemen definiert.Fachhochschule Köln – Cologne University of Applied Sciences 5
Codeanalyse mit FX Cop für MS Visual Studio
Programmierung: Implementierung jedes spezifizierten Bausteins (Modul, Unit, Klasse o.Ä.) in einer
Programmiersprache. Während der Programmierung wird die statische Codeanalyse ausgeführt.
Fehler werden beim kompilieren angezeigt.
Der Komponententest prüft, ob jeder einzelne Softwarebaustein für sich seiner Spezifikation erfüllt.
Der Integrationstest prüft, ob Gruppen von Komponenten wie im technischen Systementwurf
zusammenspielen.
Der Systemtest prüft, ob das System als Ganzes die spezifizierten Anforderungen erfüllt.
Der Abnahmetest prüft, ob das System aus Kundensicht die vertraglich vereinbarten
Leistungsmerkmale aufweist.
In jeder Teststufe ist also zu überprüfen, ob die Entwicklungsergebnisse diejenigen Anforderungen
erfüllen, die auf der jeweiligen Abstraktionsstufe relevant bzw. spezifiziert sind. Dieses Prüfen der
Entwicklungsergebnisse gegen die ursprünglichen Anforderungen wird Validieren genannt.
2.2. Statische Codeanalyse
Grundsätzlich kann man folgende Merkmale der statischen Codeanalyse zuweisen [Ligg02]:
- Es erfolgt keine Ausführung der zu prüfenden Software.
- Alle statischen Analysen können prinzipiell ohne Computerunterstützung durchgeführt
werden.
- Es werden keine Testfälle gewählt.
- Vollständige Aussagen über die Korrektheit oder Zuverlässigkeit können nicht erzeugt
werden.
Ungeachtet der manuellen Durchführbarkeit statischer Analysen ist eine Werkzeugunterstützung
sinnvoll und sollte in jedem Fall genutzt werden. Bei den statischen Analysetechniken unterscheidet
man zwischen Stilanalyse, Grafiken und Tabletten, Slicing, Datenflussanomalieanalyse und den
manuellen Inspektions- und Review-Techniken.Fachhochschule Köln – Cologne University of Applied Sciences 6
Codeanalyse mit FX Cop für MS Visual Studio
2.2.1. Manuelle formale Inspektion
Die formale Inspektion hat das Ziel eine Steigerung von Effektivität und Effizienz der Fehlerfindung
durch einen formal definierten Prozess zu erreichen. Die formale Inspektion ist nach der „IEEE
Standard for Software Reviews“ in 6 Phasen eingeteilt.
1. Planung
2. Einführung
3. Vorbereitung
4. Inspektionssitzung
5. Nachbearbeitung
6. Wiedervorlage
In der Phase Planung werden die beteiligten Personen, Verfahren sowie die Dokumente und der
Aufwand festgestellt. In der nächsten Phase werden die Informationen über Prüflinge und
Spezifikationen an die Inspektoren weiter gegeben. Die Vorbereitung dient zur Auseinandersetzung
mit dem Prüfling. Die Inspektionssitzung ist eine Diskussionsrunde mit klaren Regeln, in der alle
Befunde protokolliert werden. In der Nachbearbeitung erfolgen die Fehlerkorrekturen. In der Phase
Wiedervorlage werden die Korrekturen überprüft und die Inspektionsberichte angefertigt. Die
Vorteile der formalen Inspektion liegen in der Anwendbarkeit auf alle Dokumente der
Softwareentwicklung und zählt als die leistungsfähigste manuelle Technik. Jedoch ist die
Durchführung zeitaufwendig und teuer. Daher wird sie nur auf kleine Teilprodukte angewendet.
Die formale Inspektion kommt überwiegend bei kritischen Software-Komponenten mit zentraler
Bedeutung zum Einsatz, da sie sehr leistungsfähig jedoch auch teuer und zeitaufwendig ist.
2.2.2. Manuelle Reviewtechnik
Im Unterschied zur formalen Inspektion gibt es hier keinen formalen Ablauf und die Reviewdaten
werden in der Regel nicht aufgezeichnet. Reviews sind nicht so Effizient wie die formale Inspektion.
Jedoch werden bei der Durchführung weniger Ressourcen und Zeit verbraucht, was dieses Verfahren
Kostengünstiger macht. Durch diese Eigenschaften werden Reviews nicht nur zur Fehlerfindung,
sondern auch zur Entscheidungsfindung benutzt.
Die Reviewtechnik kommt meist bei Software-Teilen von mittlerer Kritikalität zum Einsatz, da sie
nicht so teuer wie die formale Inspektion und trotzdem leistungsfähig ist.
Die Durchführung findet in Form einer Sitzung statt, bei der gemeinsam mit einem Arbeitskollegen
der programmierte Code begutachtet wird. Dieser Arbeitskollege muss bereits gut vorbereitet in die
Sitzung kommen, da ca. 80 % der Fehler bereits in der Vorbereitung erkannt werden. Laut einer
Studie von Dipl. Inf. Peter Rösler, werden für 100 – 150 NLOC („non commentary lines of code“)
einer Stunde Aufwand berechnet.Fachhochschule Köln – Cologne University of Applied Sciences 7
Codeanalyse mit FX Cop für MS Visual Studio
2.2.3. Stilanalyse
Ein Anwendungspunkt der Werkzeuggestützten statischen Codeanalyse ist die Stilanalyse. Diese
beschäftigt sich mit der Überprüfung der Programmierkonventionen. Diese
Programmierkonventionen werden in Bereiche eingeteilt, wie etwa:
Regelwerk für Sourcecode:
Hier fallen beispielsweise Regeln der Firmen, Abteilungen oder Teams an, sowie Vorschriften durch
den Anwendungsbereich.
Ausschließen von Konstrukten:
Das Ausschließen festgelegter Konstrukte, die Fehler begünstigen, Qualität mindern, Portabilität
verhindern oder das Verständnis reduzieren.
Layout:
Beispielsweise die Kammersetzung der {}-Klammern. Es sind viele weitere Konventionen denkbar.
Beispiel für Regeln der Stilanalyse:
Kontrollstrukturen
➔ return nur einmal pro Funktion
➔ keine Schleifen mit mehrfachen Ausgängen
➔ kein continue oder break innerhalb von Schleifen
➔ ...
Operationen
➔ Zuweisungen in Ausdrücken sind verboten
➔ Mehrfachzuweisungen sind Verboten (x=y+(z=5))
➔ ...
Datentypen, Variablen
➔ Variablen sind stets zu initialisieren
➔ ungültige Zeiger sind als NULL-Pointer zu belegen
➔ Konstanten und Makros komplett in Großbuchstaben
➔ Variablen und Funktionen in Kleinbuchstaben
➔ ...
Bewertung der Stilanalyse:
Die Stilanalyse schränkt Fehlerquellen ein, kann die Lesbarkeit verbessern, das Code-Verständnis
steigern und die Testbarkeit erhöhen.
Die Stilanalyse ist bei Programmiersprachen mit liberaler, qualitätsmindernder Syntax unverzichtbar.Fachhochschule Köln – Cologne University of Applied Sciences 8
Codeanalyse mit FX Cop für MS Visual Studio
2.2.4. Slicing
Slicing zielt auf die weitgehend automatische Bereitstellung von Informationen über
Wirkzusammenhänge in einem betrachteten Programm. Die Arbeitsweise ist vergleichbar mit der
manuellen Fehlersuche (Debugging) nach dem Auftreten eines Fehlverhaltens. Ein Programm Slice
beschreibt, welche Anweisungen auf welche Weise einen betrachteten Wert beeinflussen. Ein Slice
wird also stets in Bezug auf einen betrachteten Wert an einer bestimmten Stelle des Programms
angegeben. Streng genommen ist dies die Definition des so genannten rückwärtsgerichteten Slicing.
Es gibt auch forward Slicing. Ein derartiger Slice stellt also dar, welche Anweisungen auf welche
Weise von einem betrachteten Wert beeinflusst werden. Rückwärtsgerichtetes Slicing entspricht der
Analyse, die bei der manuellen Ursachensuche für ein betrachtetes Fehlverhalten durchgeführt wird.
Zunächst wird man prüfen, ob das Fehlverhalten durch die aktuell betrachtete Anweisung verursacht
wurde. Ist das nicht der Fall, so werden die Anweisungen überprüft, die für die Anweisung Daten
liefern oder ihre Ausführung steuern. Dieses Verfahren kann fortgesetzt werden, bis keine Vorgänger
mehr existieren, also Eingabeanweisungen erreicht werden. Der so erzeugte Slice enthält alle
potentiellen Verursacher des fehlerhaften Wertes an der betrachteten Stelle. Durch Slicing liegt die
folgende Information in komprimierter Form vor:
- Anweisungen, die den Wert einer betrachteten Variablen an einer bestimmten Stelle
beeinflussen können
- Beteiligte Variablen und Datenflüsse
- Kontrollflüsse
Alle Anweisungen, die nicht Bestandteil des Slices sind, müssen bei der Fehler suche nicht geprüft
werden. Durch automatisches Slicing kann daher die der Aufwand reduziert werden. Man
unterscheidet statisches und dynamisches Slicing.
Statisches Slicing:
Es werden Wirkungszusammenhänge aus dem Quellcode heraus erzeugt.
Diese dienen zum Verständnis von Programmen.
Dynamisches Slicing:
Die Wirkungszusammenhänge werden zur Laufzeit ermittelt und bestimmte Situationen betrachtet.
Diese dienen zum Debugging von Programmen.Fachhochschule Köln – Cologne University of Applied Sciences 9
Codeanalyse mit FX Cop für MS Visual Studio
2.2.5. Datenflussanomalien
Diese Methode dient zur statischen Überprüfung des Datenflusses auf Anomalien. Die Prüfung ist
Teilweise in Compilern oder IDEs vorhanden [Ligg02].
U: undefiniert
D: definiert
R: referenziert
Es werden Zugriffsequenzen in Bezug auf eine Variable betrachtet.
Beispielsequenz: „URDRU“
Die Beispielsequenz beginnt mit „UR“. Dabei tritt das Problem auf, das zu dem Zeitpunkt an dem
referenziert wird , die Variable noch undefiniert ist. Es handelt sich um eine Anomalie.
Anomalien:
- UR: Referenz auf undefinierte Variable
- DD: Doppelte Definition einer Variable
- DU: Definierte Variable wird ohne Verwendung des Wertes wieder Undefiniert.
Zustandsautomat zur Datenflussanomalie:
D D
Datenfluss- definiert referenziert
Anomalie
U R
R D U
Start U undefiniert
UFachhochschule Köln – Cologne University of Applied Sciences 10
Codeanalyse mit FX Cop für MS Visual Studio
3. FX Cop
Im Folgenden wird die statische Analyse von Microsoft verwendet, „FX Cop“. FX Cop wurde
entwickelt um .Net Code auf Programmierregeln oder Codierungsrichtlinien hin zu prüfen.
Die Fähigkeiten von FX Cop umfassen das gesamte Spektrum der statischen Code-Analyse. Es gibt
eine Vielzahl von Elementen auf die zugegriffen werden kann. Ob Namenskonvertierungen,
Parameterwerte, Rechtschreibung oder XML Kommentare. Jede Zeile Code wird eindeutig als
OPCode repräsentiert. Es kann so ziemlich für jedes Problem eine spezifische Regel erstellt werden.
Durch die Verwendung von Fx Cop Regeln können Sie unter anderem folgende Ergebnisse erzielen:
Sicherstellen, dass Bezeichnungen von Steuerelemente in Formularen und Web-Seiten Ihrer
Namenskonventionen folgen.
Prüfen, ob die bevorzugten Steuerelemente, Komponenten und Klassen verwendet werden.
Es können Bedingungen und Schleifen auf ihre Code-Metrik untersucht werden.
Ganze Methoden und Klassen, oder je nach Implementierung auch nur spezielle Varianten beim
Aufrufen von Methoden, können gesperrt werden.
Überprüfen ob Elemente korrekt durch XML-Kommentare dokumentiert sind.
Es gibt viele weitere Möglichkeiten.
Microsoft bietet bereits eine Fülle von Programmierungsregeln an. Diese sind in verschiedene
Kategorien aufgeteilt. Die Folgenden Beispiele beschreiben einige Regeln.
• Design
Bsp.: CA1007 „Nach Möglichkeit Generika verwenden“
• Globalization
Bsp.: CA1309 „Ordinal-StringComparison verwenden“
• Naming
Bsp.: CA1707 „Bezeichner sollten keine Unterstriche enthalten“
• Performance
Bsp.: CA1821 „Leere Finalizer entfernen“
• Security
Bsp.: CA2100 „SQL-Abfragen auf Sicherheit überprüfen“
• Usage
Bsp.: CA1806 „Methodenergebnisse nicht ignorieren“
•…
Anders als bei bisherigen statischen Analyse Tools wie z.B. „lint“ für C, untersucht FX Cop nicht den
Source Code, sondern die binäre „Common Intermediate Language“ (CIL) (Siehe Kap. 4). Diese liegt in
Form einer DLL oder Exe da. Dies hat den Vorteil, dass die Regeln auf jede .Net Sprache wie C# oder
VB angewendet werden können.
Die erste Version vom FX Cop wurde bereits kurz nach der Veröffentlichung vom .Net Framework 1.0
im Jahr 2002 bereit gestellt.Fachhochschule Köln – Cologne University of Applied Sciences 11
Codeanalyse mit FX Cop für MS Visual Studio
3.1.Systemvoraussetzungen
Es wird natürlich vorausgesetzt das eine aktuelle Version von Microsoft Visual Studio und dem .NET
Framework vorliegt. Weitere Mindestvoraussetzungen die das System betreffen sind nicht
spezifiziert. Die folgenden Beispiele wurden alle unter Visual Studio 2010 erstellt.
3.2. Introspection Code Model
Bislang wurde zum analysieren von CIL (siehe Kap. 4) die API „System.Reflection“ verwendet. Mit
Reflection ist man allerdings schnell an seine Grenzen gestoßen. Das .NET Framework bietet daher
zusammen mit dem FX Cop, eine alternative Technologie namens Introspektion an. Die Introspektion
API ähnelt der bisherigen Reflection API, sie ist aber spezialisiert auf die Analyse-Funktionen. Wer mit
Reflection zufrieden war, wird von der Introspection API begeistert sein.
Das Code Modell unterteilt die Metadaten in eine Hierarchie von „Nodes“. Für jede Node wurde eine
Klasse in der Introspection API angelegt. Anhand dieser Nodes kann jede .Net Klasse oder Methode
untersucht werden.
In Abbildung 1 wird das komplette Introspection Code Model gezeigt. Die Klassen sind so
angeordnet, dass es dem Entwickler möglich ist von einer „Node“ zur anderen zu springen. Das
Introspection Code Model kann sehr detailliert eine .NET Klasse darstellen.
Abbildung 1: Introspection Code Model [Kres08]Fachhochschule Köln – Cologne University of Applied Sciences 12
Codeanalyse mit FX Cop für MS Visual Studio
4. CIL – Common Intermediate Language
[Wenz08]
Die Common Intermediate Language (CIL auch bekannt als IL oder MSIL) ist eine Zwischensprache, in
die alle Programme der Common Language Infrastructure übersetzt werden. CIL ist eine
objektorientierte Assemblersprache und ist vollständig stackbasiert. Auf dem Zielcomputer wird die
CIL von einem Laufzeitsystem (Virtual Execution System) in systemeigenen Programmcode übersetzt,
um die in CIL vorliegenden Programme ausführen zu können. Es ist das gleiche Prinzip wie auch die
Java Runtime Environment.
Vorteil dabei ist, dass alle .NET Sprachen, wie C#, VB und J# die selbe CIL erzeugen. Dadurch kann der
FX Cop für sämtliche .NET Sprachen eingesetzt werden, ohne dass jedes Mal die Regeln neu
programmiert werden müssen.
Da die FX Cop Codeanalyse nur auf CIL angewendet werden kann, ist es nicht möglich Regeln zu
programmieren, die Beispielsweise falsche Einrückungen oder leere Zeilen erkennen.
Aus dem C# Code wird CIL erzeugt. Ein kleines Beispiel zeigt den Zusammenhang.
C#:
a = a + b;
oder,
a += b;
CIL:
ldloc.0 // (ldloc = load local) erste lokale Variable laden;
ldloc.1 // zweite lokale Variable laden;
add // Addieren
stloc.0 // (stloc = store local) speichern des ErgebnissesFachhochschule Köln – Cologne University of Applied Sciences 13
Codeanalyse mit FX Cop für MS Visual Studio
5. Installation von FX Cop
Fx Cop ist Bestandteil des .NET Framework 4 in der Version 7.1. oder aktueller. Um FX Cop einsetzen
zu können, müssen die folgenden zwei Schritte erledigt werden.
1. Laden Sie das Microsoft Windows SDK für Windows 7 und .NET Framework 4 Version 7.1.
runter und installieren Sie es.
http://www.microsoft.com/downloads/en/confirmation.aspx?FamilyID=6B6C21D2-2006-
4AFA-9702-529FA782D63B
2. Starten Sie %ProgramFiles%\Microsoft SDKs\Windows\v7.1\Bin\FXCop\FxCopSetup.exe um
die Installation von FX Cop aufzurufen.
6. Erstellen eigener Regeln (Custom Rules)
Zum Erstellen einer eigenen Regel empfiehlt es sich zwei Projekte in Visual Studio anzulegen. In
einem Projekt erstellen wir neue Regeln und in dem anderen werden Sie getestet.
Abbildung 2: Projektmappe
Die Projektmappe sollte diese Struktur aufweisen, damit das Arbeiten übersichtlich bleibt.
Es gibt ein paar wichtige Punkte, die bei der Erstellung des Projektes berücksichtigt werden müssen.
Es ist zwingend notwendig das diese Vorgaben eingehalten werden, da sonst die erstellten Regeln
nicht als solche vom System erkannt werden.
1. Das Projekt, welches die Implementierungen der Custom Rules enthalten soll, muss vom Typ
„Klassenbibliothek“ sein und exakt die gleiche Bezeichnung haben wie die übergeordnete
Projektmappe. In unserem Beispiel heißt diese „StaticCodeAnalyse“.Fachhochschule Köln – Cologne University of Applied Sciences 14
Codeanalyse mit FX Cop für MS Visual Studio
2. Es müssen zwei Referenzen angegeben werden, FxCopSdk.dll und Microsoft.Cci.dll. Man
kann dazu die DLLs im Installationsverzeichnis von Visual Studio suchen, oder man löst es ein
wenig eleganter. Rechtsklick auf das Projekt und „Projekt entladen“ auswählen. Jetzt kann
die *.csproj Datei geöffnet und bearbeitet werden. In dieser Datei muss innerhalb der
-Node folgender Code hinterlegt werden.
$(CodeAnalysisPath)\FxCopSdk.dll
False
$(CodeAnalysisPath)\Microsoft.Cci.dll
False
3. Nachdem die Änderungen gespeichert sind, muss das Projekt mit einem Klick auf „Projekt
erneut laden“ wieder geladen werden.
6.1.Metadata XML
In dem Projekt „CodeAnalyse“ wurde ein Ordner „MetaData“ angelegt. Jedes Projekt das Custom
Rules erstellen möchte, benötigt eine XML Datei in der die Meta Daten für sämtliche Regeln definiert
werden. Damit diese XML Datei nach der Kompilierung in die erstellte Assembly integriert wird, muss
in den Eigenschaften der XML Datei angegeben werden das sie eine „eingebette Ressource“ ist.
Abbildung 3: Metadata XML EigenschaftenFachhochschule Köln – Cologne University of Applied Sciences 15
Codeanalyse mit FX Cop für MS Visual Studio
Im Folgenden kann der Aufbau dieser XML Datei eingesehen werden. Jede Regel bekommt ein
„Rule“-Tag. Hier werden sämtliche Informationen zu einer Custom Rule gesammelt.
FriendlyName: Der Name, der in der Regelbibliothek und der Fx Cop GUI auftaucht.
TypeName: Der Name der .NET-Klasse, die die Regel implementiert.
Category: Die Kategorie der Regel. Sie sollte in etwa den gleichen Namen haben wie der
FrienlyName. Das Feld Categorie ist für den End User wichtig, wenn er Meldungen der „Custom Rule“
abfangen will.
CheckId: Identifizierungsnummer der Regel. Es dürfen keine Regeln die selbe CheckId
verwenden. (Bsp.: „CR1010“)
Name: Der Name der Regel, der in der FxCop Gui auftaucht.
Description: Eine kurze Beschreibung der Regel. Bei einem Verstoß gegen die Regel wird die
Beschreibung im Errorfenster angezeigt.
Url: Diese Url sollte auf eine Seite weiterleiten, auf der ein konkretes Lösungsbeispiel
dargestellt wird.
Resolution: Bei einem Regelverstoß erscheint die Resolution als Lösungsvorschlag im
Errorfenster.
MessageLevel: CriticalError, Error, CriticalWarning oder Warning.
Certainty: Ein Wert von 0 – 100 der beschreiben soll, wie oft es sich bei einem erkannten Fehler
um einen Tatsächliches Problem handelt. Der Wert dient nur zur Information.
Email: Eine Email Adresse die in Verbindung mit der Regel angezeigt wird. Meistens bleibt
dieses Feld leer.
FixCategories: Breaking, NonBreaking oder DependsOnFix. Dient nur als Information.
Owner: Der Besitzer oder Ersteller der Custom Rule. Bleibt meistens leer.Fachhochschule Köln – Cologne University of Applied Sciences 16
Codeanalyse mit FX Cop für MS Visual Studio
6.2.BaseCustomRule
Wie in Abbildung 2 zu sehen, liegt in der Projektmappe „CodeAnalyse“ eine Klasse mit dem Namen
„BaseCustomRule“. Diese erbt von „BaseIntrospectionRule“ und wird später die Vaterklasse aller
erzeugten CustomRules werden.
Es werden zwei Verweise benötigt, die im Installationsordner von FxCop zu finden sind. „FxCopSDK“
und „Microsoft.Cci“.
Abbildung 4: BaseCustomRuleFachhochschule Köln – Cologne University of Applied Sciences 17
Codeanalyse mit FX Cop für MS Visual Studio
6.3.Die erste Custom Rule
Zur Demonstration wird in dem folgenden Source Code eine Custom Rule erstellt, die sämtliche
Methoden auf Groß- bzw. Kleinschreibung prüft. Ich möchte damit erreichen, dass jede Methode die
definiert wird großgeschrieben wird. Man könnte die Regel noch erweitern, so dass alle Variablen
kleingeschrieben werden.
Die Regel hat den Namen „MethodsToUppercase“ bekommen.
Abbildung 5: Custom Rule, MethodsToUppercase
Da die selbst erstellte Custom Rule nur Methoden untersuchen soll, muss die Check Methode mit
einem Parameter vom Typ Member überschrieben werden. Ein Member kann entweder eine
EventNode, ein Field, eine PropertyNode oder ein Methode sein. Für jede Methode oder für jedes
Field in der Prüfenden Klasse, wird sie aufgerufen. Im Falle der MethodsToUppercase Regel,
interessieren nur die Methoden. Daher startet die Check-Methode mit einer Typumwandlung von
Member in eine Methode. Kommt bei diesem Cast ein „null“ heraus, ist klar das es sich bei dem
Member um keine Methode handelt. Handelt es sich aber um eine Methode, so wird per Substring
das erste Zeichen des Methodennamens ausgelesen und auf die Großschreibung geprüft. Bei einemFachhochschule Köln – Cologne University of Applied Sciences 18
Codeanalyse mit FX Cop für MS Visual Studio
Verstoß wird ein „Problem“ zurückgegeben. Anhand der Definition in der Metadaten-XML, wird
daraus ein Fehler erstellt und in der Fehlerliste von Visual Studio ausgegeben.
Die XML Definition für die Regel „MethodsToUppercase“ könnte wie folgt aussehen.
Abbildung 6: Metadaten für die Regel MethodsToUppercase
In der „Resolution“ tauchen zwei Werte in geschweiften Klammern auf. Diese werden, wie bei der
Verwendung von „string.Format()“, durch die Werte ersetzt, welche dem Problem übergeben
wurden. Das sind in diesem Fall der Name der Methode und die Zeichenfolge „method“.Fachhochschule Köln – Cologne University of Applied Sciences 19
Codeanalyse mit FX Cop für MS Visual Studio
6.4.Verwenden der Custom Rule
Nachdem die Regel und die Metadaten geschrieben sind, kann die Projektmappe kompiliert werden.
Als Resultat erhält man eine DLL die sich in der Projektmappe unter „/bin“ finden lässt.
Abbildung 7: Build Resultat
Diese DLL muss in das Rules Verzeichnis von Visual Studio 2010 gelegt werden.
“C:\Program Files\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop\Rules”Fachhochschule Köln – Cologne University of Applied Sciences 20
Codeanalyse mit FX Cop für MS Visual Studio
Abbildung 8: Das Zielverzeichnis für unsere Custom Rule
Achtung! Es ist wichtig das Visual Studio 2010 neu gestartet wird, nachdem die Regel in das
Zielverzeichnis verschoben wurde.
Wie schon in Abbildung 2, in der Projektmappe zu sehen ist, benötigen wir ein zweites Projekt zum
Testen der Regeln. In diesem Projekt können beliebig viele Klassen abgelegt werden. Es ist sinnvoll
darin einen Fehlerfall und einen korrekten Fall zu implementieren. Beim späteren Kompilieren sollte
die Regel dann im Fehlerfall anschlagen.
Ein Rechtsklick auf dieses Testprojekt, in unserem Fall „ErrorTesting“, öffnet einen Dialog, in dem wir
„Eigenschaften“ auswählen. In den Eigenschaften selektiert man den Unterpunkt „Codeanalyse“, wie
in der nächsten Abbildung dargestellt.Fachhochschule Köln – Cologne University of Applied Sciences 21
Codeanalyse mit FX Cop für MS Visual Studio
Abbildung 9: Einstellungen des Projektes "ErrorTesting"
Es wird ein bestehendes „RuleSet“ ausgewählt und auf „Öffnen“ geklickt. Man kommt nun zu einer
Auswahl von Regeln. Darunter sollte sich jetzt auch die erstellte Custom Rule befinden.
Abbildung 10: Auswahl der verwendeten Regeln
In diesem Beispiel habe ich alle vordefinierten Regeln ausgeschaltet und nur die Custom Rule
aktiviert. Diese Auswahl wird gespeichert.Fachhochschule Köln – Cologne University of Applied Sciences 22
Codeanalyse mit FX Cop für MS Visual Studio
6.5.Testen der Custom Rule
Wie schon im letzten Abschnitt angesprochen, wird ein zweites Projekt benötigt, in dem die
erstellten Custom Rules getestet werden können. Zum Testen der neuen Regel werden zwei
Methoden erstellt. Eine ist großgeschrieben und die andere klein.
Wenn jetzt der Code kompiliert wird, wird er dabei gegen diese Regel geprüft. Die nächste Abbildung
zeigt die Resultierende Fehlermeldung.
Abbildung 11: Die Fehlerliste unter Verwendung der Custom Rule
Unsere Regel hat erfolgreich zugeschlagen. Mit einem „Warning“ wird darauf hingewiesen, dass die
Methode „methodToUppercaseTest2“ mit einem großen Buchstaben beginnen sollte.Fachhochschule Köln – Cologne University of Applied Sciences 23
Codeanalyse mit FX Cop für MS Visual Studio
7. Alternativen / Ergänzungen
Es ist nicht Möglich mit FXCop C#-Code direkt zu analysieren. FXCop prüft immer nur die aus C#-Code
resultierende CIL. Alternativ dazu bietet sich der StyleCop von Microsoft an. Mit dem StyleCop kann
man ein Regelwerk aufbauen, dass direkt auf C# Code angewendet wird. Somit können falsche
Einrückungen, leere Zeilen, Rechtschreibung und vieles mehr geprüft werden.
StyleCop ist nicht in der Standardinstallation von Visual Studio enthalten. Es steht aber frei im
Internet zum Download bereit. (http://stylecop.codeplex.com/releases/view/48036)
Es gibt sogar ein frei verfügbares Plug-In , welches Fehler nicht nur erkennt, sondern auch beheben
kann. Leere Zeilen etc. werden automatisch entfernt.
Weitere Hilfreiche Tools sind Cat.NET. und Pex.
Cat.NET ist ein Add-In für Visual Studio. Das Tool hilft dabei, Sicherheitslücken zu identifizieren und
Sicherheitsmängel in Bezug auf Cross-Site Scripting (XSS), SQL Injection und XPath Injection in
Applikationen zu verhindern.
Pex ist ein Whiteboxtest, welcher ebenfalls als Plug-In für Visual Studio bereit steht.
Mit Pex können Schleifen und Methoden dynamisch analysiert werden. Es werden beim Test einer
Schleife alle möglichen Parameter mitgegeben. Anschließend erhält man eine Auskunft darüber ob es
eine Konstellation von Parametern gibt, die eine Endlosschleife erzeugen.Fachhochschule Köln – Cologne University of Applied Sciences 24
Codeanalyse mit FX Cop für MS Visual Studio
8. Fazit
Statische Codeanalyse sollte fester Bestandteil eines jeden Softwareherstellers sein. Der Aufwand
zum Erstellen von Custom Rules darf nicht unterschätzt werden, aber die Mühe wird durch höhere
Codequalität bezahlt. Man kann von keinem Softwareentwickler erwarten, dass er fehlerfrei Code
erzeugt. Doch durch den Einsatz präziser Regeln, kann sichergestellt werden, dass bestimmte Fehler
vermieden werden.
Bei Oevermann Networks haben sich ca. 40 Custom Rules etabliert. Das Erstellen dieser Regeln hat
inklusive Einarbeitung etwa drei Monate, bei 20 Std./Woche, gedauert.
Meiner Meinung nach ist Codeanalyse den Aufwand wert und ist eine enorme Ergänzung zur
Qualitätssicherung.Fachhochschule Köln – Cologne University of Applied Sciences 25
Codeanalyse mit FX Cop für MS Visual Studio
9. Quellen
Buch:
- [Wenz08] Christian Wenz, Tobias Hauser, Karsten Samaschke, Jürgen Kotz: ASP .NET 3.5 mit
Visual C# 2008, 2008, ISBN 3-8273-2302-6
- [Ligg02] Peter Liggesmeyer: Software-Qualität, 2002, ISBN 3-8274-1118-1
- [Spil07] Andreas Spillner, Tilo Linz: Basiswissen Softwaretest, 2007, ISBN 3-89864-358-1
Artikel:
- [Kres08] Jason Kresowaty: FxCop and Code Analysis: Writing Your Own Custom Rules, 2008Sie können auch lesen
