6 Projektmanagement und Visual Studio 2008

6.1 Der Projekttyp »Klassenbibliothek«

Insbesondere in den Kapiteln 3 und 4 haben wir mit CircleApplication eine etwas größere Anwendung entwickelt, die zuletzt mit Circle, GraphicCircle, Rectangle, GraphicRectangle und GeometricObject fünf Klassen enthielt. Zur Erinnerung: Anhand dieser Klassen habe ich Ihnen die wesentlichen Aspekte der objektorientierten Programmierung gezeigt.

Alle Klassen sind auf Grundlage der Projektvorlage einer Konsolenanwendung entwickelt worden. Das Kompilat ist eine EXE-Datei. Denken wir nun einen Schritt weiter, und nehmen wir an, die Klassen seien so genial, dass wir sie auch in anderen Anwendungen benutzen wollen. Abwegig ist der Gedanke nicht, denn immerhin sind unsere geometrischen Objekte fähig, sich selbst in einer grafischen Benutzeroberfläche zu zeichnen.

Auf die in einer EXE-Datei enthaltenen Typdefinitionen, also Klassen, Strukturen, Delegates usw. kann aber aus anderen Anwendungen heraus grundsätzlich nicht zugegriffen werden. Dazu müssen die zu veröffentlichenden Typen in einer Datei implementiert sein, deren Kompilat die Dateiendung DLL hat. Diese .NET-Kompilate werden auch als Assemblys bezeichnet.

Es gibt eine Reihe von Projektvorlagen, die diese Bedingung erfüllen. Im Moment kommt für uns aber nur eine in Betracht, nämlich die Projektvorlage Klassenbibliothek. Eine Klassenbibliothek wird zu einer DLL-Datei kompiliert und ist somit auch nicht eigenstartfähig. Versuchen Sie dennoch, das Projekt einer Klassenbibliothek aus der Entwicklungsumgebung heraus zu starten, erhalten Sie eine Fehlermeldung. Sie können jedoch weiterhin das Klassenbibliotheksprojekt über das Menü Erstellen kompilieren.

Normalerweise werden Sie schon von Anfang an die Überlegung anstellen, ob Sie Ihre zu entwickelnden Klassen in einer Klassenbibliothek bereitstellen wollen oder in einer anderen Projektvorlage. Da wir aber anfangs mit einer Konsolenanwendung angefangen haben, müssen wir unsere fertigen Klassen nun in einer Klassenbibliothek unterbringen. Hierbei gibt es mehrere Möglichkeiten:

• Klicken Sie im Projektmappen-Explorer auf den Knoten Properties. Es öffnet sich daraufhin das Projekteigenschaftsfenster. Wählen Sie hier die Lasche Anwendung aus, und stellen Sie im Listenfeld Ausgabetyp den gewünschten Projekttyp ein, also Klassenbibliothek. Das Kompilat ist anschließend eine DLL. In diesem Fall können Sie die Klasse Program mit der Startmethode Main löschen.

• Erstellen Sie ein neues Projekt vom Typ Klassenbibliothek, und löschen Sie die standardmäßig bereitgestellte Datei Class1.cs. Markieren Sie danach das Projekt im Projektmappen-Explorer, öffnen Sie dann das Kontextmenü und wählen Sie Hinzufügen • Vorhandenes Element. Navigieren Sie danach zu den Quellcodedateien der Klassen, die Sie allen Anwendungen zur Verfügung stellen wollen.

6.1.1 Mehrere Projekte in einer Projektmappe verwalten

Bisher haben wir in der Entwicklungsumgebung immer nur mit einem Projekt gearbeitet. Visual Studio ermöglicht aber auch, mehrere Projekte gleichzeitig parallel zu bearbeiten. Verwaltet werden die einzelnen Projekte in einer Projektmappe, die die Aufgabe eines Containers hat. Das Visual Studio generiert beim Erstellen eines neuen Projekts eine Projektmappe, die anschließend um praktisch beliebig viele, auch unterschiedliche Projekttypen erweitert werden kann. Damit erübrigt sich das mehrfache Öffnen des Visual Studios, wenn mehrere Projekte gleichzeitig bearbeitet werden sollen. Die von einer Projektmappe verwalteten Projekte können in einem logischen Zusammenhang stehen, müssen es aber nicht zwangsläufig.

Auch Projektmappen haben einen spezifischen Bezeichner. Dieser kann vergeben werden, sobald Sie die Entwicklungsumgebung starten und ein neues Projekt erstellen. Sollten Sie im Projektmappen-Explorer keinen Knoten für die Projektmappe sehen, öffnen Sie das Menü Extras und wählen Optionen. Im Dialog, der daraufhin geöffnet wird, wählen Sie in der linken Liste den Knoten Projekte und Projektmappen aus und unter diesem den Unterpunkt Allgemein. Im rechten Bereich des Dialogs wird Ihnen daraufhin eine Option angeboten, die Projektmappe immer anzuzeigen.

Der Standardbezeichner einer Projektmappe ist der des ersten Projekts, sollte allerdings insbesondere dann einen spezifischen Namen bekommen, wenn Sie wissen, dass Sie im Laufe der Entwicklungstätigkeit mindestens noch ein weiteres Projekt hinzufügen wollen.

Um die Entwicklungsumgebung um ein weiteres Projekt zu ergänzen, müssen Sie im Projektmappen-Explorer den Knoten der Projektmappe markieren, dessen Kontextmenü öffnen und Hinzufügen • Neues Projekt... auswählen. Daraufhin öffnet sich ein Dialog, der alle Projekttypen zur Auswahl stellt.

Mit diesen Kenntnissen ausgestattet, sollten wir ein komplett neues Projekt gestartet haben, dessen Projektmappe den Namen GeometricObjectsSolution trägt. In der Projektmappe befinden sich eine Klassenbibliothek, die nun GeometricObjects heißt, und eine Konsolenanwendung namens TestApplication. Danach könnte die Ansicht im Projektmappen-Explorer so aussehen wie in Abbildung 6.1.

Werden von einer Projektmappe mehrere Projekte verwaltet, kann nur eines davon ausgeführt werden, wenn man auf die Schaltfläche Starten in der Symbolleiste von Visual Studio klickt. Es ist immer das Projekt, dessen Projektbezeichner fett geschrieben ist. In Abbildung 6.1 würde es sich demnach um das Projekt GeometricObjects, also die Klassenbibliothek handeln und zu einer Fehlermeldung führen. Um ein anderes Projekt zum Startprojekt zu erklären, müssen Sie das Kontextmenü des entsprechenden Projekts öffnen und Als Startprojekt festlegen auswählen.

Abbildung 6.1 Projektmappe mit einer Klassenbibliothek

Physikalisch werden die beiden Projekte GeometricObjects und TestApplication als Unterordner des übergeordneten Ordners der Projektmappe GeometricObjectsSolution gespeichert. In Letzterem sind zwei Dateien mit den Dateierweiterungen .SLN und .SUO zu finden. In der SLN-Datei sind die Daten enthalten, die die Projektmappe definieren, und in der SUO-Datei die Daten, mit denen die Entwicklungsumgebung entsprechend der ausgewählten Optionen angepasst wird.

6.1.2 Die Zugriffsmodifizierer »public« und »internal«

Klassen können sowohl als public wie auch als internal definiert sein. public bedeutet, dass die so gekennzeichnete Komponente überall sichtbar ist. In einer Konsolenanwendung eine Klasse nicht mit public zu kennzeichnen, hat keine besonderen Auswirkungen, denn alle Definitionen innerhalb einer Konsolenanwendung sind nicht veröffentlichungsfähig. Gewissermaßen geben wir dann der Klasse Fähigkeiten mit auf den Lebensweg, die sie niemals ausnutzen kann. In Projekten, deren Kompilat eine EXE-Datei ist, können wir daher auf public verzichten. Die Klasse gilt dann implizit als internal, was bedeutet, dass sie nur in der aktuellen Anwendung bekannt ist. Natürlich gilt diese Aussage auch bei allen anderen Typdefinitionen.

public hat jedoch eine besondere Bedeutung innerhalb einer Klassenbibliothek, denn damit teilen wir dem Compiler unsere Absicht mit, dass auch Anwendungen außerhalb der Klassenbibliothek auf diese Klasse zugreifen dürfen. Der Verzicht auf die Angabe von public bedeutet, dass die Typdefinition außerhalb der Klassenbibliothek nicht bekannt ist. Dies ist gleichbedeutend mit dem ausdrücklichen Setzen des Zugriffsmodifizierers internal.

6.1.3 Friend Assemblys

Um den Zugriff auf die Mitglieder einer Assembly von einer zweiten Assembly aus sicherzustellen, muss neben der Klasse auch das Mitglied public deklariert sein. Der Zugriffsmodifizierer internal einer Klasse macht die Klasse innerhalb einer Assembly zugreifbar, sie ist aber außerhalb der Assemblierung nicht zu sehen. Dasselbe gilt auch für die Member einer Klasse.

Um eine noch bessere Steuerung des Zugriffs zu ermöglichen, gibt es Assemblierungen, die ihre internal-Klassen und Mitglieder nur ganz bestimmten Assemblierungen zur Verfügung stellen. Sehen Sie sich dazu das folgende Beispiel der Klasse ClassA an:

namespace ClassLibrary { 
  class ClassA { 
    internal void TestMethod() { 
      Console.WriteLine("In der Friend-Assembly"); 
    } 
  } 
}

Da die Klasse über keinen Zugriffsmodifizierer verfügt, gilt sie per Vorgabe als internal. Andere Klassen, die sich innerhalb derselben Assemblierung befinden, sehen die Definition von ClassA und können darauf zugreifen. Bindet jedoch ein Client die Assemblierung ein, erfährt er nichts von der Existenz des Typs ClassA.

Nehmen wir an, wir wollten nun den Typ ClassA einer ganz bestimmten Anwendung zur Verfügung stellen. Deren Name sei ConsoleAppliction. Wir müssen diese nur zu einer Friend Assembly heraufstufen, so dass sie die Ausnahme von der Regel darstellt.

Dazu muss die Assemblierung, in der ClassA definiert ist, mit dem Attribut InternalsVisibleTo verknüpft werden. Dem Attribut wird ein Zeichenfolgeparameter mit dem Namen der Assemblierung übergeben, für die alle nicht öffentlichen Typen sichtbar gemacht werden sollen.

[assembly:InternalsVisibleTo("ConsoleApplication")] 
namespace ClassLibrary { 
  class Class1 {... } 
}

Das Attribut gehört zum Namespace System.Runtime.CompilerServices, der mit using bekannt gegeben werden sollte. Gesetzt wird der Eintrag in der Datei AssemblyInfo.cs.

6.1.4 Einbinden einer Klassenbibliothek

Uns liegen nun mit TestApplication und GeometricObjects zwei Projekte in der Projektmappe vor. Sollten Sie sich den Beispielscode auf der Buch-DVD ansehen, werden Sie feststellen, dass ich den Namespace aller Typdefinitionen in der Klassenbibliothek von CircleApplication in GeometricObjectLibrary umbenannt habe. Ich finde, dieser Bezeichner passt besser.

TestApplication dient dazu, die nun vorliegende Klassenbibliothek GeometricObjects zu testen. Allerdings weiß die Konsolenanwendung noch nicht, dass die Klassenbibliothek existiert. Das müssen wir zuerst sicherstellen. Dazu dient der Knoten Verweise im Projektmappen-Explorer. Im Kontextmenü dieses Knotens wählen Sie Verweis hinzufügen.... Daraufhin öffnet sich der in Abbildung 6.2 gezeigte Dialog mit den Registerkarten .NET, COM, Projekte, Durchsuchen und Aktuell.

Abbildung 6.2 Der Dialog »Verweise«

Bezogen auf die uns vorliegende Projektmappe GeometricsObjectSolution ist es am einfachsten, die Registerkarte Projekte auszuwählen, da wir hier sofort die Klassenbibliothek GeometricObjects angeboten bekommen.

Jetzt haben wir in der Anwendung Zugriff auf die öffentlichen Elemente in GeometricObjects und können beispielsweise die Klasse Circle instanziieren. Dabei müssen wir aber auch den Namespace, in dem Circle definiert ist, berücksichtigen. Entweder geben wir den voll qualifizierenden Bezeichner an, beispielsweise

GeometricObjectsLibrary.Circle kreis = new GeometricObjectsLibrary.Circle();

oder – was eine deutlich bessere Lösung ist – wir geben den Namespace mit using vorher bekannt und können direkt die Klasse ansprechen:

using GeometricObjecstLibrary; 
... 
Circle kreis = new Circle();

Ihr Kommentar