Ich würde für Desktop Anwendungen die plattform übergreifend laufen sollen niemals .NET empfehlen.
1. Man brauch für eine brauchbare Benutzeroberfläche wieder eine extra UI Bibliothek. Nicht alle sind brauchbar oder überhaupt fertig. Der Punkt ist das Windows.Forms rein für Windows konzipiert wurde und somit auf anderen Plattformen nur mehr schlecht als recht funktioniert. Dazu sehen die Anwendungen extrem hässlich aus. Das muss man sich nicht antun.
2. Selbst Swing lässt sich besser integrieren. Also wäre es eher zu empfehlen.
3. Es hat so gut wie keinen Vorteil gegenüber der direkten Nutzung des Toolkits.
4. .NET und Mono sind nicht grade beliebt unter Linux und Mac Nutzern. Denn die Performance der meisten Anwendungen ist grauenhaft und daher hat nicht jeder Mono installiert.
Ohwei.. selten so einen Schwachfug gelesen.
1.) Teilweise korrekt. Windows Forms ist natürlich für Windows gedacht und man braucht tatsächlich eine
Gui-Bibliothek. Wie ich aber schon ausgfeührt habe ich Gtk# fertig und brauchbar. Und die Anwendungen sehen besser aus als mit irgendeinem Java-Gedöns.
2.) Swing ist eine Krankheit. Jede Applikation die damit geschrieben ist sieht auf jedem System anders bescheiden aus und fühlt sich nicht nativ an.
3.) Deswegen gibt es für jede Plattform auch native Bindings - die gibts bei Java nicht.
4.) Bei Linux-Freaks mag das zutreffen, normalen Linux-Usern ist es egal ob da eine Runtime druntersteckt oder nicht und mit der Performance hat das gerade mal gar nichts zu tun. .NET im allgemeinen und auch Mono sind sauschnell. Man merkt allerhöchstens beim ersten Anwendungsstart eine kurze Verzögerung - wenn überhaupt.
Mono und C# sind 100% zueinander kompatibel, sind aber von der Entwicklung her zwei komplett andere Sprachen. Die Entwickler von Mono haben sich zum Ziel gesetzt, C#.net multi-platform-fähig zu machen. Das ist ihnen auch gelungen.
PS: Irgendwo habe ich mal gelesen, dass Mono in der Linux-Welt nicht gern gesehen ist, weil es eben kompatibel zu .net ist.
Auch nochmal Autsch.
Mono ist eine zu der ECMA-Spezifikation von .NET 4.0 kompatible Runtime.
Dazu kommen dann teile(!) von Microsoft-Kompatiblen-Implementierungen zugehöriger Bibliotheken wie ASP.NET, Windows Forms,
ADO.NET.
Darüber hinaus bringt Mono aber z.B. auch mehr
ADO.NET Datenbanktreiber mit als Microsoft.NET - ist in diesem Bereich also sogar weiter. Dazu kommen dann auch noch weitere Bibliotheken wie z.B. Gtk# oder auch die MonoMac-Bindings, die z.B. viele Zugriffe auf die Mac-
API Cocoa kapseln und dem Entwickler sonst notwendige P/Invokes abnehmen.
Mono hat sich inzwischen übrigens im Gnome-Desktop fest eingenistet und etliche Default-Anwendungen von Gnome sind für Mono geschrieben. So ablehnend kann die Einstellung der Linux-Anhänger die Gnome entwickeln also gar nicht sein.
So, und nun zum eigentlichen Teil:
Mono ist quasi das .Net für Nicht-Windows-Systeme?
Und "glücklicherweise" sind diese beiden Systeme (zumindest bis .NET 2, wenn Wiki recht hat) kompatibel. D.h. wenn ich unter Mac was mit z.B. MonoDevelop programmiere, dann wird es auch unter Windows laufen, wenn dort ein passendes .NET-Framework installiert ist?
Korrekt. Das geht schon etwas tiefer in .NET rein, aber für .NET gibt es drei Laufzeitumgebungen: 1.0, 2.0 und 4.0. Was man Landläufig unter .NET 2.5, 3.0 und 3.5 versteht ist im Grunde nur die 2.0er Runtime + zusätzliche Bibliotheken.
Es gibt von diesen Bibliotheken einige, die nicht oder nur Teilweise unter Mono bzw. auf anderen Plattformen laufen. Das ist z.B. Windows Presentation Foundation (WPF) oder auch Teile von WCF (Windows Communication Foundation). Letztere ist aber grad im kommen.
Auf der anderen Seite gibt es aber auch Teile in Mono, die sind viel umfangreicher als die in Microsofts .NET. Ein gutes Beispiel hier ist
ADO.NET. Microsoft kann
SQL Server und Oracle. Mono bringt hier Provider für viel mehr Datenbanken von Haus aus mit.
Bzgl. dem Programmieren an sich:
Mit MonoDevelop wäre die Sprache der Wahl dann vermutlich C#?
Ja. Oder Delphi Prism
Wie ist das mit Delphi-Prism?
Ich hab auf der Download-Seite gesehen, es gibt die
IDE für Mac und Windows. Gilt dann hier quasi das selbe wie oben? Ich entwickele unter Mac und das Ganze wäre dann unter Windows mit .NET-Framework lauffähig? Und die Sprache ist dann quasi Delphi im .NET-Style?
Genau. Voll auf den Punkt getroffen
Eine zentrale Frage wäre für mich jetzt noch:
Die Verbreitung irgendeiner .NET-Framework-Version unter Windows dürfte wohl recht weit sein - aber wie sieht es auf der anderen Seite für Mac und Linux aus?
Wenn ich das richtig verstanden habe, muss dort ja dann das Mono-Framework installiert sein - das wäre jetzt bei mir beispielsweise nicht der Fall.
Daher meine Frage, ob es da vllt. irgendwo Statistiken/Zahlen (auch wenn ich sie nicht selbst gefälscht habe ) gibt, die dazu was sagen.
Das ist halb so wild.
Wie oben schon erwähnt: Auf einem neueren Linux-System mit GNOME ist Mono schon drin. Mono auf dem Mac ist üblicher als man meinen mag, aber selbst wenn nicht ist das kein Beinbruch:
Mono bietet zum einen die Möglichkeit, die komplette Runtime in die Anwendung gleich reinzupacken. Von der Idee her ist es das gleiche, wie wenn man bei Delphi eben keine Packages ausliefert sondern einkompiliert.
http://www.mono-project.com/Embedding_Mono
Natürlich bläht das die Anwendung dann ein wenig auf - aber die komplette Mono Runtime inkl. mscorlib.dll brauchen zusammen nur 3.7 MB. Das kann man sogar noch weiter runterkriegen.
Dazu gibt es bei Mono dann auch noch die Möglichkeit, die Anwendung komplett in nativen Code zu übersetzten. Das wird z.B. auch für iOS-Anwendungen gemacht, so dass man am Ende eine native executable hat:
http://www.mono-project.com/AOT Damit ist man dann noch unabhängiger.
Dann noch eine letzte Frage:
Auf der Mono-Download-Seite habe ich jetzt auch eine Windows-Version gesehen. Da frage ich mich nun, warum?
Unterstützt die dann Mono-Anwendungen besser, als das .NET-Framework es tut?
Es soll Leute geben, die .NET nicht mögen
Nein, die Idee ist eher die, dass man seine Anwendung dann auch auf Windows direkt gegen die Mono testen kann. Wie gesagt: Es gibt Teile in Mono, die sind in .NET nicht drin (eben die angesprochenen
ADO.NET Provider), und umgekehrt.
Die oben genannten Tools (z.B. auch das Ahead-of-time compiling-Tool) sind natürlich auch kein Bestandteil von Microsofts .NET, so das man hierfür auch unter Windows Mono braucht. Es gibt auch ein Tool namens Mono Migration Analyer (MoMA), das eine für Microsoft .NET geschriebene Anwendung analysiert und aufzeigt, bei welchen Stellen es auf anderen Systemen Probleme geben kann (z.B. ein P/Invoke auf eine Windows-
DLL, das verwenden von #13#10 anstelle von Environment.NewLine oder - noch schlimmer - das Benutzen von WPF).
Auch dafür braucht man unter Windows eine Mono-Installation.
Als Anmerkung:
Ich mache ja ungeheuer viel im Web-Bereich, und ich habe bisher noch keine ASP.NET Anwendung hinbekommen die nicht auch unter Apache/mod_mono lief.
Übrigens: Die meisten kommerziellen ASP.NET Komponenten laufen inzwischen auch offiziell unter Mono:
http://www.telerik.com/company/press...-for-mono.aspx
http://www.infragistics.com/about-us...ouncement.aspx
Ich schreibe auch etliche Tools und Bibliotheken, die auch alle unter Mono laufen (viele schreibe ich sogar auf dem Mac).
Man muss sich fast schon anstrengen Sachen zu schreiben, die nicht auf Mono laufen - sofern man sich auf ein paar Grundregeln einlässt. Diese wären: Keine hart codierten Pfade, keine hart codierten Zeilenumbrüche. Die Spezialpfade wie z.B. das Userverzeichnis gibts mit .NET-Hausmitteln genauso einfach und das läuft auch unter Mono. Bevor man etwas mit Fremdcode oder Komponenten löst erstmal nachgucken ob .NET / Mono nicht schon was passendes mitliefert. Die Bibliothek ist riesig und ein großes Problem was ich bei vielen sehe ist dass sie einfach loslaufen und zeug selber schreiben was es schon gibt. Ein bisschen einlesen hat noch niemandem geschadet
Bei der
GUI immer aufpassen. Windows Forms mag auch auf dem Mac laufen (unter X11) und unter Linux, aber das sieht echt häßlich aus und viele eingekaufte Komponenten gehen da nicht. Also da lieber einheitlich auf Gtk# setzten, ODER (mein Favorit), sich tatsächlich die Arbeit machen, ein MVC-Pattern hernehmen und die
GUI für jede Plattform nativ machen (Windows Forms oder WPF für Windows, Cocoa (mittels InterfaceBuilder) auf dem Mac und Gtk oder Qt für Linux. Das sieht auf jedem System viel natürlicher aus, fühlt sichbesser an, ist hintenraus einfacher zu handeln und wenn man hinten mit Model und Controller aufpasst und das sauber löst muss man tatsächlich nur die Form auf jedem System machen, ein bisschen Glue-Code schreiben, und das war's auch schon.