Keine Monokultur

Microsoft will mit .Net sein in die Jahre gekommenes Component Object Model ablösen und gleichzeitig eine Alternative zu Java/J2EE anbieten. Damit ist .Net für Microsoft auf unabsehbare Zeit die entscheidene Basis für die Windows-Softwareentwicklung. Im Kasten „Die Bestandteile des .Net-Baukastens“ ist das Zusammenwirken der einzelnen Bausteine der .Net-Technologie beschrieben.

Die Freigabe des .Net-Codes für andere Plattformen hat Microsoft im Rahmen der Standardisierung bei ECMA und ISO allerdings nur halbherzig betrieben. Mit ASP.Net (Webentwicklung), ADO.Net (Datenbankzugriff) und Windows Forms (Desktop-Oberfläche) fehlen zentrale Bausteine des Framework im Standard und in der zugehörigen Referenzimplementierung „Shared Source Common Language Infrastructure“ (alias Rotor), die Microsoft primär zu Forschungszwecken bereit stellt. Auch bei der Auswahl von Mac OS und FreeBSD als Portierungsplattformen für Rotor sind politische Gründe zu unterstellen.

Nun ist das Mono-Projekt angetreten, eine echte plattformunabhängige Open-Source-Implementierung von .Net zu schaffen. Dieses Projekt hat Miguel de Icaza im Jahre 2001 ins Leben gerufen, zu dem Zeitpunkt bekannt als treibende Kraft beim Gnome Desktop, dem Konkurrenten von KDE. Im August 2003 akzeptierte er mit seiner zwischenzeitlich gegründeten Firma Ximian ein Übernahmeangebot von Novell, die sich später mit Suse eine weiteres erfahrenes Open-Source-Haus zulegte.

Offiziell bezeichnet Novell Mono als „eine .Net-Implementierung basierend auf den ECMA-Standards für die Programmiersprache C# und die Common Language Infrastructure“. Tatsächlich geht Mono in der aktuellen stabilen Version 1.0.5 weit über die lückenhaften Standards hinaus. Neben den standardisierten Teilen unterstützt Mono zusätzlich ADO.Net und ASP.Net. Die für die Entwicklung von klassischen grafischen Benutzerschnittstellen notwendigen Windows Forms sind hingegen noch in einem sehr frühen Entwicklungsstadium. Die Tabelle „Weiterreichende Klassenbibliotheken“ listet auf, dass Mono zudem Programmierschnittstellen für spezielle Anwendungsgebiete aus der Welt von Linux und Ximian/Novell anbietet. Wie sich der Initiator die Weiterentwicklung von Mono vorstellt, ist im Interview mit Miguel de Icaza auf Seite 47 nachzulesen.

Weiterreichende Klassenbibliotheken von Mono
Bezeichnung	Bedeutung
Apache Mono	Unterstützung des Apache Webservers als Frontend für ASP.Net
Mozilla	Verwendung des Mozilla Browsers in .Net/Mono-Applikationen
ByteFX.Data.dll	ADO.Net Managed Data Provider für MySQL
Mono.Data.SybaseClient.dll	ADO.Net Managed Data Provider für Sybase
Mono.Data.SqliteClient.dll	ADO.Net Managed Data Provider für Sqllite
IBM.Data.DB2	ADO.Net Managed Data Provider für DB2
Npgsql.dll	ADO.Net Managed Data Provider für Postgres
SharpZipLib.dll	ZIP-Algorithmus zum Ver- und Entpacken (aus dem SharpDevelop-Projekt)
Novell.Directory.Ldap.dll	LDAP-Implementierung
Gnome#	GUI-Klassen
GTK#	GUI-Klassen
iFolder	Novell File Sharing-Lösung
Java Kompatibilität	IKVM.Net-Laufzeitumgebung zur Interoperabilität mit Java-Programmen
Commons.Xml.Relaxng.dll	XML-Reader und -Validator für RelaxNG
NUnit	Unterstützung für Unit Testing mit NUnit

Novell liefert derzeit Mono-Distributionen für die Linux-Varianten Suse, Red Hat, Fedora und Novell sowie für Mac OS X und Windows. Pakete für andere Unix-Derivate sind geplant, aber derzeit noch nicht verfügbar. Zudem kann sich ein erfahrender Anwender jederzeit sein eigenes Mono aus den frei verfügbaren Quelltexten bauen. Der für die Ausführung der Common Intermediate Language notwendigen Just-in-Time-Compiler oder Interpreter (mint) existiert für x86, ia64, PPC, S390, HPPA, StrongARM und Sparc. Eine erwähnenswerte Alternative stellt die Monoppix-Distribution dar. Aufbauend auf Knoppix bringt diese von CD startbare Linux-Variante ein komplett vorinstalliertes und konfiguriertes Mono mit.

Ungleiche Geschwister, fehlende Grundlagen

Für die Beurteilung der Kompatibilität stellen sich zwei zentrale Fragen.

• Lassen sich unter Windows kompilierte .Net-Applikationen durch einfaches Kopieren unter Mono ausführen?
• Lässt sich .Net-Quellcode unter Mono neu kompilieren und damit weiterentwickeln?

Für Mono 1.0.5 kann man beide Fragen positiv beantworten, zumindest für Anwendungen, die sich ausschließlich der .Net-Assemblys mscorlib, System, System.Data, System.Configuration.Install, System.Net, System.Xml, System.Web, System.Web.Services, System.Drawing, System.DirectoryServices, System.Runtime.Remoting und System.Security bedienen. Viele andere .Net-Assemblys sind hingegen in der Mono-Welt nicht vorhanden. Neben den bereits genannten Windows Forms fehlen andere zentrale Klassen aus dem .Net Framework, zum Beispiel die von .Net-Entwicklern gleichermaßen bewunderte wie gefürchtete „Code Access Security“ (CAS). Die Tabelle „In Mono fehlende .Net-Bestandteile“ zeigt eine Liste aller offensichtlichen Unterschiede zwischen Mono und .Net.

Der Grund für das Fehlen von Funktionen ist in vielen Fällen, dass unter den verwalteten .Net-Schnittstellen Windows-eigene Techniken oder gar Microsoft-Produkte liegen. Hier mussten die Mono-Entwickler für andere Plattformen eigene Wege gehen. So basiert der Verzeichnisdienstzugriff mit der System.DirectoryServices.dll auf Novell.Directory.Ldap.dll, statt auf Microsofts Active Directory Service Interface (ADSI). Das Zeichnen greift unter .Net auf Microsoft GDI+ zu. Unter Linux haben die Mono-Schöpfer eine GDI+-konforme API entwickelt, die im Inneren die freie Vektorgrafikbibliothek Cairo verwendet. Cairo kann der Entwickler auch direkt über die Mono.Cairo.dll aus Managed Code heraus ansprechen.

Andere Teile der .Net-Klassenbibliothek sind nur in Rümpfen oder gar nicht vorhanden, weil es kein geeignetes Äquivalent auf anderen Plattformen gibt. Die System.Management.dll, der Managed-Code-Wrapper für die „Windows Management Instrumentation“ (WMI), ist zwar vorhanden, aber nicht einmal ansatzweise implementiert und liefert daher bei jedem Methodenaufruf eine System.NotImplementedException. WMI basiert zwar auf dem „Web-based Enterprise Management Standard“ (WBEM); dieser ist jedoch unter Unix/Linux noch nicht verbreitet.

Unmanaged Code auch unter Mono

Ebenfalls nur in Form von Funktionsrümpfen vorhanden ist die Sytem.Messaging.dll für den Zugriff auf Microsofts Message-Queuing-Dienste. In diesen DLLs findet sich jeweils die Definition eines MonoTODOAttribut, das alle unvollständigen Mitglieder besitzen. Die Existenz dieses Attributes ist übrigens ein sicherer Hinweis auf eine unvollständige Implementierung, wobei MonoTODOAttribut nicht immer im gleichen Namensraum liegt (zum Beispiel System.MonoTODO- und System.Management.MonoTODO-Attribute). Gar nicht verfügbar sind die .Net Enterprise Services, die Redmonder Ausführung eines Application Servers mit Diensten wie verteilten Transaktionen und Objekt-Pooling.

Zugriff auf nicht verwalteten Code gibt es auch unter Mono, aufgrund des Fehlens des „Component Object Model“ (COM) als Komponentensammlung beschränkt sich diese Interoperabilität auf die „Platform Invoke Services“ (P/Invoke), um Code in C-Bibliotheken nutzen zu können. P/Invoke ist Chance und Fluch zugleich, denn die Portierbarkeit geht verloren bei der Verwendung nativer Bibliotheken. Wenn eine Windows-Anwendung per P/Invoke auf Funktionen aus der Win32-API zugreifen muss, weil es dafür keine Entsprechung in der .Net-Klassenbibliothek gibt, hagelt es auf anderen Plattformen Fehler. Diese Problematik muss man beim Entwurf und bei der Realisierung von .Net-Applikationen immer im Hinterkopf behalten.

Zum Mono-Kern gehören bislang weder eine grafische Entwicklungsumgebung noch ein leistungsfähiger Debugger. Hoffnungsträger ist hier MonoDevelop, eine experimentelle Portierung der Open-Source-.Net-Entwicklungsumgebung SharpDevelop. Auch wenn diese IDE bei weitem nicht an das Visual Studio heranreicht, lässt das frühe Stadium erahnen, was alles mit MonoDevelop (Abbildung 1) möglich sein wird. Ein Eclipse-Plug-in ist noch nicht in Sichtweite. Zurzeit müssen Entwickler, die mehr als einen reinen Texteditor erwarten, Windows als Plattform für ihr Entwicklungssystem benutzen.

Den vollständigen Text inklusive eines Interviews mit Monos Projektleiter, Miguel de Icaza, finden Sie in der aktuellen Print-Ausgabe der iX.

Mehr Infos

iX-TRACT

• Mit Mono existiert eine quelltextoffene Implementierung von .Net für Linux, andere Unix-Derivate und Windows.
• Mono umfasst bereits heute viele Teile der .Net-Klassenbibliothek und ergänzende Managed-Code-Bibliotheken.
• ASP.Net-Lösungen lassen sich fast ohne Änderungen nach Mono migrieren.
• Anwendungen, die auf Windows Forms basieren, können sinnvoll erst mit der kommenden Mono-Version portiert werden.

(wm)