Das Mono-Projekt wagt den Spagat: Es verbindet eine ursprünglich von Microsoft stammende Technologie, namentlich das .NET-Framework, mit der Welt von Linux. Die Fronten zwischen den Windows-Programmierern und den Anhängern von Linux scheinen sich aufzulösen und der Streit um den Sinn oder Unsinn einen solches Projektes scheint vorerst beendet zu sein. Zeit für die Linux Enterprise-Redaktion, einen ersten Praxistest mit den Mono-Tools zu wagen.
Mit der zunehmenden Popularität von Linux ist auch das Thema Cross-Plattform-Programmierung wieder verstärkt in der Softwarebranche wahrgenommen worden. Zahlreiche Methoden für die Entwicklung plattformunabhängiger Software wurden im Laufe der Zeit entwickelt. Jede hat ihre Vor- und Nachteile. Linux-Programmierer schwören auf ihr ./configure; make, make install, also auf die Kompilierung des Quellcodes auf dem lokalen Rechner. So lässt sich der Code für die jeweilige Plattform optimieren und Inkompatibilitäten werden bereits bei der Installation erkannt. Einen vollkommen entgegen gesetzten Ansatz verfolgt Java. Statt zu Binärcode werden die Programme einmalig zu Bytecode kompiliert und auf dem lokalen Rechner von einer Java Virtual Machine interpretiert. Selbstverständlich bedarf es eines Java-Interpreters für die jeweilige Zielplattform. Ein weiterer Haken sind die teils beträchtlichen Performanceeinbußen.
Lobeshymne auf .NET
Mit der Common Language Infrastructure, die einerseits in Form eines ECMA-Standards vorliegt und andererseits im .NET-Framework umgesetzt wurde, setzt Microsoft ebenso wie der Konkurrent Sun auf eine Virtual Machine. Die .NET-Laufzeitumgebung bringt jedoch für eine bessere Performance einen Just-In-Time-Compiler ins Spiel, der bei Bedarf einzelne Teile des Bytecodes zu Binärcode kompiliert. Ein weiterer Unterschied zu Java: Statt von Bytecode spricht Microsoft von IL-Code und meint damit zwei Dinge auf einmal: Zum einen die einer Assemblersprache ähnliche Intermediate Language und zum anderen eben den Bytecode, der bei der Kompilierung dieser Zwischensprache entsteht.
Die Programmierung unter dem .NET-Framework erfolgt jedoch keineswegs in dieser Zwischensprache. Vielmehr stehen für zahlreiche Programmiersprachen, darunter auch Skriptsprachen wie Perl oder Exoten wie Eiffel, entsprechende Compiler zur Verfügung, die jedoch teils kommerziell vermarktet werden. Frei verfügbar ist hingegen das .NET-Framework SDK, welches neben der .NET Laufzeitumgebung und den .NET-Klassenbibliotheken auch den C#-Compiler
csc beherbergt. Der Nachteil der genannten Compiler: Sie laufen allesamt nur unter Windows.
Obgleich die ECMA-Spezifikation der Common Language Infrastructure eine Portierbarkeit sowohl der Laufzeitumgebung als auch der Klassenbibliotheken vorsieht und Microsoft mit dem Projekt Rotor eine solche Portierung (auf FreeBSD) demonstriert hat, beschränkt sich die Implementierung von .NET auf die Win32-Plattform. Schade, denn das .NET-Framework hat mit seinen zahlreichen Klassen und seiner modernen Architektur - Stichwort Garbage Collector und sprachübergreifende Vererbung - einiges zu bieten.
Danke, Mono!
Ähnlich sahen es wohl die Entwickler der Firma Ximian und riefen vor gut einem Jahr das Projekt Mono und die zugehörige Website www.go-mono.com/ ins Leben. Seitdem haben die knapp hundert Entwickler, darunter zehn Angestellte der Firma Ximian, einiges geschafft: Den freien C#-Compiler
mcs, die unter Windows und Linux lauffähige Laufzeitumgebung
mono, den portierbaren Interpreter
mint und zahlreiche Klassenbibliotheken aus dem Fundus von .NET.
Dass die Arbeit an dem Projekt noch nicht abgeschlossen ist, zeigt die aktuelle Versionsnummer 0.16. Während die Laufzeitumgebung und insbesondere der Compiler schon sehr weit gediehen sind, fehlen den Laufzeitbibliotheken noch zahlreiche Klassen, ganz zu schweigen von den Klassen der Zusatzbibliotheken
WinForms,
ASP.NET und
ADO.NET.
In .NET stellt die WinForms-Bibliothek die grafische Benutzeroberfläche für Windows-Anwendungen. Eine Portierung dieser Bibliothek auf Linux gestaltet sich dementsprechend schwer. Einen Ausweg und eine durchaus akzeptable Alternative bietet das Gtk#-Projekt, welches sich um die Sprachanbindung von Gnome an C# kümmert.
ASP.NET steht für Active Server Pages .NET, obgleich es nur noch wenig mit den bekannten Skript-basierten Active Server Pages zu tun hat. Unter ASP.NET werden sowohl Webseiten als auch Web Services auf Grundlage von Klassen implementiert, die auf Ereignisse wie das Drücken eines Buttons oder den Aufruf einer Web Method reagieren.
Im Zusammenhang mit der Mono-Implementierung von ASP.NET spielt das Tool
xsp eine entscheidende Rolle. Zwar lässt das Akronym an die eXtensible Server Pages des Apache-Servers denken, hat jedoch mit diesen nur im weitesten Sinne etwas gemein. Das ebenfalls im Mono-Paket enthaltene Tool implementiert einen kleinen Web-Server, der zumindest das Testen von eigenen ASP.NET-Anwendungen unter Mono ermöglicht.
Aber auch die Anhänger des populären Apache Servers könnten in Zukunft von Mono profitieren. Mit dem Modul
mod_haydn steht eine Lösung in den Startlöchern, die es erlaubt, IL-Programme im Apache-Server zu hosten. Hierfür wird die Mono-Laufzeitumgebung selbst als Komponente in den Apache-Server geladen.
Schließlich kümmert sich ADO.NET um die Datenanbindung. Glaubt man den Ankündigungen auf der Mono-Website, sollen für die gängigsten Datenbanken bald entsprechende
System.Data-Provider zur Verfügung stehen. Genannt werden unter anderem der
SqlClient für PostgreSQL und später für den Microsoft SQL Server,
OleDb für diverse Datenbanken wie zum Beispiel MySQL oder Oracle und zu guter letzt
Odbc für sämtliche ODBC-Datenquellen.
Frühmorgendliche Installation
Besonders erfreulich unter den vielen täglichen Erfolgsmeldungen, die auf der Mono-Website veröffentlicht werden, war die Freigabe von RPM-Paketen für die Linux-Distributionen von Red Hat, SuSE und Mandrake. Es sind insgesamt vier solcher Pakete erforderlich, die in der nachstehenden Reihenfolge über den Aufruf von
rpm -i zu installieren sind:
libgc,
libgc-develop,
mono-0.16 und
mono-devel-0.16. Für Debian stehen entsprechende DEB-Pakete zur Verfügung.
Windows-Anwender dürfen sich über ein Installationsprogramm freuen, dessen Download-Adresse zusammen mit weiteren Internet-Adressen im Kasten
Links aufgeführt ist. Derzeit findet sich bei der erwähnten Adresse nur ein Setup für die vorherige Version 0.15 von Mono. Außerdem weist das Installationsprogramm einen kleinen Schönheitsfehler auf: Als Installationsverzeichnis schlägt es
C:\mono-0.13 vor. Glücklicherweise bietet das Setup jedoch die Möglichkeit an, diesen Pfad nach Belieben zu ändern.
Für Hartgesottene steht auch der Quellcode zum Download bereit - wahlweise als Source-RPM, als TAR-Archiv oder tagesaktuell über einen anonymen Zugang zu einem CVS-Server. Ein wenig Vereinfachung beim Auschecken und Kompilieren des Quellcodes bieten dabei zwei Skripte - jeweils eines für Linux und eines für Windows.
Entwurf am Vormittag ...
Bei der Programmierung mit dem Mono-Projekt ist es wichtig zu wissen, welche Teile der Klassenbibliotheken bereits implementiert sind und welche nicht. Die Mono-Website gibt unter
Class Status genaue Auskunft zu dem jeweiligen Stand einer Klasse und ihren Methoden und Eigenschaften.
Falls hingegen nur relevant ist, ob eine Klasse überhaupt implementiert wurde oder sich in der Implementierung befindet, genügt ein Blick in die XML-Datei
class.xml. Diese kann von der Mono-Website geladen werden (siehe Link-Kasten) und mit einem einfachen Texteditor geöffnet werden. Komfortabler geht es jedoch mit dem im Folgenden vorgestellten Programm
mcl.exe (für Mono Class List).
Die Aufgabe des Programms ist das Einlesen der XML-Datei über die Standardeingabe oder alternativ über die Angabe des Pfades als Kommandozeilenparameter und die anschließende Ausgabe einer Liste der in der Datei verzeichneten Klassen. Zu jeder Klasse werden die folgenden Daten tabellarisch ausgegeben: Zeitpunkt der letzten Änderung an dem Quellcode der Klasse, zwei Felder mit den Werten
yes oder
no, die entscheiden, ob eine Implementierung beziehungsweise ein Testfall für die Klasse existiert, die Angabe einer Prozentzahl, die Auskunft über den Grad der Fertigstellung gibt sowie der vollständige Name der Klasse, bestehend aus dem Namensraum und dem eigentlichen Klassennamen.
Ignoriert wird dagegen die Angabe der so genannten Maintainer, die für die jeweilige Klasse verantwortlich sind. Diese werden unter ihrer eMail-Adresse in der XML-Datei aufgeführt, werden jedoch aus Platzgründen nicht mit ausgegeben.
... und Programmierung am Nachmittag
Die Programmierung des Tools
mcl.exe erfolgte in C# und mit Hilfe der Mono-Tools. Für den Zugriff auf die XML-Datei wurde die Klasse
XmlTextReader aus der Bibliothek
System.Xml.dll verwendet. Listing 1 zeigt den vollständigen Quellcode des einzigen Moduls
mcl.cs.
Listing 1 using System;
// required for XmlTextReader
using System.Xml;
// MonoClassList reads mono class status-file
// from standard input or from xml-file
// and writes status to standard output.
class MonoClassList
{
static void Main(string[] args)
{
// XmlTextReader for reading mono class status-file
XmlTextReader xtr;
// if argument is passed use it as path for xml-file
// else read from standard input
if (args.Length > 0)
xtr = new XmlTextReader(args[0]);
else
xtr = new XmlTextReader(Console.In);
// name of the current class
String name = "";
// name of the enclosing element
String element = "";
// print column titles
Console.WriteLine("{0,-15}{1,-7}{2,-6}{3,-8}{4}",
"Last-Activity", "Impl.", "Test", "Compl.", "Namespace.Name");
// read all nodes
while (xtr.Read())
{
// distinguish the node types
switch (xtr.NodeType)
{
case XmlNodeType.Element:
// distinguish the element
switch (xtr.Name)
{
case "class":
// store class name
name = xtr["name"];
break;
// store element names
case "last-activity":
case "implementation":
case "test-suite":
case "completion":
element = xtr.Name;
break;
// just do nothing
case "classes":
case "maintainers":
case "maintainer":
element = "";
break;
// throw exception
default: throw new Exception("unknown element");
}
break;
case XmlNodeType.EndElement:
// distinguish the endelement
switch (xtr.Name)
{
// print class name
case "class":
Console.WriteLine(name);
break;
// just do nothing
case "classes":
case "last-activity":
case "implementation":
case "test-suite":
case "completion":
case "maintainers":
case "maintainer":
break;
// throw exception
default: throw new Exception("unknown endelement");
}
break;
case XmlNodeType.Text:
// distinguish the enclosing element
switch (element)
{
case "last-activity":
// print date of last-activity
Console.Write("{0,-15}", xtr.Value);
break;
case "implementation":
// print if there is an implementation
Console.Write("{0,-7}", xtr.Value);
break;
case "test-suite":
// print if there is a test-suite
Console.Write("{0,-6}", xtr.Value);
break;
case "completion":
// print percent state of completion
Console.Write("{0,-8}", xtr.Value);
break;
}
break;
}
}
// close XmlTextReader
xtr.Close();
}
}
Auffällig ist die erste und dritte Zeile des Moduls. Über die Anweisung
using werden zwei Bibliotheken - oder im Sprachgebrauch von .NET zu bleiben, Assemblies - eingebunden:
System für die Klasse
Console und
System.Xml für die Klasse
XmlTextReader. Über die Methoden des
Console-Objektes erfolgt die Eingabe und Ausgabe des Programms.
Das
XmlTextReader-Objekt, welches im Unterschied zum
Console-Objekt explizit erzeugt werden muss, dient hingegen der Verarbeitung der XML-Datei. Dabei orientiert sich der Zugriff auf die XML-Datei an einem Datenstrom, das heißt es kann jeweils nur der aktuelle Knoten in der XML-Datei gelesen werden und sobald ein Knoten gelesen wurde, wird der folgende Knoten angesprungen.
Als Knoten wird jeder Baustein des XML-Dokuments bezeichnet: angefangen bei den öffnenden und schließenden Marken, den reinen Textknoten oder Kommentaren sowie den Attributen. Die
XmlTextReader-Klasse unterscheidet grundsätzlich nicht zwischen den verschiedenen Knotentypen, sondern betrachtet ein XML-Dokument als sequenzielle Folge von XML-Knoten.
Die eigentliche Arbeit findet in der
Main-Methode der
MonoClassList-Klasse statt. Unter C# beziehungsweise unter .NET allgemein muss jedes Programm mindestens eine Klasse mit einer statischen
Main-Methode implementieren. Diese wird beim Start des Programms von der Laufzeitumgebung aufgerufen und ihr wird im Parameter
args die Kommandozeilenparameter übergeben.
Nachdem die XML-Datei entweder über die Standardeingabe oder über den Pfad im ersten Kommandozeilenparameter in das
XmlTextReader-Objekt eingelesen wurde, werden in einer
while-Schleife die Knoten des XML-Dokuments durchlaufen. Letzteres erledigt die
Read-Methode der
XmlTextReader-Klasse. Sie liest den jeweils folgenden Knoten ein und liefert den Wert
False, falls keine weiteren Knoten mehr vorhanden sind.
Mittels mehrerer verschachtelter
switch-Abfragen wird in der
while-Schleife der jeweilige Knotentyp sowie der Name des aktuellen Elements unterschieden und eine entsprechende Aktion durchgeführt. Für den Zugriff auf den Knotentyp, den Knotennamen und den Knotenwert stellt die
XmlTextReader-Klasse die Eigenschaften
NodeType,
Name und
Value bereit.
Attribute werden dagegen von der
Read-Methode nicht berücksichtigt. Sie müssen explizit über die
Item-Eigenschaft der
XmlTextReader-Klasse unter Angabe eines Indizes oder des Attributnamens abgefragt werden. Da es sich bei der
Item-Eigenschaft um den so genannten Indexer der
XmlTextReader-Klasse handelt, kann der Zugriff zum Beispiel auf das
name-Attribut des
class-Elements wie im Falle eines Arrays erfolgen:
name = xtr["name"];
Die ursprüngliche Implementierung des Programms
mcl sah vor, für den Zugriff auf den Inhalt eines Textelements die Methode
ReadElementString zu verwenden. Trifft beispielsweise die
Read-Methode auf das Element
no oder genauer auf die öffnende Marke
<test-suite>, so würde ein Aufruf von
ReadElementString die Zeichenfolge
no liefern und anschließend zur schließenden Marke
</test-suite> springen. Da diese sehr praktische Methode jedoch in den Mono-Bibliotheken noch nicht implementiert wurde, musste eine andere Lösung gefunden werden.
Zwar ist der Wert eines Textknotens auch über die
Value-Eigenschaft zugänglich, jedoch fehlt dann die Information über das umschließende Element und das jeweilige Programm kann nicht entscheiden, welche Daten der Textknoten beherbergt. In Folge dessen muss der Name des aktuellen Elements an geeigneter Stelle, nämlich beim Lesen der öffnenden Marke, in einer Variablen gespeichert werden und beim Lesen der schließenden Marke wieder gelöscht werden. Trifft die
Read-Methode zwischenzeitlich auf einen Textknoten, kann anhand der genannten Variablen entschieden werden, welche Daten zu erwarten sind und wie sie auszugeben sind.
Tool Time
Es ist nun an der Zeit den Mono C#-Compiler
mcs aus der Werkzeugkiste hervorzuholen und die Quellcodedatei
mcl.cs zu kompilieren. Der hierfür erforderliche Befehl lautet:
mcs -o bin/final/mcl.exe mcl.cs
Das Tool
mcs kennt eine Reihe von Kommandozeilenparametern, die über den Schalter
--help abgefragt werden können. Die im obigen Beispiel verwendeten Parameter sind im einzelnen
-o für die Ausgabedatei und zu guter letzt das oder gegebenenfalls die zu kompilierenden Module. Der Parameter
-o ist wie alle Schalter des Compilers optional. Per Standardeinstellung wird die kompilierte EXE-Datei im selben Verzeichnis angelegt, in dem sich auch die Quellcodedatei befindet.
Zwei weitere wichtige Schalter sind
-r und -
target. Mittels
-target kann bestimmt werden, ob der Quellcode zu einer EXE- oder einer DLL-Datei kompiliert werden soll. Um zum Beispiel aus der Datei
mcl.cs ein Assembly zu generieren, ist folgender Aufruf von
mcs erforderlich:
mcs -target:library mcl.cs
Zusätzliche Assemblies, die das Programm benötigt, können mittels
-r spezifiziert werden. In früheren Versionen des Compilers
mcs war es beispielsweise notwendig, das Assembly
System.Xml.dll wie folgt manuell einzubinden:
mcs -r System.Xml -o bin/final/mcl.exe mcl.cs
In der aktuellen Version erfolgt die Referenzierung automatisch bei der Kompilierung und anhand der eben besprochenen
using-Anweisung, die in diesem Fall auf ein bekanntes Assembly verweist. Sollte der Compiler bei einem unbekannten Assembly einmal meckern, so hilft die Angabe von
-r.
Bei dem zweiten Tool aus dem Werkzeugkasten handelt es sich um das Programm
mono, welches die Laufzeitumgebung für die Ausführung der IL-Programme stellt. Obgleich die mit
mcs kompilierten Dateien die Endung
EXE tragen, können sie nicht eigenständig ausgeführt werden. Es bedarf hierzu des Aufrufes von
mono wie folgt:
mono bin/final/mcl.exe bin/final/class.xml
Alle Kommandozeilenparameter, die dem eigentlichen Programmnamen (hier
mcl.exe) folgen, werden unverändert an das jeweilige Programm übergeben und landen schließlich in dem bereits bekannten Zeichenfolgenarray
args der
Main-Methode. Vor der Parameterübergabe sorgt der Just-In-Time-Compiler für die Kompilierung der
Main-Methode, sodass deren Code direkt auf dem Prozessor läuft.
Im Unterschied hierzu wird bei dem Tool
mint der IL-Code eines Programms nur interpretiert. Dies hat teils beträchtliche Performanceeinbußen zur Folge, die insbesondere dann zum Tragen kommen, wenn eine Prozedur oder eine Schleife mehrmals durchlaufen wird.
Der Aufruf des Mono-Interpreters unterscheidet sich von dem der Mono-Laufzeitumgebung nur durch den Programmnamen:
mint bin/final/mcl.exe bin/final/class.xml
Nächtliche Fehlersuche
Ein Tool fehlt im Mono-Werkzeugkasten noch: der Debugger. Zwar wurde ein solcher angekündigt, aber bisweilen sind auf der Website des Mono-Projektes nur zwei Screenshots des grafischen Debuggers zu sehen. Immerhin findet sich auf der Website eine Anleitung zum Einsatz des bekannten Debuggers
gdb. Da jedoch der
gdb keinen IL-Code kennt, können die IL-Programme nicht direkt in den Debugger geladen werden. Statt dessen ist die Mono-Laufzeitumgebung in den Debugger zu laden.
Als erstes ist es notwendig, den binären IL-Code in eine lesbare Form zu übersetzen, mit anderen Worten zu disassemblieren. Das entsprechende Tool trägt den Namen
monodis und gibt den rückübersetzten (IL-)Assemblercode direkt auf die Standardausgabe aus. Mit Hilfe des Umleitungsoperator kann dieser in eine Datei mit der Endung
il geschrieben werden.
Da die Disassemblierung für sämtliche beteiligten Assemblies stattfinden muss, empfiehlt es sich ein
makefile anzulegen und dort die Aufrufe für den Compiler und den Disassembler vorzunehmen. Listing 2 zeigt die entsprechende Datei für das Programm
mcl. Dessen Kompilierung erfolgt nun über
make debug.
Listing 2 final:
mcs -r System.Xml -o bin/final/mcl.exe mcl.cs
debug:
mcs -r System.Xml -o bin/debug/mcl.exe mcl.cs
monodis /usr/local/lib/corlib.dll > bin/debug/corlib.il
monodis /usr/lib/System.Xml.dll > bin/debug/System.Xml.il
monodis /usr/lib/System.dll > bin/debug/System.il
monodis bin/debug/mcl.exe > bin/debug/mcl.il
Um anschließend die Mono-Laufzeitumgebung in den Debugger zu laden, sollte zuerst in das Ausgabeverzeichnis (in diesem Fall
bin/debug) gewechselt werden und dort der
gdb über den folgenden Befehl gestartet werden:
gdb /usr/bin/mono
Als nächstes wird die Mono-Laufzeitumgebung im Debugger über den Befehl
r(un) zur Ausführung gebracht und ihr dabei das eigentlich zu testende Programm übergeben:
(gdb) r --debug=dwarf --break MonoClassList:Main mcl.exe class.xml
Der Schalter
--break sorgt dafür, dass die Laufzeitumgebung die Programmausführung unterbricht, sobald die im Argument angegebene Methode aufgerufen wird. Die Angabe einer Methode verlangt sowohl die Nennung eventueller Namensräume als auch die des Klassennamens.
Schließlich teilt der Schalter
--debug der Laufzeitumgebung mit, die Symboldateien im Format
dwarf zu erzeugen. Letzteres erfolgt jedoch erst durch den expliziten Aufruf der Funktion
mono_debug_make_symbols. Für Funktionsaufrufe innerhalb des zu testenden Programms sieht der
gdb den Befehl
call vor. Und um die von der Mono-Laufzeitumgebung erzeugten Symboldateien zu laden, ist der Befehl
add-symbol-file unter Angabe des entsprechenden Pfades auszuführen:
(gdb) call mono_debug_make_symbols()
(gdb) add-symbol-file mcl.exe.o
Das Gröbste ist nun überstanden und der
gdb kann wie gewohnt verwendet werden. Mit dem Befehl
info locals können die aktuellen Variablenwerte abgefragt werden und mit
n(ext) die nächste Befehlszeile zur Ausführung gebracht werden. Da der IL-Code jedoch rückübersetzt wurde, fehlen nicht nur jegliche Variablennamen, auch auf Kommentare muss verzichtet werden und statt elegantem C#-Code ist Assemblercode angesagt:
(gdb) info locals
V_0 = (XmlTextReader *) 0x0
...
(gdb) n
55 IL_000b: newobj instance void class [System.Xml]System.Xml.XmlTextReader::.ctor(string)
Seitensprünge
Nach der erfolgreichen Kompilierung und Ausführung unter Linux stellt sich die Frage nach der Ausführbarkeit des Programms unter Windows. Und tatsächlich, das Programm
mcl.exe kann ohne Neukompilierung unter Windows gestartet werden, allerdings nur mit Hilfe der Mono-Laufzeitumgebung. Sofern das am Anfang des Beitrags erwähnte Windows-Setupprogramm installiert wurde, erfolgt der Start der Mono-Laufzeitumgebung über die Stapelverarbeitungsdatei
mono.bat:
mono.bat bin\debug\mcl.exe bin\debug\class.xml
Ebenso ist eine erneute Kompilierung unter Windows möglich. Allerdings lautet der Befehl dann
mcs.bat. Schließlich kann die C#-Datei auch mit dem Programm
monomcs wie folgt kompiliert werden:
monomcs.bat -o bin\debug\mcl.exe mcl.cs
Bei dieser Kompilierung werden unter Windows anstelle der Mono-Laufzeitbibliotheken die .NET-Laufzeitbibliotheken verwendet. Dennoch kann das Programm auch weiterhin unter Linux ausgeführt werden. In diesem Fall greift die Mono-Laufzeitumgebung auf ihre eigenen Bibliotheken zurück. Das Unterjubeln der Mono-Laufzeitbibliotheken funktioniert selbst dann, wenn das Programm nicht mit dem Mono C#-Compiler, sondern zum Beispiel mit dem C#-Compiler von Microsoft oder einem anderen IL-Compiler kompiliert wurde.
Fazit
Die Programmierung mit den Mono-Tools ist noch sehr zeitaufwändig. Es fehlen vor allem eine vollständige Dokumentation und ein vernünftiger Debugger. Erschwerend kommt hinzu, dass erst bestimmte Teile der Klassenbibliotheken von .NET fertig gestellt sind. Eine Kompatibilität zum .NET-Framework ist zumindest beim derzeitigen Stand der Bibliotheken folglich nicht gegeben. Doch die Entwickler von Ximian und die zahlreichen freien Entwickler arbeiten fleißig an der Vervollständigung des Mono-Projektes. Währenddessen entwickelt Microsoft bereits die zweite Version von .NET. Unerwartete Unterstützung erhielt die Mono-Gemeinde jedoch von ihrem Maskottchen, dem Code Monkey. Wer mehr über dieses Arbeitstier wissen möchte, sei am Ende dieses Beitrags noch auf die folgende URL verwiesen:
developer.ximian.com/projects/third_party/codemonkey/.
Links
Hat Ihnen dieser Artikel gefallen? Dann abonnieren Sie das Entwickler Magazin direkt über unser
