Journals>Das Entwickler-Journal>Meine Erfahrungen mit dem mono-Projekt

Meine Erfahrungen mit dem mono-Projekt

Vorwort

Man kann über Microsoft sagen, was man will, aber eines muss ich ihnen schon lassen: mit Produkten wie SQL-Server, Visual Studio und .NET ist ihnen ein großer Wurf gelungen, mit denen im Bereich der Softwareentwicklung sinnvolle Standards in Bezug auf objektorientiertes Programmieren gesetzt wurden. Eine Trennung zwischen Benutzeroberfläche und Programmlogik war mit den Win32-IDEs (z.B. Visual Basic 6) zwar möglich, aber verhältnismäßig kryptisch und recht umständlich gelöst. In .NET wird man fast schon gezwungen, sich einen sauberen Programmierstil anzueignen. Nun gibt es endlich für die unterschiedlichsten Projekttypen einheitliche Vorgehensweisen. Der kleine Haken dabei ist jedoch, dass das .NET-Framework ausschließlich auf Windows-Plattformen betrieben wird, trotz der gelobten Plattformunabhängigkeit seitens Microsoft.
Wie gut, dass es Entwickler gibt, die sich diesen Umstand zu Herzen genommen und das mono-Projekt ins Leben gerufen haben. mono ist ein Nachbau des .NET-Frameworks und läuft neben Windows auch auf Linux und Mac OS X. Ich wollte wissen, wie gut das funktioniert, ob man wirklich, wie es versprochen wird, seine Visual Studio-Anwendungen ohne Abstriche auf Mac portieren kann und was es zu beachten gibt.

Umgebung

In meinem Fall betreibe ich mono unter Mac OS X 10.6.4. Das .NET-Projekt wurde in Visual Studio 2005 geschrieben. Dabei handelt es sich um eine einfache Windows Forms-Anwendung, die ein SQL-Frontend für Microsoft SQL Server darstellt, sprich: man gibt eine SQL-Abfrage ein und bekommt das Ergebnis in einem DataGrid angezeigt. Soweit nichts Spektakuläres.

Vorbereitung

Zunächst einmal wird das mono-Framework benötigt. Dieses kann man sich frei unter herunterladen. Das mono-Framework ist übrigens OpenSources, weswegen Interessierte auch gleich die Quelltexte laden können.
Gut, die Installation des Frameworks ist dank eines automatischen Installers keine Raketentechnik und geht in der Regel problemlos vonstatten. Was wir nun aber noch benötigen, ist eine Entwicklungsumgebung. Das Pendant zu Visual Studio nennt sich MonoDevelop und ist, je nach Plattform, in einem unterschiedlichen Entwicklungsstadium. Die Mac OS X-Version hat beispielsweise keinen GUI Designer, da Drap & Drop noch nicht implementiert werden konnte. So bleibt nur das Codieren der Positionen, das Pixelzählen und immer wieder Ausprobieren. MonoDevelop ist unter der oben genannten Seite verfügbar. Auch hier ist die Installation einfach und nach wenigen Sekunden hat man ein Disk Image, wo man nur das MonoDevelop-Icon in die Programme ziehen muss.

Start

Nach dem Start von MonoDevelop erhält man eine Startseite, die stark an Visual Studio erinnert. Hier werden die zuletzt benutzten Projekte sowie Neuigkeiten und Links zu verwandten Seiten angezeigt.

MonoDevelop Startseite

Die MonoDevelop-Oberfläche ist alles andere als nativ. Sie verhält sich nicht mac-like und sieht auch nicht so aus.
In MonoDevelop wird nach Projekten und Projektmappen gegliedert, was es für Ein- und Umsteiger leichter macht, seine Projekte wiederzufinden. Ich lade also mein SQLer-Projekt (sln-Datei, bekannt aus Visual Studio) in die IDE. Alle bekannten Dateitypen werden in der nicht-nativen Auswahlbox aufgeführt.
Nach dem Öffnen der Projektmappe befindet man sich im SourceCode. Wie schon anfangs erwähnt, findet man keinen GUI Designer, mit dem man die Oberfläche bearbeiten könnte. Stattdessen ist der Zugriff auf die Designer-Datei möglich, die immer neben einer normalen vb-Datei existiert und die Generierung sämtlicher Steuerelemente beinhaltet.
Bevor wir das Projekt ausführen können, müssen wir die .NET-Verweise für das Projekt definieren. Diese Möglichkeit finden wir unter "Projekt" und "Verweise bearbeiten…". Hier wählen wir dann die nachfolgend ersichtlichen Verweise:

mono bringt das .NET-Framework gleich mit.

Standardmäßig arbeitet mono mit den gtk-Verweisen, eigene Klassenbibliotheken für die Steuerung von Fenstern, Steuerelementen, Datenbankoperationen und einiges mehr. Da wir es hier mit einer waschechten Windows-Forms-Anwendung zu tun haben und unter denselben Rahmenbedingungen arbeiten möchten, verwenden wir hier knallhart die normalen Microsoft .NET-Bibliotheken. Mit diesen vorbereitenden Maßnahmen können wir das Projekt nun einmal kompilieren und ausführen.

Erste Schritte mit dem Projekt

Nach der Kompilierung stellen wir erstaunt fest, dass das Programm tatsächlich startet und nichts - außer der Titelleiste - darauf hindeutet, dass es sich hier um ein Programm handelt, was auf dem Mac läuft. Dadurch, dass sämtliche Steuerelemente direkt aus der Windows.Forms kommen, werden sie natürlich auch genauso dargestellt und nicht plattformspezifisch gerendert. Nach ein wenig Herumprobieren und Klicken fallen jedoch schon die ersten Macken auf. So ist der Bildschirmaufbau zäh, langsam, mitunter fehlerhaft und oft führen Aktionen jeglicher Art zum Crash des gesamten Programms - ohne, dass ich dabei selbst Mist gebaut hätte.

Ein Windows-Fenster unter Mac OS X. Die Umlaute stehen zwar richtig im Quelltext, werden aber in der kompilierten Anwendung nicht dargestellt.

Eine Windows-MessageBox unter Mac OS X! Die Fenstericons werden scheinbar nicht ausgewertet, denn egal, ob man vbInformationen, vbQuestion oder vbExclamation benutzt - es erscheint immer das Lämpchen.

Während der Ausführung sammeln sich in der Debug-Ausgabe Fehlermeldungen. Schlagwörter wie "DeviceSynchronize" lassen darauf schließen, dass das Framework oft nicht in der erforderlichen Geschwindigkeit hinterherkommt und sich Threads gegenseitig überholen.

So kann es aussehen, wenn man mehrmals hintereinander das gleiche Fenster öffnet.

Soviel zum Thema Windows.Forms. Wenden wir uns mal von der Oberfläche ab und schauen wir uns die Anwendungslogik an. Hier gehts um Klassen, Schleifen, Konstruktoren uvm. In Klassen werden üblicherweise Properties (Eigenschaften) benutzt, um Werte, die von außen nicht greifbar sein sollen (= private), kontrolliert zurückzugeben und/oder auch zu setzen. Properties sind handlich und können, im Gegensatz zu Funktionen, beide Aufgaben gleichzeitig erfüllen. Natürlich soll erwähnt werden, dass Funktionen für größere Taten bestimmt sind Visual Studio ist in dieser Hinsicht recht flexibel. Properties können, müssen aber keinen definierten Datentyp zurückgeben. Sie können sowohl nur-lesend als auch lesend/schreibend ausgeführt werden. Die folgende Property gibt keinen definierten Datentypen zurück und wird daher als "Object" angenommen - eigentlich:


mono sieht das aber ganz anders - naja fast. Das, was eigentlich eine Warnung sein sollte, ist hier noch ein Fehler:


ReadOnly-Properties werden hingegen gar nicht unterstützt … zumindest nicht "abgefangen":

Resultat:


Das disqualifiziert mono leider im jetzigen Stadium noch für eigene, wiederverwendbare Klassen(bibliotheken) (zumindest komplexere). Hier müsste man dann wieder auf Funktionen ausweichen, die zwar letztlich dasselbe tun, für unseren Zweck aber lediglich eine Vermeidungsstrategie darstellen. Übrigens: der Fehler VBNC99999 signalisiert, dass der Compiler gegen die Wand gefahren ist. Auch wenn der Eindruck entsteht, man habe versehentlich ein Objekt nicht erzeugt, so liegt der Fehler keineswegs im Quelltext - in Visual Studio ist der Quelltext problemlos ausführbar.

Wie geht es weiter?

Mein kleiner Versuch hat gezeigt, dass mono noch in den Kinderschuhen steckt und für das produktive Arbeiten nicht geeignet ist. Nein, man kann definitiv nicht alle Projekte anstandslos in mono ausführen. mono zeigt aber schon sehr gute Ansätze, was das plattformübergreifende Entwickeln anbelangt. Sicher bedarf mono noch viel Entwicklungsarbeit und Fehlerbehebung, es zeigt aber, dass sich einige Menschen Gedanken gemacht haben, wie man das Potential von .NET auf andere Plattformen bringen kann.

Kommentare

ExMacRabbitPro25.06.10 08:02
Funktioniert es denn besser wenn man in C# statt in Visual Basic programmiert?
Megaseppl25.06.10 10:45
Danke für den Bericht.
Als .NETler habe ich alle Jahre mal wieder ebenfalls Mono auf dem Mac getestet... und auch ich kam immer zu dem Ergebnis dass es noch nicht ausgereift ist.
Schade eigentlich, denn wie Du auch geschrieben hast: .NET und dessen Umfeld gehört zu den sehr wenigen tatsächlich guten Produkten von Microsoft.
bjbo25.06.10 11:52
ExMacRabbitPro

C# in Visual Basic? Meinst Du Visual Studio? Ja, darin klappt die Entwicklung leichter.

Das große Problem von .Net ist, dass es das nur für Windows-Systeme gibt (von der Version 1.1 für BSD mal abgesehen). Mono entwickelt sich zwar gut, aber immer MS .Net hinterher.
ExMacRabbitPro25.06.10 12:19
bjbo

Nein, ich meinte in der Tat schon sehr konkret C# statt Visual Basic als Programmiersprache, zum Test von Mono. Keine Ahnung was für eine Rolle das Visual Studio da spielen soll...

Hast Du denn sein Journal gelesen? Wohl eher nicht.
Denn sein Beispiel welches er zum Test der .NET Implementierung auf dem Mac nutzte ist ein VB Programm.
Meine Frage hatte den Hintergrund, dass vielleicht der Common Language Support in Mono für C# evtl. ausgereifter ist als für Visual Basic.
BNO
BNO25.06.10 22:58
Das Problem ist, dass Mono für OS X immernoch ein recht kleiner Branch von Mono ist, es fehlt halt an Entwicker Man-Power. Das sieht man auch daran, dass z.B. Banshee (Novells Mono Referenz-Projekt) auf dem Mac immer hinterher hinkt.

Wo Mono mittlerweile groß ist, ist halt unter Linux und auf mobilen Endgeräten. Bezüglich Mobilen Geräten kann sich Mono aber bei Unity bedanken, ohne die und deren support wäre das auch nicht soweit gekommen.
M@cBenutzer26.06.10 15:25
Ich kann mich meinen Vorredner nur anschließen. Zum einen ist .NET wirklich in guter Schritt zur schnellen Anwendungsentwicklung und zum anderen hinkt Mono eben noch hinterher.
Es kommt mittlerweile vor allem darauf, dass man schnell einen "Clickable-Dummy" (Windows.Forms eben) dem Kunden in die Hand drückt, damit die für ihn wichtige Gestaltung testen kann. Wenn ich ihm aber was von den tollen Sachen erzähle, die in der Anwendungslogik drinstecken, kommt meist nur Schulterzucken. Und deshalb läuft auch weiterhin VMware Fusion mit VS2008 und .NET3.5, um zu programmieren.
bjbo29.06.10 17:59
ExMac...

Der Sprachensupport spielt dabei keine Rolle, VB und C# sind beide von Anfang an implementiert worden. Sonst käme keine ausführbare Datei heraus, weil der Compiler es nicht in die IL übersetzen könnte.
apfelmuss30.07.10 22:44
Einen interessanten Aspekt solte man nicht aus den Augen verlieren. Mono lässt sich dank des JIT in Anwendungen als "script-artige" Sprache mit vollem Funktionsumfang embedden. Das geht mit C++/C leider bei weitem nicht so einfach (der entsprechende support via LLVM steckt wirklich noch in den Kinderschuhen). Die Mono APIs hingegen scheinen mittlerweile recht stabil.

Kommentieren

Sie müssen sich einloggen, um diese Funktion nutzen zu können.

OK MacTechNews.de verwendet Cookies unter anderem für personalisierte Inhalte, Seitenanalyse und bei der Auslieferung von Google-Anzeigen. Dies war zwar schon immer so, auf Wunsch der EU muss nun jedoch explizit darauf hingewiesen werden. Durch Nutzung der Website erklären Sie sich damit einverstanden. Weitere Informationen