So, und nun mal wieder was zum Thema:
Zitat von
Mavarik:
Falls ich nicht völlig daneben liege, gibt es ein .Net Framework zur Zeit nur für Windows, oder? (CF mal außen vor)
Welchen Sinn hat es Jahrelang entwickelte Routinen die sicherlich jeder hat auf .Net umzustellen, wenn sowieso
der Zielsystem Windows ist?
Dann kann ich auch nativen Code programmieren, oder?
1.) Mono wurde schon mehrfach erwähnt. Es gibt etliche Software die auch einwandfrei auf Mono unter OSX läuft. Allerdings (meine Meinung): Es gibt (noch) keine Sprache/Umgebung die das wirklich zufriedenstellend löst. Java hat einfach kein gescheites UI-Framework. Windows Forms ist dank der internen Umsetzung auf Windows beschränkt. GTK halte ich für eine Krücke (und man sieht auch grossartig keine Windows-Anwendung die GTK benutzt).
Also: Wenn Du eine plattformunabhängige Desktop-Anwendung schreiben willst hast Du die Wahl zwischen vielen verschiedenen, aber alle irgendwie gleich schlechten Lösungen. Möglicherweise wird WPF da zukünftig ein wenig was reissen können (um XAML in Direct-X Calls umzusetzen hat man in etwa den gleichen Aufwand wie von X(A)ML zu
OpenGL, wenn man da noch Ressourcen Reinsteckt kann Mono hinterher tatsächlich
OpenGL-WPF unter Windows UND Linux / OSX mit der gleichen Codebasis), aber das ist noch Zukunftsmusik.
Die Alternative wäre ein Backend mit mehreren separaten
GUI's, und zumindest für ein Backend ist .NET sicher sehr gut geeignet.
Kommen wir zu Punkt 2:
Willst Du Anwendungen ausschliesslich für den Windows-Desktop schreiben, ist natives Delphi sicher immernoch und auch in Zukunft die richtige Wahl, insbesondere wenn man schon alten Code hat den man weiterverwenden will.
Es gibt allerdings Dinge in .NET, die ich stand heute nie mehr in anderen Umgebungen anfangen würde: Webanwendungen. ASP.NET ist mit seinem Konzept so dermassen weit vorne, elegant zu entwickeln und unterstützt mich als Entwickler so sehr, dass alles andere was da im Web-Bereich herumschwirrt einfach jederzeit messbar viel weniger Effizient ist. Und das 'läuft doch nur auf IIS'-Argument ist auch schlichtweg falsch: Ich habe es bisher nur ein einziges mal gesehen, wo eine ASP.NET Anwendung nicht 100% auf Linux / Apache mit mod_mono (und freilich mono) lief. Und da war der Entwickler selber schuld, weil er einen Excel-Export mittels
COM-Automatisierung von Excel realisiert hat. Und das ist normalerweise auch unter einem Windows Server mit IIS nicht lauffähig weil niemand ein Excel auf einem reinen Webserver installieren würde.