Vorheriger Artikel Nächster Artikel

.NET als Open Source: Mono

Aus dem
t3n Magazin Nr. 4

06/2006 - 08/2006

Die Bildverwaltungssoftware F-Spot ist eine bekannte Gtk#-Anwendung – hier läuft sie auf einem GNOME-Desktop.

Kompilierte Webanwendungen in einer modernen zu hosten, bedeutet nicht mehr zwingend, Java einsetzen zu müssen. Nach einigen Jahren der hat Mono die notwendige Reife, ASP.Net-Seiten auf praktisch jeder Plattform ausführen zu können. Darüber hinaus bietet es eine moderne Umgebung ohne unnötigen Ballast. Mono hat das Zeug dazu, eine der Hauptentwicklungsplattformen im Open-Source-Bereich zu werden.

Mono ist die Open-Source-Umsetzung des Microsoft .Net-Frameworks. Um Mono zu verstehen, muss daher zunächst der von Microsoft ursprünglich verfolgte Ansatz erläutert werden. Microsoft hatte sich mit der Entwicklung von .NET zweierlei Ziele gesetzt: Zum einen sollte das bekannte COM-Komponente-Framework ersetzt und zum anderen ein Gegenentwurf zu Suns Java-Plattform geschaffen werden. Zunächst hatte Microsoft, mangels einer Alternative zu Java, von Sun entsprechende Lizenzen erworben und ein Paket mit dem Namen J++ geschnürt. J++ ist im Verlauf der Weiterentwicklung jedoch vom Sun-Standard abgewichen, da immer mehr Windows-spezifische Erweiterungen Einzug fanden. Das führte dazu, dass Sun und Microsoft sich nicht auf ein weiteres Lizenzabkommen einigen wollten. Dementsprechend arbeitete man bei Microsoft fern der Öffentlichkeit bereits an einer Java-ähnlichen Technologie, die schließlich 2002 unter dem Namen .NET präsentiert wurde. Dieses Framework stellte sich zwar in seinen Einzelbestandteilen als nichts wirklich Neues dar, in seiner Gesamtheit war es jedoch ein homogenes und fortschrittliches Konzept. Vor allem hatte man aus vielen Design-Fehlern verschiedener Ansätze radikale Konsequenzen gezogen.

Das Framework bediente sich bekannter Konzepte von Java, erweiterte und veränderte diese. Man vollzog eine strikte Trennung zwischen Programmiersprache und Laufzeitumgebung. So konnten verschiedene Programmiersprachen (am Anfang Visual-Basic.NET und C#) miteinander kooperieren. Das Java-Konzept des Bytecodes griff man auf, änderte es aber dahingehend, dass er besser auf registerbasierten Prozessoren zu optimieren ist und grundsätzlich JIT-kompiliert wird. Trotz des plattformunabhängigen Charakters dieser Technologien verstand Microsoft unter der in dem Zusammenhang propagierten Plattformunabhängigkeit lediglich die Kompatibilität zu allen Windows-Versionen. Diesen Umstand griff Mono auf. Weitere typische .NET-Eigenschaften sollen daher im Folgenden auf Basis von Mono erläutert werden.

Mono (spanisch für Affe) ist ein inzwischen von Novell geführtes Open-Source-Projekt. Der Begründer Miguel de Icaza – Initiator des GNOME-Projektes – hatte ursprünglich das Ziel, eine moderne Entwicklungsplattform für GNOME zu realisieren. Die Umsetzbarkeit eines solchen Vorhabens wurde anfangs angezweifelt, inzwischen ist Mono jedoch kompatibel zu .Net 1.0. Dabei war die schiere Größe des .Net-Frameworks (in der Version 1.0 über 5000 Klassen) nicht die größte Hürde. Probleme bereitete vor allem die starke Windows-Ausrichtung bestimmter Klassen. Trotz alledem ist Mono inzwischen ein großes und aktives Open-Source-Projekt [1] mit reger Community und schnell wachsender Anhängerschaft.

Sprachen

.Net versteht sich als Plattform für diverse Programmiersprachen. Hier sollen die zwei wichtigsten unter ihnen (C# und VB.Net) be-

trachtet werden [2]. Daneben gibt es jedoch inzwischen eine Vielzahl weiterer, darunter Python, Nemerle, , JavaScript, Boo oder Delphi.

C#

Die primäre Entwicklungssprache unter .Net (und demnach auch unter Mono) ist mit Sicherheit weiterhin C# (gesprochen C-Sharp). In all ihren Eigenschaften ist sie ganz auf eine möglichst direkte Unterstützung aller .Net-Features ausgelegt. Sie orientiert sich syntaktisch an C++. Der Abstraktionsgrad ist ähnlich wie bei Java – auch in C# gibt es keine Pointer, lediglich strikte Vererbung, Interfaces und ein eigenes Event-System. Über den Java-Umfang hinaus besitzt C# einige Konstrukte, die die alltägliche Arbeit erleichtern, zum Beispiel „foreach“, um Listen/Arrays/Collections zu durchlaufen sowie Enumerationen (wie in C), um Konstanten zu verwalten. Von hoher Bedeutung ist vor allem die Tatsache, dass Microsoft C# im Jahr 2000 zur Standardisierung bei der ECMA und 2003 bei der ISO eingereicht hat. Nicht zuletzt durch diesen Umstand war es der Mono-Community so schnell möglich, C# voll umzusetzen. Weiterhin kann man sagen, dass C# dadurch grundsätzlich einen „freieren“ Charakter als Java hat – diese Debatte gehört allerdings an eine andere Stelle. Die Weiterentwicklung von C# im Rahmen des .Net 2.0 Frameworks beinhaltet wesentliche neue Features, etwa so genannte Generics und nullable types. Diese werden von Mono bereits durch einen eigenen Compiler (gmcs) unterstützt, der bei vollständiger Umsetzung den bisherigen Compiler mcs ablösen wird.

Visual Basic.Net

VB.Net ist der Nachfolger von Visual Basic 6 und VBA (Macro-Sprache in Office-Anwendungen). Die Sprache ist im Vergleich zu ihren Vorfahren jedoch sehr stark erweitert und verändert worden. Innerhalb von Mono wird sie zwar bereits unterstützt, genießt aber nicht sehr große Aufmerksamkeit. Mit ihrer Entwicklung verfolgte Microsoft das Ziel, bisherigen Office- und VB-Entwicklern einen Umstieg auf .Net zu erleichtern. Diesen Anspruch hat Mono nicht, weswegen Novell zwecks Konzentration auf C# den Support für den Compiler mbas eingestellt hat. VB.Net wird jedoch von einigen Enthusiasten weiterentwickelt.

Technologische Komponenten

Mono besteht, genau wie das .Net-Framework, aus einem Set benannter Kerntechnologien, deren Kombination erst die eigentlichen Vorteile gegenüber anderen Systemen ausmacht. Die Bestandteile der Version 1.1 des .NET-Framworks sind in Mono zu 99 Prozent implementiert.

Intermediate Language (IL)

Die Intermediate Language (IL) ist das Pendant zum Java-Bytecode. Mono unterstützt dabei zwei Arten der Kompilierung, Just in Time (JIT) und Ahead of Time (AOT). Bei ersterer wird auszuführender Code bei Bedarf zur Laufzeit kompiliert, bei letzterer kann man ein plattformspezifisches Kompilat erzeugen. Die IL ist in ihrem Design im Gegensatz zum Bytecode vor allem darauf ausgelegt, optimal in nativen Code für registerbasierte Prozessoren überführt werden zu können.

Assembly

Eine Assembly ist in .NET ein Code-Container ähnlich einem JAR-File. Es wird grundsätzlich zwischen zwei verschiedenen Arten unterschieden: .exe und .dll. Der einzige Unterschied zwischen beiden ist der, dass jene mit der Endung .exe ausführbar sind. Assemblies beinhalten neben IL-Code auch Ressourcen wie Bilder, Texte und anderweitige von der Applikation benötigte Daten. Assemblies beschreiben sich und ihre Abhängigkeiten mittels Metadaten selbst und können so entsprechend geforderter Version und Kultur vom Assembly-Resolver aus dem GAC (Global Assembly Cache) geladen werden. Der GAC ist dabei eine Art Datenbank, in die Assemblies installiert werden können. Generell ist das Laden von abhängigen Bibliotheken in .NET völlig anders realisiert als bei Java. So steht zum Beispiel der Dateiname/Pfad einer Source- bzw. Assembly-Datei in keinem Zusammenhang mit den darin befindlichen Klassen oder Namensräumen. Beim Laden einer Assembly wird zunächst das lokale Verzeichnis der ladenden Assembly mit seinen Unterverzeichnissen durchsucht, anschließend der GAC. Dieser Prozess ist über eine Policy konfigurierbar und soll die Einbindung von Abhängigkeiten für den Entwickler möglichst transparent machen. Um eine .exe-Assembly unter Mono ausführen zu können, verwendet man das Tool „mono“, dem man als Parameter die .exe-Assembly übergibt.

Common Type System (CTS)

Damit IL-Codes, die durch die Übersetzung verschiedener Sprachen erzeugt wurden, untereinander kompatibel und nutzbar sind, wurde ein Set aus zur Verfügung stehenden Typen definiert. Dieses Common Type System (CTS) verfolgt zwar Ansätze von Sun, geht jedoch noch weiter, indem es alle Datentypen als Objekte behandelt. Dies wird durch eine Technologie namens Boxing realisiert, die einen Werttyp bei entsprechendem Zugriff kurzzeitig zu einem Objekt macht. Dabei wird grundsätzlich zwischen zwei Arten von Typen unterschieden: Werttypen wie „integer“, „boolean“ oder „long“ und Verweistypen wie „string“, „array“ oder „class“.

Common Language Specification (CLS)

Damit verschiedene Programmiersprachen interoperabel bleiben, müssen verschiedene Voraussetzungen erfüllt sein. Beispielsweise müssen nicht alle Sprachen alle Datentypen unterstützen oder case-sensitive sein.

Die Common Language Specification (CLS) trägt diesem Problem Rechnung, indem sie einen zu gewährleistenden Mindestumfang von zu unterstützenden Aspekten definiert. Beispiel: Eine C#-Klasse soll von einem Visual Basic.Net Programm verwendet werden. VB.Net unterscheidet jedoch nicht zwischen Groß/Kleinschreibung. Daher definiert die CLS, dass jede Sprache zu exportierende Symbole nicht lediglich durch Groß/Kleinschreibung zu unterscheiden hat.

Common Language Runtime (CLR)

Sie ist der wichtigste Bestandteil von Mono respektive dem .Net-Framework. Hier laufen alle Fäden zusammen. Auf Basis von CTS und CLS stellt die Common Language Runtime (CLR) gemäß dem ECMA-Standard 335 für die Common Language Infrastructure (CLI) die Laufzeitumgebung für Mono- und .Net-Programme dar. Das hier verfolgte Java-Prinzip der Sandbox bietet diverse Vorteile gegenüber nativ ausgeführtem Code. Bestandteil dieser Umgebung ist ein Garbage Collector. In Mono wird dieser bisher durch den Boehm-Conservative-Collector realisiert. Garbage Collection befreit den Entwickler von der Notwendigkeit des Deallozierens verwendeter Ressourcen (Klassen, Speicher usw.). Außerdem prüft die CLR vor Ausführung des Codes die Security-Policy der Runtime und des Hostsystems gegen die vom Programm verwendeten Framework-Funktionalitäten. Kommt es zu einem Konflikt (ein Programm fordert zum Beispiel Dateizugriff, ist jedoch nicht dazu berechtigt worden), so wird der entsprechende Code nicht ausgeführt. Solcherlei Policys werden in sog. Zonen definiert. Dadurch kann man, abhängig von Code-Herkunft und -Ort, Programmen unterschiedliche Rechte einräumen. Aus diesen und weiteren Eigenschaften der CLR leitet sich die Bezeichnung „Managed-Code“ für .Net-Programme ab.

Base Class Library (BCL)

Die Base Class Library (BCL) ist ein ECMA-standardisierter Klassenbaum, der minimale Kernfunktionalitäten umfasst. Jedes .Net-Programm kann jederzeit ihre Existenz voraussetzen. Sie stellt beispielsweise alle Datentypen, IO-Routinen, Netzwerk-Klassen sowie Hilfsklassen für Collections, Arrays, Events, XML usw. zur Verfügung.

Framework Class Library (FCL)

Die nicht standardisierte Framework Class Library (FCL) umfasst die BCL plus ASP.Net, ADO.Net und Windows.Forms.

ASP.NET

ASP.NET ist eine von Grund auf neu entwickelte Web-Technologie, die mit dem ursprünglichen ASP nichts gemein hat. Sie stellt auch keine eigene Programmiersprache dar, sondern ist lediglich ein großer Bestandteil der Framework Class Library. Die Mono-Implementation von ASP.NET gehörte zu den ersten vollständig umgesetzten .NET 1.1-Bestandteilen.

Bei der Entwicklung von ASP.NET-Web-Lösungen setzen sich ASP.NET-Seiten zu einem Teil aus XML-Code (aspx-Dateien) und zu einem anderen aus Code-Behind (in Form einer dll) zusammen. Die aspx-Datei wird dabei zur Laufzeit intern in ausführbarem Code umgesetzt, der mit dem Code-Behind-Anteil verkoppelt eine kompilierte Web-Seite bildet. Wie man nun in der eigenen Implementation den Code verteilt, ist Sache des Designs. Eher deklarative Anteile werden im XML-Dialekt in der aspx-Datei hinterlegt, eher imperative Anteile im Code-Behind. Beide können sich dabei jederzeit referenzieren.

In Mono gibt es mehrere Arten, ASP.NET-Seiten auszuführen. Zum einen gibt es mit dem XSP einen reduzierten, eher für Entwicklungszwecke gedachten Mini-Web-Server, des Weiteren mit mod_mono eine Apache-Anbindung und für sehr spezielle Anwendungen kann man unter Verwendung von bereits integrierten HTTP-Request-Response-Klassen einen eigenen Web-Server aufbauen.

Über ASP.NET können auch sog. Web-Services realisiert werden, die, auf dem SOAP-Protokoll basierend, Web-getriebene Remote Procedure Calls erlauben.

ADO.NET

Wie auch bei ASP.NET darf man ADO.NET nicht mit dem Namensvetter ADO von Microsoft verwechseln. ADO.NET stellt die Datenbankzugriffstechnologie unter .NET dar und ist ebenso wie ASP.NET unter Mono vollständig kompatibel zum .Net- Framework 1.1. Basierend auf so genannten Data-Providern werden die verschiedenen Datenbanken angesprochen. Mono unterstützt dabei über den Standardumfang von Microsoft hinaus auch Open-Source-Datenbanken wie MySQL, PostgreSQL, SQLite und Firebird und proprietäre Systeme wie IBM DB2, Oracle und Sybase.

Unter .NET wird die Philosophie des diskonnektiven Datenbankzugriffs propagiert. Dazu gibt es die Klasse DataSet, die es ermöglicht, eine Datenbankstruktur mit Inhalten von einem Server abzufragen, diese dann offline zu verarbeiten und bei erneuter Verbindung die vollzogenen Änderungen wieder zurück in die Datenbank zu spielen.

Windows.Forms

Eine besondere Bedeutung kommt dem GUI-Toolkit Windows.Forms zu. Hier gab es bei Mono in der Vergangenheit den Ansatz, auf Nicht-Microsoft-Plattformen eine Kapselung von WINE einzusetzen. Da dieser Ansatz jedoch konzeptionell unsauber war, wird zurzeit intensiv an einer Reimplementierung auf Basis von Cairo als Grafik-Engine gearbeitet. Bereits jetzt sind einfache Oberflächen auf dieser Basis realisierbar. Völlige Kompatibilität wird jedoch erst in der zweiten Hälfte 2006 mit Mono 1.2 erreicht sein.

GTK#

Besser als die Benutzung von Windows.Forms ist es jedoch, von Anfang an auf GTK# zu setzen. Dieses auf dem bekannten Gtk aufsetzende GUI-Toolkit ist in der Lage, auf jeder Plattform eine annähernd völlig nativ aussehende Oberfläche darzustellen. Dabei wird ein zeitgemäßes Boxing-Modell umgesetzt, das die Unabhängigkeit von Bildschirmauflösungen, Textbreiten bei unterschiedlichen Fonts/Sprachen und so weiter gewährleistet. GTK# ist in jeder Mono-Distribution bereits enthalten.

Nachteile: Die völlig unterschiedlichen APIs von GTK# und Windows.Forms machen eine Migration relativ schwierig und auf Apple-Systemen muss zur Verwendung von Gtk ein X-Server betrieben werden.

Cocoa#

Cocoa# ist ein Apple-spezifischer Wrapper des proprietären GUI-Toolkits Cocoa. Mit ihm ist es möglich, die Apple-spezifischen GUI-Funktionalitäten zu nutzen.

IDE

Neben dem bekannten Visual Studio gibt es mit SharpDevelop eine umfangreiche freie .Net-Entwicklungsumgebung unter Windows, die auch Mono unterstützt. Speziell für Mono wird zurzeit die Entwicklungsumgebung MonoDevelop entwickelt. Auf einer früheren Version von SharpDevelop aufbauend, realisiert sie ihre GUI jedoch in Gtk#, um auf typischen Open-Source-Plattformen ein natives Look-And-Feel zu erreichen. MonoDevelop befindet sich zurzeit in einem relativ frühen Entwicklungsstadium und unterstützt daher noch nicht alle vom Visual-Studio oder SharpDevelop gewohnten Features. Dafür integriert es sich nahtlos in den GNOME-Desktop und arbeitet eng mit den unterstützten Mono-Tools zusammen.

Fazit

Insgesamt kann hier nur ein grober Überblick gegeben werden. Würde man weiter ausholen, so müsste man sicherlich auf Technologien wie Generics, Partial-Classes, Reflection, Code-Erzeugung zur Laufzeit, Remoting, Application-Domains, Type-Resolver, Properties, Serialisierung, Web-Controls, Strong-Names, Namespaces und andere näher eingehen. Sie sind alle in Mono realisiert und allein die genauere Betrachtung einer einzelnen würde den Rahmen dieses Artikels sprengen.

Bezieht man sich auf den reinen Code, so ist eine Migration von .NET zu Mono zumindest bis zur Version 1.1 von .NET fast problemlos möglich. Sie kann bei weniger komplexen und wenig technisch spezifischen Projekten sogar entfallen, womit auch der IL-Code ohne erneute Übersetzung auf Mono sofort ausführbar wäre. Dies setzt allerdings voraus, dass keine Microsoft-spezifischen Anteile im Code existieren. Beispiel hierfür sind Klassen zum Umgang mit dem Active-Directory. Mono hat sich ansonsten in Details um möglichst hohe Kompatibilität zum Microsoft-Original bemüht. Beispielsweise werden Pfadangaben so behandelt, dass auch hier nur wenig bis gar nicht zu migrieren ist.

Generell lässt sich sagen, dass der Umstieg vom Microsoft- .Net-Framework auf Mono vor allem auch eine Öffnung in Richtung anderer Plattformen mit anderen Philosophien ist.

Abonniere jetzt t3n-News über WhatsApp und bleib mobil auf dem Laufenden!
t3n-News via WhatsApp!
Vorheriger Artikel Zurück zur Startseite Nächster Artikel
Deine Meinung

Bitte melde dich an!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden

Aktuelles aus dem Bereich Entwicklung
Microsoft öffnet sich weiter! Visual Studio Code ab sofort Open Source
Microsoft öffnet sich weiter! Visual Studio Code ab sofort Open Source

Auf seiner Entwicklerkonferenz Connect hat Microsoft einen weiteren Schritt auf die Open-Source-Community zu gemacht. Der Editor Visual Studio Code ist ab sofort frei verfügbar. » weiterlesen

HP ruft Entwickler zur Mitarbeit auf: Neues Open-Source-OS OpenSwitch gestartet
HP ruft Entwickler zur Mitarbeit auf: Neues Open-Source-OS OpenSwitch gestartet

HP hat mit OpenSwitch ein auf Linux basierendes neues Open-Source-Betriebssystem für Netzwerkgeräte und eine passende Community-Plattform an den Start gebracht. Fünf Partner, darunter Intel und … » weiterlesen

Open-Source-Mail-Client in schick: Das kann der erweiterbare Nylas N1
Open-Source-Mail-Client in schick: Das kann der erweiterbare Nylas N1

N1 ist ein schicker neuer E-Mail-Client aus dem Hause Nylas, der seinen Fokus auf Design und Erweiterbarkeit setzt – und der Open Source ist. » weiterlesen

Alle Hefte Jetzt abonnieren – für nur 35 €

Kennst Du schon unser t3n Magazin?