Das kostenlose Tool FxCop von Microsoft bietet die Möglichkeit, eigene Design-Regeln festzulegen und somit beispielsweise in einem Team Unstimmigkeiten zu verhindern bzw. zu beheben.
Leider ist die Implementierung neuer Regeln nicht ganz trivial...
In den nächsten Tagen werde ich versuchen, mir wenigstens die Basis-Techniken anzueignen und meine Ergebnisse hier niederschreiben, vielleicht als eine Art kleines Tutorial.
Bis dahin bitte ich um Geduld.
Monday, October 27, 2008
Perfect Development Environment (Part 1)
Dieser Artikel (und seine Fortsetzungen) beschäftigen sich mit dem Aufsetzen der "perfekten" Entwicklungsumgebung für die Programmierung mit dem Microsoft .NET Framework 3.5 unter Microsoft Windows XP. "Perfekt" bedeutet in diesem Fall, dass sich die Umgebung darum kümmert, dass der Programmierer keine Fehler macht und sich an einen akzeptablen Programmierstil zu halten hat.
Da die Idee von einem meiner Professoren an der TFH Berlin stammt (nämlich Prof. Dr. Stefan Edlich), soll diese Einleitung mit seinen Worten zu diesen Intentionen enden: "Schon bei einem einfachen HelloWorld-Programm soll einem diese Entwicklungsumgebung Fehler um die Ohren hauen!" (sinngemäß).
Grundlage: Die eigentliche Entwicklungsumgebung
Als Basis für die perfekte Entwicklungsumgebung kommt für mich nur Microsoft Visual Studio 2008 infrage. Einerseits bietet diese IDE zahlreiche nützliche Features von vornherein an (built-in), andererseits lässt sie sich durch AddIns leicht um andere Funktionen erweitern. Zudem bin ich mit ihrem Einsatz vertraut. Die Wahl fiel also nicht schwer...
Ein kleines Projekt, um die Umgebung zu testen
Natürlich braucht man, wenn man eine solche Entwicklungsumgebung aufsetzen möchte, auch irgendein Projekt, welches man damit entwickeln möchte.
Für dieses Vorhaben habe ich mich dazu entschieden, ein kleines Kryptografie-Tool zu programmieren, welches vollständig auf Plugins basiert. Es selbst hat keine wirkliche Funktionalität, sondern stellt lediglich verschiedene Möglichkeiten zur Ein- und Ausgabe bereit, die von den Plugins (natürlich werden entsprechende Schnittstellen nach außen geliefert) genutzt werden können, um verschiedenste Verschlüsselungen und Hashing-Verfahren anzuwenden. Dieses Tool trägt den Codenamen "Krypta".
Microsoft Design Guidelines
Wer bereits einmal mit Microsoft Visual Studio gearbeitet hat und in den Eigenschaften einer Assembly unter dem Punkt "Code Analysis" einen Haken bei "Enable Code Analysis on Build" gesetzt hat, der wird sich vielleicht über die zahlreichen Warnungen wundern, die nun bei jeder Ausführung/jedem Build eines Projekts auf ihn einprasseln. Code Analysis bedeutet nichts anderes als die Analyse der Assembly bezüglich der Microsoft Design Guidelines for Class Library Developers. Dabei handelt es sich um zahlreiche (!) Regeln, die Microsoft den .NET-Programmierern auferlegt hat, um eine einheitliche Assembly-Programmierung zu erreichen.
Die folgende Abbildung zeigt die besagte Einstellung, die - falls erst zu einem späteren Zeitpunkt angewendet - einige schlaflose Nächte produzieren kann...
Ist diese Option erst einmal gesetzt, wird automatisch die gesamte Assembly auf die Einhaltung der Guidelines hin überprüft.
Schon eine leere Windows-Forms-Anwendung produziert (auf meinem System) drei Warnungen:
CA2210
Microsoft.Design : Sign 'WindowsFormsApplication1.exe' with a strong name key.
CA1014
Microsoft.Design : Mark 'WindowsFormsApplication1.exe' with CLSCompliant(true) because it exposes externally visible types.
CA1824
Microsoft.Performance : Because assembly 'WindowsFormsApplication1.exe' contains a ResX-based resource file, mark it with the NeutralResourcesLanguage attribute, specifying the language of the resources within the assembly. This could improve lookup performance the first time a resource is retrieved.
Diese Warnungen lassen sich jedoch leicht entfernen. Um eine Assembly mit einem starken Namen zu versehen (CA2210), muss man lediglich in deren Eigenschaften (Rechtsklick auf die Assembly im Solution Explorer -> Eigenschaften) unter "Signing" einen Haken bei "Sign Assembly" setzen. In der DropDown-Box wählt man "New" aus, um eine neue Schlüsseldatei zu erzeugen (vgl. Abbildung).
Ist dieser Schritt getan (einfach den Anweisungen folgen), ist die Assembly mit einem starken Namen versehen und die Warnung verschwindet.
Um die zweite Warnung (CA1014) zu eliminieren, muss die Assembly als CLS-Compliant markiert werden (oder als explizit nicht CLS-Compliant). Die Warnung entsteht, wenn über diese Eigenschaft einer Assembly keine Angaben gemacht wurden. Um eine Assembly CLS-Compliant zu machen (CLS: Common Language Specification), muss an beliebiger Stelle (AssemblyInfo.cs wäre sinnvoll), das entsprechende Attribut gesetzt werden:
Was bringt es, eine Assembly als CLS-Compliant zu markieren?
CLS-Compliance bedeutet eigentlich "nur", dass die Assembly aus allen .NET-Sprachen heraus angesprochen werden kann, also beispielsweise keine reservierten Wörter einer dieser Sprachen als Methoden-Parameter o.ä. verwendet wurde. Eine Einhaltung der CLS-Compliance ermöglicht es einer größeren Zahl von Entwicklern, die entsprechende Assembly aus ihrer bevorzugten Sprache heraus anzusprechen.
Nun sind bereits zwei der drei Warnungen verschwunden. Die dritte Warnung (CA1824) kann genau so leicht behoben werden. Windows-Forms-Anwendungen besitzen (wie immer auf mein System bezogen) eine Ressourcen-Datei ("Resources.resx"). Diese Ressourcendatei ist nicht mit einer bestimmten Sprache verbunden. Die Design Guidelines empfehlen allerdings, eine Standard-Sprache anzugeben, da somit die Performance beim ersten Suchen der Ressource erhöht werden könne.
Ich bin nicht sicher, ob meine Lösung die richtige ist, aber sie hat die Warnung erfolgreich entfernt und das Programm lässt sich auch weiterhin starten. Ich habe lediglich die folgende Zeile direkt unter die CLS-Compliance-Zeile gesetzt:
Zusammenfassung
Ehrlich gesagt gibt es ja noch nicht so viel zum Zusammenfassen. Bisher ist eine Entwicklungsumgebung entstanden, die - falls gewünscht - eine oder mehrere Assemblies automatisch auf die Einhaltung der Microsoft Design Guidelines hin überprüft.
Damit ist die IDE schon einen großen Schritt in die richtige Richtung gegangen.
Abschließend sei noch erwähnt, dass die Microsoft Design Guidelines auch vom kostenfrei erhältlichen Tool "Microsoft FxCop" überprüft werden können (für alle, die kein Visual Studio haben).
Da die Idee von einem meiner Professoren an der TFH Berlin stammt (nämlich Prof. Dr. Stefan Edlich), soll diese Einleitung mit seinen Worten zu diesen Intentionen enden: "Schon bei einem einfachen HelloWorld-Programm soll einem diese Entwicklungsumgebung Fehler um die Ohren hauen!" (sinngemäß).
Grundlage: Die eigentliche Entwicklungsumgebung
Als Basis für die perfekte Entwicklungsumgebung kommt für mich nur Microsoft Visual Studio 2008 infrage. Einerseits bietet diese IDE zahlreiche nützliche Features von vornherein an (built-in), andererseits lässt sie sich durch AddIns leicht um andere Funktionen erweitern. Zudem bin ich mit ihrem Einsatz vertraut. Die Wahl fiel also nicht schwer...
Ein kleines Projekt, um die Umgebung zu testen
Natürlich braucht man, wenn man eine solche Entwicklungsumgebung aufsetzen möchte, auch irgendein Projekt, welches man damit entwickeln möchte.
Für dieses Vorhaben habe ich mich dazu entschieden, ein kleines Kryptografie-Tool zu programmieren, welches vollständig auf Plugins basiert. Es selbst hat keine wirkliche Funktionalität, sondern stellt lediglich verschiedene Möglichkeiten zur Ein- und Ausgabe bereit, die von den Plugins (natürlich werden entsprechende Schnittstellen nach außen geliefert) genutzt werden können, um verschiedenste Verschlüsselungen und Hashing-Verfahren anzuwenden. Dieses Tool trägt den Codenamen "Krypta".
Microsoft Design Guidelines
Wer bereits einmal mit Microsoft Visual Studio gearbeitet hat und in den Eigenschaften einer Assembly unter dem Punkt "Code Analysis" einen Haken bei "Enable Code Analysis on Build" gesetzt hat, der wird sich vielleicht über die zahlreichen Warnungen wundern, die nun bei jeder Ausführung/jedem Build eines Projekts auf ihn einprasseln. Code Analysis bedeutet nichts anderes als die Analyse der Assembly bezüglich der Microsoft Design Guidelines for Class Library Developers. Dabei handelt es sich um zahlreiche (!) Regeln, die Microsoft den .NET-Programmierern auferlegt hat, um eine einheitliche Assembly-Programmierung zu erreichen.
Die folgende Abbildung zeigt die besagte Einstellung, die - falls erst zu einem späteren Zeitpunkt angewendet - einige schlaflose Nächte produzieren kann...
Ist diese Option erst einmal gesetzt, wird automatisch die gesamte Assembly auf die Einhaltung der Guidelines hin überprüft.
Schon eine leere Windows-Forms-Anwendung produziert (auf meinem System) drei Warnungen:
CA2210
Microsoft.Design : Sign 'WindowsFormsApplication1.exe' with a strong name key.
CA1014
Microsoft.Design : Mark 'WindowsFormsApplication1.exe' with CLSCompliant(true) because it exposes externally visible types.
CA1824
Microsoft.Performance : Because assembly 'WindowsFormsApplication1.exe' contains a ResX-based resource file, mark it with the NeutralResourcesLanguage attribute, specifying the language of the resources within the assembly. This could improve lookup performance the first time a resource is retrieved.
Diese Warnungen lassen sich jedoch leicht entfernen. Um eine Assembly mit einem starken Namen zu versehen (CA2210), muss man lediglich in deren Eigenschaften (Rechtsklick auf die Assembly im Solution Explorer -> Eigenschaften) unter "Signing" einen Haken bei "Sign Assembly" setzen. In der DropDown-Box wählt man "New" aus, um eine neue Schlüsseldatei zu erzeugen (vgl. Abbildung).
Ist dieser Schritt getan (einfach den Anweisungen folgen), ist die Assembly mit einem starken Namen versehen und die Warnung verschwindet.
Um die zweite Warnung (CA1014) zu eliminieren, muss die Assembly als CLS-Compliant markiert werden (oder als explizit nicht CLS-Compliant). Die Warnung entsteht, wenn über diese Eigenschaft einer Assembly keine Angaben gemacht wurden. Um eine Assembly CLS-Compliant zu machen (CLS: Common Language Specification), muss an beliebiger Stelle (AssemblyInfo.cs wäre sinnvoll), das entsprechende Attribut gesetzt werden:
[assembly: CLSCompliant(false)]In diesem Fall wird die Assembly als explizit nicht CLS-Compliant markiert.
Was bringt es, eine Assembly als CLS-Compliant zu markieren?
CLS-Compliance bedeutet eigentlich "nur", dass die Assembly aus allen .NET-Sprachen heraus angesprochen werden kann, also beispielsweise keine reservierten Wörter einer dieser Sprachen als Methoden-Parameter o.ä. verwendet wurde. Eine Einhaltung der CLS-Compliance ermöglicht es einer größeren Zahl von Entwicklern, die entsprechende Assembly aus ihrer bevorzugten Sprache heraus anzusprechen.
Nun sind bereits zwei der drei Warnungen verschwunden. Die dritte Warnung (CA1824) kann genau so leicht behoben werden. Windows-Forms-Anwendungen besitzen (wie immer auf mein System bezogen) eine Ressourcen-Datei ("Resources.resx"). Diese Ressourcendatei ist nicht mit einer bestimmten Sprache verbunden. Die Design Guidelines empfehlen allerdings, eine Standard-Sprache anzugeben, da somit die Performance beim ersten Suchen der Ressource erhöht werden könne.
Ich bin nicht sicher, ob meine Lösung die richtige ist, aber sie hat die Warnung erfolgreich entfernt und das Programm lässt sich auch weiterhin starten. Ich habe lediglich die folgende Zeile direkt unter die CLS-Compliance-Zeile gesetzt:
[assembly: NeutralResourcesLanguage("de-DE")]Wenn ich diese Anweisung richtig interpretiere, wird die CLR von nun an versuchen, zunächst nach einer deutschsprachigen Ressource zu suchen und diese im Falle der invarianten Sprache als die Standard-Sprache zu verwenden. Ob das aber richtig/sinnvoll ist, weiß ich leider nicht (sobald ich das weiß, werde ich das Ergebnis hier eintragen!).Zusammenfassung
Ehrlich gesagt gibt es ja noch nicht so viel zum Zusammenfassen. Bisher ist eine Entwicklungsumgebung entstanden, die - falls gewünscht - eine oder mehrere Assemblies automatisch auf die Einhaltung der Microsoft Design Guidelines hin überprüft.
Damit ist die IDE schon einen großen Schritt in die richtige Richtung gegangen.
Abschließend sei noch erwähnt, dass die Microsoft Design Guidelines auch vom kostenfrei erhältlichen Tool "Microsoft FxCop" überprüft werden können (für alle, die kein Visual Studio haben).
Subscribe to:
Posts (Atom)
