wake-up-neo.net

Mono wird häufig verwendet, um "Ja, .NET ist plattformübergreifend" zu sagen. Wie gültig ist diese Behauptung?

In Was würden Sie für Ihr Projekt zwischen .NET und Java zu diesem Zeitpunkt wählen? Ich würde sagen, dass ich das Thema "Werden Sie immer unter Windows bereitstellen?" "Die wichtigste technische Entscheidung für ein neues Webprojekt. Wenn die Antwort" Nein "lautet, würde ich Java anstelle von .NET) empfehlen.

Ein sehr häufiges Gegenargument ist: "Wenn wir jemals unter Linux/OS X/Whatever laufen wollen, werden wir einfach Mono laufen lassen."1, was an der Oberfläche ein sehr überzeugendes Argument ist, aber ich stimme aus mehreren Gründen nicht zu.

  • OpenJDK und alle vom Anbieter bereitgestellten JVMs haben das offizielle Sun TCK bestanden, um sicherzustellen, dass alles ordnungsgemäß funktioniert. Mir ist nicht bekannt, dass Mono ein Microsoft TCK bestanden hat.
  • Mono verfolgt die .NET-Versionen. Welche .NET-Ebene wird derzeit vollständig unterstützt?
  • Funktionieren alle GUI-Elemente (WinForms?) In Mono ordnungsgemäß?
  • Unternehmen möchten sich möglicherweise nicht auf Open Source-Frameworks als offiziellen Plan B verlassen.

Ich bin mir bewusst, dass mit der neuen Governance von Java von Oracle) die Zukunft unsicher ist, aber zB IBM bietet JDKs für viele Plattformen an , einschließlich Linux. Sie sind es einfach nicht Open Source.

Unter welchen Umständen ist Mono eine gültige Geschäftsstrategie für .NET-Anwendungen?


1Mark H fasste es zusammen als : "Wenn die Behauptung lautet, dass " Ich habe eine Windows-Anwendung in .NET geschrieben, sollte sie auf Mono laufen ", dann nicht, es ist keine gültige Behauptung - aber Mono hat sich bemüht, die Portierung solcher Anwendungen zu vereinfachen. "

171
user1249

Sparkies Antwort Verstanden, lassen Sie mich ein wenig ergänzen.

".NET ist plattformübergreifend" ist eine zu vieldeutige Aussage, da sich sowohl das Framework als auch die Welt, für die es ursprünglich erstellt wurde, geändert und weiterentwickelt haben.

Die kurze Antwort lautet:

Die zugrunde liegende Engine, die .NET und seine Derivate antreibt, der Common Language Infrastructure Standard, ist plattformübergreifend. Als ob Sie Ihren Code auf mehrere Plattformen übertragen möchten, müssen Sie die Verwendung der richtigen APIs auf dem planen richtige Plattform um auf jeder Plattform die beste Erfahrung zu liefern.

Die CLI-Familie hat den Ansatz "Einmal schreiben, überall ausführen" nicht ausprobiert, da die Unterschiede zwischen einem Telefon und einem Mainframe zu groß sind. Stattdessen ist ein Universum von API- und Laufzeitfunktionen entstanden, die plattformspezifisch sind, um Entwicklern die richtigen Tools zu bieten, um großartige Erfahrungen Auf jeder Plattform zu erstellen.

Denken Sie daran: Programmierer zielen nicht mehr auf Windows-PCs oder Unix-Server. Die Welt ist heute mehr denn je von faszinierenden Plattformen umgeben, von PCs über Spielekonsolen bis hin zu leistungsstarken Telefonen, Set-Top-Boxen, großen Servern und verteilten Maschinenclustern. Eine Einheitsgröße auf allen Plattformen würde sich auf winzigen Geräten nur aufgebläht und auf großen Systemen unterfordert fühlen.

Das .NET Framework-Produkt von Microsoft ist nicht plattformübergreifend, sondern läuft nur unter Windows. Es gibt Variationen von .NET Framework von Microsoft, die auf anderen Systemen wie Windows Phone 7, XBox360 und Browsern über Silverlight ausgeführt werden, aber alle sind leicht unterschiedliche Profile.

Heute können Sie mit .NET-basierten Technologien alle gängigen Betriebssysteme, Telefone, Mobilgeräte, eingebetteten Systeme und Server ansprechen. Hier ist eine Liste, die zeigt, welche CLI-Implementierung Sie jeweils verwenden würden (diese Liste ist nicht vollständig, sollte aber 99% der Fälle abdecken):

  • x86- und x86-64-basierte PC-Computer:
    • windows ausführen -> Normalerweise führen Sie .NET oder Silverlight aus, aber Sie können hier auch Vollmono verwenden.
    • linux, BSD oder Solaris ausführen -> Sie führen Mono oder Silverlight vollständig aus
    • macOS X ausführen -> Sie führen Mono oder Silverlight aus
    • running Android -> Sie führen die Mono/Android-Teilmenge aus
  • ARM-Computer:
    • Ausführen von Windows Phone 7: Sie führen Compact Framework 2010 aus
    • Ausführen von Windows 6.5 und älter: Sie führen das alte Compact Framework aus
    • Android-Geräte: Sie führen Mono/Android aus
  • PowerPC-Computer:
    • Sie führen Mono für vollständige Linux-, BSD- oder Unix-Betriebssysteme aus
    • Sie führen Embedded Mono für PS3, Wii oder andere eingebettete Systeme aus.
    • Auf der XBox360 führen Sie CompactFramework aus
  • S390, S390x, Itanium, SPARC Computer:
    • Sie laufen voll Mono
  • Andere eingebettete Betriebssysteme:
    • Sie führen .NET MicroFramework oder Mono mit dem mobilen Profil aus.

Abhängig von Ihren Anforderungen kann das oben Genannte ausreichen oder nicht. Sie werden kaum den gleichen Quellcode bekommen, der überall ausgeführt wird. Beispielsweise wird XNA-Code nicht auf jedem Desktop ausgeführt, während .NET Desktop-Software nicht auf XNA oder dem Telefon ausgeführt wird. In der Regel müssen Sie Änderungen an Ihrem Code vornehmen, um in anderen Profilen von .NET Framework ausgeführt zu werden. Hier sind einige der Profile, die mir bekannt sind:

  • .NET 4.0-Profil
  • Silverlight-Profil
  • Windows Phone 7-Profil
  • XBox360-Profil
  • Monokernprofil - folgt dem .NET-Profil und ist unter Linux, MacOS X, Solaris, Windows und BSD verfügbar.
  • .NET Micro Framework
  • Mono auf iPhone Profil
  • Mono auf Android Profil
  • Mono auf PS3-Profil
  • Mono auf Wii-Profil
  • Mondscheinprofil (kompatibel mit Silverlight)
  • Erweitertes Moonlight-Profil (Silverlight + vollständiger .NET 4-API-Zugriff)

Jedes dieser Profile ist also etwas anders, und das ist keine schlechte Sache. Jedes Profil ist so konzipiert, dass es auf seine Host-Plattform passt und die sinnvollen APIs verfügbar macht und diejenigen entfernt, die keinen Sinn ergeben.

Beispielsweise sind die Silverlight-APIs zur Steuerung des Host-Browsers auf dem Telefon nicht sinnvoll. Und Shader in XNA machen auf PC-Hardware, für die die entsprechende Unterstützung fehlt, keinen Sinn.

Je früher Sie erkennen, dass .NET keine Lösung ist, um den Entwickler von den zugrunde liegenden Funktionen der Hardware und der nativen Plattform zu isolieren, desto besser wird es Ihnen gehen.

Zu Beginn sind einige APIs und Stacks auf mehreren Plattformen verfügbar. Beispielsweise kann ASP.NET unter Windows, Linux, Solaris und MacOS X verwendet werden, da diese APIs sowohl unter .NET als auch unter Mono vorhanden sind. ASP.NET ist auf einigen von Microsoft unterstützten Plattformen wie XBox oder Windows Phone 7 nicht verfügbar und wird auch auf anderen von Mono unterstützten Plattformen wie der Wii oder dem iPhone nicht unterstützt.

Die folgenden Informationen sind erst ab dem 21. November korrekt und viele Dinge in der Mono-Welt werden sich wahrscheinlich ändern.

Die gleichen Prinzipien können auf andere Stapel angewendet werden. Eine vollständige Liste würde eine richtige Tabelle erfordern, von der ich keine Ahnung habe, wie sie hier dargestellt werden soll. Hier ist jedoch eine Liste von Technologien, die auf einer bestimmten Plattform möglicherweise nicht vorhanden sind. Sie können davon ausgehen, dass alles verfügbar ist, was hier nicht aufgeführt ist (Sie können mir gerne Änderungen für Dinge senden, die ich verpasst habe):

Core Runtime Engine [überall]

  • Reflection.Emit Support [überall außer WP7, CF, Xbox, MonoTouch, PS3]
  • CPU SIMD-Unterstützung [Linux, BSD, Solaris, MacOS X; Bald PS3, MonoTouch und MonoDroid]
  • Fortsetzung - Mono.Tasklets [Linux, BSD, Solaris, MacOS, PS3, Wii]
  • Assembly entladen [nur Windows]
  • VM-Injektion [Linux, BSD, MacOS X, Solaris]
  • DLR [Windows, Linux, MacOS X, Solaris, MonoDroid]
  • Generika [einige Einschränkungen für PS3 und iPhone].

Sprachen

  • C # 4 [überall]
  • C # Compiler als Dienst (Linux, MacOS, Solaris, BSD, Android)
  • IronRuby [überall WP7, CF, Xbox, MonoTouch, PS3 ausführen]
  • IronPython [überall WP7, CF, Xbox, MonoTouch, PS3 ausführen]
  • F # [überall WP7, CF, Xbox, MonoTouch, PS3 ausführen]

Server-Stacks

  • ASP.NET [Windows, Linux, MacOS, BSD, Solaris]
  • ADO.NET [überall]
  • LINQ to SQL [überall]
  • Entity Framework [überall]
  • XML-Kernstapel [überall]
    • XML-Serialisierung [überall außer WP7, CF, Xbox]
  • LINQ to XML (überall)
  • System.Json [Silverlight, Linux, MacOS, MonoTouch, MonoDroid]
  • System.Messaging [Windows; unter Linux, MacOS und Solaris ist RabbitMQ erforderlich]
  • .NET 1 Enterprise Services [nur Windows]
  • WCF [vollständig unter Windows; kleine Teilmenge unter Silverlight, Solaris, MacOS, Linux, MonoTouch, MonoDroid]
  • Windows-Workflow [nur Windows]
  • Cardspace-Identität [nur Windows]

GUI-Stapel

  • Silverlight (Windows, Mac, Linux - mit Moonlight)
  • WPF (nur Windows)
  • Gtk # (Windows, Mac, Linux, BSD)
  • Windows.Forms (Windows, Mac, Linux, BSD)
  • MonoMac - Native Mac Integration (nur Mac)
  • MonoTouch - Native iPhone-Integration (nur iPhone/iPad)
  • MonoDroid - Native Android Integration (nur Android)
  • Media Center-APIs - Nur Windows
  • Unordnung (Windows und Linux)

Grafikbibliotheken

  • GDI + (Windows, Linux, BSD, MacOS)
  • Quarz (MacOS X, iPhone, iPad)
  • Kairo (Windows, Linux, BSD, MacOS, iPhone, iPad, MacOS X, PS3, Wii)

Monobibliotheken - Plattformübergreifend, können in .NET verwendet werden, müssen jedoch manuell erstellt werden

  • C # 4 Compiler als Service
  • Cecil - CIL Manipulation, Workflow, Instrumentierung von CIL, Linker
  • RelaxNG-Bibliotheken
  • Mono.Data. * Datenbankanbieter
  • Full System.Xaml (zur Verwendung in Setups, in denen .NET den Stack nicht anbietet)

MonoTouch bedeutet, dass Mono auf dem iPhone ausgeführt wird. MonoDroid bedeutet, dass Mono auf Android ausgeführt wird. PS3- und Wii-Ports stehen nur qualifizierten Entwicklern von Sony und Nintendo zur Verfügung.

Ich entschuldige mich für die mangelnde Formalität.

195
miguel.de.icaza

Zunächst müssen Sie zwischen der Common Language Infrastructure (dem offenen Standard) und .NET (der Implementierung dieses Standards durch Microsoft) unterscheiden. Mono ist eine Implementierung der CLI und hat nie behauptet, ein "portables .NET" zu sein. Außerdem ist die C # -Sprache ein offener Standard und nicht streng an .NET gebunden.

Ich weiß nicht, ob Microsoft über ein Tool verfügt, mit dem überprüft werden kann, ob eine Implementierung kompatibel ist. Wenn dies jedoch der Fall ist, bin ich mir ziemlich sicher, dass die Mono-Mitarbeiter es haben und verwenden.

Mono folgt dem .Net, aber kaum. Mono kann C # 4.0-Code ausführen (aktuelle .NET-Version). Außerdem hat Microsoft kürzlich den gesamten DLR-Code und die DLR-Bibliotheken als Open Source-Version (unter der Apache 2.0-Lizenz) bereitgestellt. Dadurch konnte Mono erst letzte Woche Sprachen wie IronPython, IronRuby und F # als Open Source-Version verwenden. Darüber hinaus veröffentlicht Microsoft regelmäßig CTPs mit bevorstehenden Funktionen in .NET, sodass Mono-Entwickler über aktuelle Release-Versionen auf dem Laufenden bleiben können.

In .NET gibt es eine Reihe von Tools und Erweiterungen, z. B. Codeverträge. Diese sind nicht immer vollständig in Mono implementiert. (Derzeit gibt es meines Erachtens einen Teilvertragsprüfer für Requires-Verträge). Diese werden in .NET-Apps ohnehin nicht häufig verwendet, aber wenn ihre Popularität zunimmt, steigt auch die Geschwindigkeit, mit der sie in Mono implementiert werden.

WinForms sind nicht (vollständig) portabel. Sie sind .NET-spezifisch und nicht Teil der CLI. Die CLI gibt keinen bestimmten Widget-Satz an. Es gibt jedoch plattformübergreifende Widget-Sets (GTK # und Silverlight). Wenn Sie eine Anwendung von Grund auf mit Blick auf die Portabilität schreiben, verwenden Sie eine dieser Anwendungen anstelle von Winforms/WPF. Darüber hinaus bietet mono einen Thin Wrapper für die Winforms-API, mit dem vorhandene Winforms-Apps einfacher in GTK # portiert werden können (ohne vollständiges Umschreiben).

Mono bietet ein Tool, den Mono Migration Analyzer (MoMA), mit dem eine vorhandene .NET-Anwendung verwendet werden kann, um Sie über die Portabilität zu informieren. (z. B. nicht portierbare Bibliotheken identifizieren, die verwendet werden, P/Invokes usw.).

Für Unternehmen, die nicht auf Open Source angewiesen sind, kann Mono erneut lizenziert werden. Das Eigentum an Code, der zu Mono hinzugefügt wurde, wird an Novell übergeben, der ihn auf andere Weise als die übliche LGPL-Lizenz (die ohnehin nur sehr wenige Einschränkungen aufweist) lizenzieren kann.

Was die Behauptung ".NET ist portabel" betrifft, kann dies eine gültige Behauptung sein, wenn Sie Code von Grund auf schreiben und sich der Portabilitätsprobleme mit dem Framework bewusst sind. Wenn die Behauptung lautet: "Ich habe eine Windows-Anwendung in .NET geschrieben, sie sollte unter Mono ausgeführt werden", ist dies keine gültige Behauptung. Mono hat jedoch Anstrengungen unternommen, um die Portierung solcher Anwendungen zu vereinfachen.

115
Mark H

Punkt für Punkt:

  • OpenJDK und alle vom Anbieter bereitgestellten JVMs haben das offizielle Sun TCK bestanden, um sicherzustellen, dass die Dinge korrekt funktionieren. Mir ist nicht bekannt, dass Mono ein Microsoft TCK bestanden hat.
    Es gibt eine Spezifikation, der die Microsoft CLR entspricht. Mono ist kein Klon der CLR von Microsoft, sondern eine Implementierung derselben Spezifikation. Einerseits besteht die Möglichkeit, dass dies zu einer noch größeren Inkompatibilität führt. In der Praxis hat dies bei Mono sehr gut funktioniert.
  • Mono verfolgt die .NET-Versionen. Welche .NET-Ebene wird derzeit vollständig unterstützt?
    Da die Dokumentation für .Net der tatsächlichen Version vorausgeht, hatte mono die Unterstützung für .Net 4 out vor der offiziellen Microsoft-Version tatsächlich abgeschlossen (keine Beta-Version). Darüber hinaus kann mono sehr gut dokumentieren, welche Dinge nicht unterstützt werden, und es gibt einige Tools, die Sie für vorhandene Projekte ausführen können, um Orte mit potenzieller Inkompatibilität zu erkennen.
  • Funktionieren alle GUI-Elemente (WinForms?) In Mono korrekt?
    Die überwiegende Mehrheit der Winforms funktioniert einwandfrei. WPF, nicht so sehr. Ich habe gehört, dass dies auch für Java gilt - viele der erweiterten Widget-/GUI-Toolkits werden nicht auf allen Plattformen so gut unterstützt.
  • nternehmen möchten sich möglicherweise nicht auf Open Source-Frameworks als offiziellen Plan B verlassen.
    Wenn dies der Fall ist, werden sie definitiv nicht mit Java arbeiten, da dies ein Open-Source-Framework bei Plan A noch weiter verbessert.

Wenn Sie jetzt eine plattformübergreifende App erstellen möchten , ist es nichts Falsches, von Anfang an mit Mono zu beginnen und diese als Framework zu verwenden. Sie können Mono sogar unter Windows bereitstellen, wenn Sie möchten.

Wenn Sie jedoch heute eine Windows-App erstellen möchten, von der Sie glauben, dass zu einem unbekannten Zeitpunkt in der Zukunft plattformübergreifend sein muss, möchten Sie dies wahrscheinlich Verwenden Sie die nativen Windows-Widgets und -Tools. .Net leistet hier einen viel besseren Job als Java, und Mono ist in diesem Szenario ein durchaus akzeptabler Rückgriff.

Mit anderen Worten: Ja, .Net wenn plattformübergreifend in jeder Hinsicht, die für Ihre Frage wichtig ist. Nein, Mono führt nicht einfach jedes .Net-Programm sofort aus, sondern Ihre Frage steht im Kontext eines neuen Projekts. Es erfordert nicht viel Arbeit, um neue Projekte vor Problemen zu bewahren und Kompatibilitätsprobleme zu vermeiden, insbesondere wenn Sie eher an die Entwicklung für Mono als an die Entwicklung für .Net denken.

Vor allem aber denke ich, dass dies in erster Linie die falsche Frage ist. Sofern Sie nicht von Grund auf ein neues Entwicklungsteam aufbauen, beginnen Sie mit Programmierern, die über Fachkenntnisse auf dem einen oder anderen Gebiet verfügen. Ihre besten Ergebnisse werden erzielt, wenn Sie sich an das halten, was Ihre Programmierer bereits wissen. So wichtig das Erstellen einer plattformübergreifenden App auch sein mag, wenn Sie ein Team voller .NET-Programmierer mit wenig Java Erfahrung haben, ist es unwahrscheinlich, dass Sie sie feuern oder alle Java für Sie lernen nächstes Projekt. Wenn Sie ein Team voller Java - Programmierer haben, werden Sie sie nicht bitten, .Net für ein Windows-Projekt zu lernen. Beides wäre verrückt.

14
Joel Coehoorn

Ich habe mit Mono gearbeitet, und ich würde sagen, es ist so gut wie möglich mit einer alternativen Plattform, die Open Source ist und nicht direkt von Microsoft unterstützt wird. Wenn Sie mit einer alternativen Open-Source-Plattform wie Clojure oder Scala vertraut sind, könnten Sie wahrscheinlich mit Mono vertraut sein.

Die von Mono unterstützte .NET-Version finden Sie immer auf der Seite Mono Roadmap .

Funktionieren alle GUI-Elemente? Soweit ich weiß, tun sie dies, obwohl ich nicht jedes Element ausführlich ausprobiert habe.

Ist Mono identisch mit .NET? Ich vermute, dass hier und da kleinere (und vielleicht größere) Änderungen erforderlich sind. Sie können das Entity Framework derzeit beispielsweise nicht damit ausführen.

11
Robert Harvey

Als Ziel bewegt sich das .NET/Mono-Universum sehr schnell .

Alle paar Jahre bringt Microsoft einige überzeugende Änderungen und Innovationen in Bezug auf Sprache, Laufzeit und Infrastruktur rund um .NET heraus. Beispiel: Generics, LINQ, DLR, Entity Framework - Mit jeder neuen Version von Visual Studio werden die Funktionen und die Nützlichkeit des Frameworks, auf das es abzielt, im Allgemeinen erheblich verbessert.

Die ständige Verbesserung des Frameworks ist zwar zu begrüßen, aber auch problematisch, wenn Sie Kompatibilität über mehrere Plattformen hinweg wünschen. Langzeit-Support-Plattformen wie Red Hat Enterprise Linux entwickeln sich im Hinblick auf die Einführung neuer Technologien nur schleppend langsam, und zu jedem Zeitpunkt wird es signifikante Verbesserungen bei der Mono-Plattform geben, die erst in den letzten Monaten stattgefunden haben. Wenn Sie also das Zeug ausführen möchten, das die coolen Kids bauen, müssen Sie Mono von Grund auf neu kompilieren und Ihre eigenen Patches und Updates verwalten. Das ist nicht cool.

Java hingegen stagniert so wie ein Kinderpool. Besonders jetzt, wo es von einer Firma gehört, die nur wollte Java für die Patentklagen, können Sie Seien Sie ziemlich sicher, dass es in absehbarer Zeit keine erkennbaren Änderungen in der Sprache oder Laufzeit geben wird. Java ist eine so stabile Plattform wie FORTRAN. Das ist nicht so gut, wenn Sie auf irgendeine Art von Hoffnung gehofft haben Verbesserungen, aber nicht so schlimm, wenn Sie versuchen, eine Unternehmensanwendung bereitzustellen.

9
tylerl

Aus Anwendersicht ist Mono schlecht darin, Windows .NET-Apps mit Linux kompatibel zu machen. Wenn Sie tatsächlich versuchen, eine anständig geschriebene Windows-App in Mono auszuführen, funktioniert dies nicht.

Aus der Sicht eines Packagers (ich habe früher ein bisschen an PortableApps gearbeitet) kann .NET sowohl ein Segen als auch ein Fluch sein. Wenn Sie nur unter Windows arbeiten, erleichtert .NET die Bereitstellung erheblich, da mehr Bibliotheken weniger systemabhängiges Material bedeuten (insbesondere zwischen Windows-Versionen, glaube ich), aber auch unter Windows äußerst verwirrend ist, da .NET-Versionen weder rückwärts sind -Kompatibel oder vorwärtskompatibel. Sie müssen verschiedene Versionen von .NET für verschiedene Programme herunterladen.

Trotzdem ist Mono ein guter Ausgangspunkt, um C # -Programme plattformübergreifend zu gestalten. Packen Sie das Programm nur nicht mit dem neuesten WEIN und nennen Sie es trotzdem erledigt. Schauen Sie, wohin das Picasa geführt hat.

Wie bei der politischen Stabilität der beiden Sprachen/Plattformen würde RMS) wahrscheinlich darüber schimpfen, wie Mono von Novell geleitet wird, dessen Flitterwochen mit Microsoft ziemlich berüchtigt sind. Beide Plattformen können derzeit als politisch instabil angesehen werden .

Wenn Sie wirklich eine einfache plattformübergreifende Lösung wünschen, ist QT der bewährte Weg, der politisch derzeit recht stabil ist. Er ist a) LGPL-fähig, b) mit den wichtigsten Lizenzproblemen der vergangenen Jahre fertig und c) unterstützt von Nokia. das verkauft wirklich sehr, sehr beliebte Telefone.

7
digitxp

Mono ist kein 1: 1-Port von Microsoft .net. Es gibt Technologien, die Mono einfach nicht implementiert oder nicht plant (z. B. Workflow Foundation oder WPF ), während sie andererseits über einige verfügen eigene Technologien, die Microsoft .NET nicht bietet, z. B. SIMD-Erweiterungen.

Kurze Antwort: Mono und Microsoft .NET basieren auf derselben zugrunde liegenden Grundlage - CIL und BCL -, sind jedoch separate Projekte.

4
Michael Stum

Kleiner Kommentar zu den Aussagen im Originalbeitrag. Ich werde argumentieren, dass das TCK ein theoretisches Werkzeug bleibt, mit dem Oracle behaupten kann, Java sei ein offener Standard. Denn wenn Sie bemerken, versucht Apache Harmony seit einigen Jahren erfolglos, sich als "Java" zertifizieren zu lassen. Es ist klar, dass Oracle wirklich nicht an einer Open-Source-Implementierung interessiert ist, abgesehen von der, mit der sie verbunden sind, und mehr oder weniger Kontrolle (OpenJDK), die übrigens. Ähnlich wie Mono ist es nicht vollständig (d. h. keine Java Web Start-Unterstützung) und es fehlen einige Optimierungen, die in der Closed-Source-HotSpot-Implementierung verfügbar sind.

Also wohl ab 2010; (die meisten von) Java ist Open Source, aber kein offener Standard, während (die meisten) .NET keine Open Source, sondern ein offener Standard sind. Es gibt natürlich Ausnahmen, das DLR, IronPython, IronRuby und F # sind tatsächlich Open Source. Mono ist interessant, weil es das Beste aus beiden Welten bietet, Open-Source-Implementierungen offener Standards.

2
Casper Bang

Abgesehen von allen technischen Details spielt sich beim Schreiben des Codes ein sehr wichtiger Teil ab.

Wie bei jeder plattformübergreifenden Technologie (sei es Java, Python, Ruby ...) sollten Sie davon ausgehen, dass der Code im Grunde genommen keine Chance hat, dass der Code ordnungsgemäß ausgeführt wird (auch wenn dies der Fall ist), wenn der Code nicht unter Berücksichtigung der Portabilität geschrieben wurde in Wirklichkeit viel, viel höher), da das seltsame Fehlverhalten ziemlich kritisch sein könnte. Lesen Sie: Nehmen Sie nicht die zufällige Assembly und führen Sie sie unter Mono aus.

Für ein neues Projekt (oder eines, das Sie einfach umgestalten können) ist die Auswahl von .Net/Mono als potenziell portable Laufzeit sinnvoll. Sie sparen sich jedoch viel Ärger, indem Sie Ihren Code sehr früh auf Mono testen, selbst wenn dies im Projekt der Fall ist nur eine geringfügige Änderung der Multiplattform. Wenn Sie einen Continuous Integration Server verwenden, kann dies so einfach sein wie das Einrichten eines Mono-Build-Knotens. Viele Probleme können während der Entwicklung gelöst werden, indem Sie einfach eine Gewohnheit daraus machen (wie das Erstellen von Pfadzeichenfolgen), und ein großer Teil Ihres Codes kann auf Mono portabel und in der Einheit getestet werden, indem Sie nur vernünftige Praktiken und ein wenig Voraussicht anwenden. Der Rest (d. H. Fehlgeschlagene Komponententests) ist dann plattformspezifisch (wie Code mit PInvoke), sollte jedoch ausreichend gekapselt sein, um eine alternative Implementierung pro Zielplattform bereitstellen zu können. Auf diese Weise wurde ein Großteil der Arbeit fast kostenlos erledigt, wenn das Projekt schließlich portiert werden soll, und der Rest soll Just In Time entwickelt werden.

Die Verwendung einer Bibliothek, die in Mono nicht verfügbar (.Net) oder kompatibel (Drittanbieter) ist, schließt dies natürlich aus, aber in meinem Bereich dies muss noch gesehen werden. Das ist die Strategie, die wir tatsächlich bei der Arbeit anwenden, und wenn ich sie anwende, habe ich keine Angst zu behaupten, dass .Net + Mono plattformübergreifend ist.

1
Lloeki

Es variiert die ehrliche Antwort. Ich habe kleine Webserver-Inhalte gesehen, die von IIS nach Apache) verschoben wurden und fast problemlos unter Mono ausgeführt wurden. Ich habe unveränderte Windows .NET-Anwendungen mit Win Forms unter Linux erfolgreich ausgeführt.

Obwohl es funktionieren kann, funktioniert es nicht, wenn Sie einen API-Aufruf verwenden, der nicht in Mono implementiert ist. Die einzige Lösung besteht darin, entweder Ihre Anwendung neu zu schreiben, bei Windows zu bleiben oder die zusätzlichen Inhalte in Mono zu schreiben.

0
Michael Shaw