Open-Source-Software wird meistens als Gratis-Software unter Linux oder mit Java in Verbindung gesetzt. Vielfach geht dabei vergessen, dass es auch im Microsoft-Umfeld sehr viele und qualitativ hochwertige Open-Source-Projekte gibt. Gerade in der Software-Entwicklung werden häufig sogenannte Frameworks eingesetzt, um den Aufwand in der Programmierung zu minimieren. Praktisch jeder Software-Entwickler im Linux- oder Java-Umfeld setzt beispielsweise wie selbstverständlich auf Teilprojekte der Apache Software Foundation. Hingegen ist es interessant, dass Programmierer, die mit .Net auf der Microsoft-Plattform arbeiten, weitgehend auf den Einsatz von Open Source verzichten. Dies rührt oftmals daher, dass die Kombination von Open Source und .Net als Widerspruch angesehen wird, obwohl es sogar eine Open-Source-Implementierung von .Net mit dem Projektnamen Mono gibt.
Dabei bringt der Einsatz von Open Source bei Frameworks viele Vorteile. Jeder Interessierte kann den Source Code herunterladen und beliebig studieren. Dadurch, dass ein Open-Source-Framework nicht nur von den Autoren eingesehen werden kann, sondern auch von Tausenden von Programmierern beim Einsatz überprüft wird, bietet sich ein enorm grosses Potential bei der Qualitätssicherung gegenüber herkömmlichen geschlossenen Produkten. Jedermann hat dadurch die Möglichkeit, Fehler zu entdecken, diese den Autoren zu melden oder gar selber in der Community mitzuarbeiten und Fehler
zu eliminieren. Entgegen vielen Befürchtungen läuft dies aber nie unkontrolliert ab, sondern wird immer durch die Community
gesteuert.
Doch die Frameworks stammen nicht immer von Anfang an aus der Community. Es kann auch passieren, dass aus geschlossenen Projekten einzelne kleine Teilbereiche herausgelöst werden und als Open Source öffentlich und kostenlos zugänglich gemacht werden.
Besonders stark ist diese Bewegung in der Java-Community. Unter den Software-Entwicklern, die Java einsetzen, ist es selbstverständlich, dass Open-Source-Frameworks tagtäglich zum Einsatz kommen. Daher ist es nicht verwunderlich, dass viele Frameworks auch mittlerweile von Java auf die .Net-Plattform portiert und teilweise gar mit plattformspezifischen Eigenheiten erweitert wurden. Nachfolgend wollen wir einige Beispiele vorstellen, die dem einen oder anderen (ehemaligen) Java-Entwickler durchaus bekannt vorkommen dürften.
Log4net ist eine Portierung vom bekannten Java-Logging-Framework log4j und ist mittlerweile auch von der Apache Software Foundation aufgenommen worden. Da praktisch in jedem Projekt Logging-Funktionalität – auch wenn nur zum Debuggen – benötigt wird, ist dieses Framework als Quasistandard zu betrachten. Unter Java wird es schon seit Jahren erfolgreich in praktisch allen Projekten eingesetzt.
Das Spezielle an log4net ist die enorm einfache Anwendbarkeit bei einer ausgesprochen grossen Flexibilität. Dies wird dadurch erreicht, dass das Schreiben von Log-Messages über hierarchische Strukturen realisiert wird und das Verhalten komplett durch die Konfiguration gesteuert werden kann.
Ein einfaches Beispiel, wie der Logger eingesetzt werden kann:
Die grosse Flexibilität von log4net ist durch seine Konfigurierbarkeit bedingt. Es existiert ein sehr umfangreiches Set von sogenannten Appenders, die beliebig erweitert werden können. Ein Appender dient dazu, bestimmte Log-Messages, die praktisch beliebig formatiert werden können, an ein bestimmtes Ziel wie eine Datei oder eine Datenbank zu übergeben. Mittlerweile existieren mehrere Implementierungen, die neben der Übergabe an Datenbanken oder Dateien unter anderem auch Fehlermeldungen an spezielle Logging-Applikationen übergeben können:
• ADONetAppender
• ASPNetTraceAppender
• ConsoleAppender
• EventLogAppender
• FileAppender
• MemoryAppender
• NetSendAppender
• OutputDebugStringAppender
• RollingFileAppender
• SMTPAppender
• TraceAppender
• UdpAppender
• RemotingAppender
Das Bild auf Seite 42 zeigt eine einfache Konfiguration mit zwei verschiedenen Appenders, um Messages direkt auf der Konsole und in einem File auszugeben.
NUnit ist ein Framework, um automatisches Unit-Testing, das ein elementarer Bestandteil des Extreme Programming ist, möglichst einfach und effizient einzusetzen. NUnit stammt ursprünglich ebenfalls aus der Java-Ecke und wurde vom JUnit Projekt abgeleitet, aber in der aktuellsten Version komplett neu aufgesetzt. Durch die vollständig neue Implementierung werden die Vorteile von .Net vollumfänglich in NUnit angewendet. So ist durch den intensiven Einsatz von Attributen die Implementierung automatischer Tests äusserst einfach geworden.
Ein einfacher Test wird gemäss folgendem Beispiel aufgesetzt:
Aus einer ganz anderen Sparte kommt das Dokumentationshilfsmittel NDoc. Mit seiner Hilfe kann auf sehr flexible Weise eine professionelle Dokumentation aus dem Source Code erstellt werden, wie dies Beispielsweise von JavaDoc schon seit langem bekannt ist. Die Dokumentation wird mit XML-Tags direkt in den Source Code als speziell formatierten Kommentar eingefügt. Als Ergebnis spuckt NDoc die Dokumentation in Form einer Windows-Hilfe-Datei (chm) aus, wie sie aus dem MSDN bekannt ist.
Dank dem Einsatz von NDoc steigt auch die Motivation im Team, sauber dokumentierten Source Code zu erstellen. Es vereinfacht dadurch gerade die Zusammenarbeit mit mehreren Entwicklern. Ziel sollte letztlich sein, keine mühselige Dokumentation mehr in einer Textverarbeitung erstellen zu müssen, da diese meistens sowieso schon nach kurzer Zeit veraltet ist.
NAnt ist eigentlich ein Script-Interpreter, um automatisch komplette und auch komplexe Projekte einem Build-Prozess zuzuführen. Aus der Unix-Welt waren die Build-Prozesse schon lange bekannt, sind aber erst nach und nach über Java zu .Net geschwappt. Durch die immer komplexer werdenden Build-Strukturen wurde in Java das Ant Projekt ins Leben gerufen, um über eine XML-Sprache flexible Build-Abläufe festzulegen. NAnt ist eine Portierung der Java-Umsetzung, bietet aber zum aktuellen Zeitpunkt noch nicht den gesamten Funktionsumfang der Originalversion.
Bei der Software-Entwicklung im Team kommen immer mehr Tools zum Einsatz, die die «Continous-Integration» ermöglichen. Mit solchen Tools wird laufend während der Arbeit das komplette Projekt im Hintergrund aus der Versionsverwaltung ausgecheckt, vollständig kompiliert, zum Deployment vorbereitet und dann durch die automatischen Unit-Tests auf Herz und Nieren geprüft. Durch diesen automatischen und dauernden Prozess kommt es nicht mehr vor, dass tagelang Teile entwickelt werden, die am Schluss nicht richtig zusammenpassen. CruiseControl ist eines der möglichen Werkzeuge, um diesen automatischen Prozess auf einfache Weise aufzusetzen.
Adrian Wildermuth (adrian.wildermuth@netiva.ch) ist Mitgründer der Berner Netiva und seit acht Jahren als Consultant und externer Mitarbeiter im Bereich von Architektur, Design und Implementierung von unterschiedlichsten Projekten tätig.
