Ist Mono bereit für die Primetime?

Hat jemand Mono, die Open-Source-.NET-Implementierung in einem großen oder mittelgroßen Projekt verwendet? Ich frage mich, ob es für reale Produktionsumgebungen bereit ist. Ist es stabil, schnell, kompatibel, … genug zu benutzen? Ist es sehr mühsam, Projekte auf die Mono-Laufzeit zu portieren, oder ist es wirklich, wirklich kompatibel genug, um bereits geschriebenen Code für die Laufzeit von Microsoft zu übernehmen und auszuführen?

Es gibt ein paar Szenarien zu beachten: (a) wenn Sie eine bestehende Anwendung portieren und sich fragen, ob Mono für diese Aufgabe gut genug ist; (b) Sie fangen an, einen neuen Code zu schreiben, und Sie möchten wissen, ob Mono reif genug ist.

Im ersten Fall können Sie mithilfe des Mono Migration Analyzer-Tools (Moma) ermitteln, wie weit Ihre Anwendung in Mono ausgeführt wird. Wenn die Bewertung mit Bravour zurückkehrt, sollten Sie mit dem Testen und der Qualitätssicherung beginnen und sich auf den Versand vorbereiten.

Wenn Ihre Bewertung mit einem Bericht zurückkommt, in dem Merkmale hervorgehoben werden, die in Mono in der Semantik fehlen oder signifikant voneinander abweichen, müssen Sie bewerten, ob der Code angepasst, neu geschrieben oder im schlimmsten Fall mit eingeschränkter functionalität ausgeführt werden kann.

Laut unserer Moma-Statistik, basierend auf Benutzereingaben (aus dem Speicher), arbeiten etwa 50% der Anwendungen out-of-the-box, etwa 25% erfordern etwa eine Woche Arbeit (Refactoring, Anpassung), weitere 15% erfordern eine ernsthafte Verpflichtung Redo Chunks von Ihrem Code, und der Rest ist es nicht wert, portieren, da sie so unglaublich an Win32 gebunden sind. An diesem Punkt beginnst du entweder bei Null oder eine geschäftliche Entscheidung wird die Bemühungen vorantreiben, deinen Code portabel zu machen, aber wir reden über Monate, die Arbeit wert sind (zumindest aus den Berichten, die wir haben).

Wenn Sie bei Null beginnen, ist die Situation viel einfacher, da Sie nur die APIs verwenden werden, die in Mono vorhanden sind. Solange Sie mit dem unterstützten Stack bleiben (das ist ziemlich viel .NET 2.0, plus alle Core-Upgrades in 3.5 einschließlich LINQ und System.Core, sowie alle der plattformübergreifenden Mono-APIs) werden Sie in Ordnung sein.

Hin und wieder stoßen Sie möglicherweise auf Fehler in Mono oder auf Einschränkungen, und Sie müssen sie möglicherweise umgehen, aber das ist nicht anders als bei jedem anderen System.

Was die Portabilität angeht: ASP.NET-Anwendungen sind die leichteren Portierungen, da diese kaum Abhängigkeiten von Win32 aufweisen und Sie sogar SQL Server oder andere gängige databaseen verwenden können (es gibt viele gebündelte databaseanbieter mit Mono).

Windows.Forms Portierung ist manchmal kniffliger, weil Entwickler gerne die .NET-Sandbox und P / Invoke ihre Gehirne verlassen, um Dinge so nützlich wie die Änderung der Cursor Blinkrate als zwei Bezier Punkte in BCD-Form in einem wParam codiert ausgedrückt. Oder so ein Trödel.

Es hat eine recht umfangreiche Berichterstattung bis zu .NET 4.0 und enthält sogar einige functionen von .NET 4.5 APIs, aber es gibt einige Bereiche, die wir aufgrund der Tatsache, dass die APIs veraltet sind, neue Alternativen erstellt haben oder der Bereich auch ist, nicht implementiert haben groß. Die folgenden APIs sind in Mono nicht verfügbar:

  • Windows Presentation Foundation
  • Windows Workflow Foundation (keine der beiden Versionen)
  • Entitätsrahmen
  • Die WSE1 / WSE2-Add-Ons zum Standard-Web-Services-Stack

Darüber hinaus ist unsere WCF-Implementierung auf das beschränkt, was Silverlight unterstützt.

Die einfachste Möglichkeit, nach einem bestimmten Projekt zu suchen, ist der Mono Migration Analyzer (MoMA) . Der Vorteil besteht darin, dass das Mono-Team über Probleme informiert wird, die die Verwendung von Mono (falls vorhanden) verhindern, sodass sie ihre Arbeit priorisieren können.

Ich habe vor kurzem MoMA auf SubSonic ausgeführt und nur ein Problem gefunden – eine seltsame Verwendung von Nullable-Typen. Das ist eine große Codebase, also war die Berichterstattung dort ziemlich beeindruckend.

Mono wird in mehreren kommerziellen sowie Open-Source-Produkten aktiv eingesetzt . Es wird in einigen großen Anwendungen wie Wikipedia und dem Mozilla Developer Center verwendet und wurde in eingebetteten Anwendungen wie den Sansa MP3-Playern verwendet und treibt tausende von veröffentlichten Spielen an.

Auf der Sprachebene ist der Mono-Compiler vollständig kompatibel mit der C # 5.0-Sprachspezifikation .

Auf der Desktop-Seite funktioniert Mono hervorragend, wenn Sie sich für GTK # entscheiden. Die Windows.Forms-Implementierung ist immer noch ein wenig errorshaft (TrayIcon funktioniert zum Beispiel nicht), aber es hat einen langen Weg zurückgelegt. Außerdem ist GTK # ein besseres Toolkit als Windows Forms.

Auf der Webseite hat Mono genug von ASP.NET implementiert, um die meisten Websites perfekt zu betreiben. Die Schwierigkeit besteht darin, einen Host zu finden, der mod_mono auf Apache installiert hat, oder selbst zu tun, wenn Sie Shell-Zugriff auf Ihren Host haben.

So oder so, Mono ist großartig und stabil.

Wichtige Dinge, die Sie beim Erstellen eines plattformübergreifenden Programms beachten sollten:

  • Verwenden Sie GTK # anstelle von Windows.Forms
  • Stellen Sie sicher, dass Sie Ihre Dateinamen richtig eingeben
  • Verwenden Sie Path.Separator anstelle von Hardcoding "\" , verwenden Sie auch Environment.NewLine anstelle von "\n" .
  • Verwenden Sie keine Aufrufe von P / Invoke für die Win32-API.
  • Verwenden Sie nicht die Windows-Registrierung.

Ich persönlich benutze Mono in einer Prime-Time-Umgebung. Ich betreibe Mono-Server, die Giga-Bytes von udp / tcp-Datenverarbeitungsaufgaben behandeln und könnte nicht glücklicher sein.

Es gibt Besonderheiten, und eines der nervigsten Dinge ist, dass Sie Ihre Msbuild-Dateien nicht einfach aufgrund des aktuellen Status von Mono “bauen” können:

  • MonoDevelop (die IDE) hat einige partielle msbuild-Unterstützung, wird aber grundsätzlich auf jeder “REAL” -Konstruktion aufbauen, die über eine einfache Hallo-Welt hinausgeht (benutzerdefinierte Build-Aufgaben, dynamische “Eigenschaften” wie $ (SolutionDir), echte Konfiguration, um ein paar Tote zu nennen (endet)
  • xbuild, welches das mono-mitgelieferte-msbuild-vollkompatible-Build-System sein sollte, ist noch schrecklicher, also ist das Bauen von der Kommandozeile eigentlich eine schlechtere Erfahrung als die Benutzung der GUI, was ein sehr “unorthodoxer” Zustand ist Union für Linux-Umgebungen …

Einmal / Während du deine Sachen tatsächlich BUILT bekommst, könntest du sogar für Code, der UNTERSTÜTZT werden sollte, einige Wildniss sehen:

  • der Compiler wird auf bestimmte Konstrukte geborst
  • und bestimmte fortgeschrittenere / neue .NET-classn casting unerwarteten Mist auf dich (XLinq irgendjemand?)
  • einige unreife Runtime “Features” (3GB Heap Limit ON x64 … WTF!)

aber das Heben sagte, dass Dinge im Allgemeinen sehr schnell arbeiten und Lösungen / Workarounds reichlich vorhanden sind .

Sobald Sie diese anfänglichen Hürden genommen haben, ist meine Erfahrung, dass Mono ROCKS, und wird immer besser mit jeder Iteration .

Ich hatte Server laufen mit Mono, Verarbeitung von 300 GB Daten pro Tag, mit Tonnen von p / ruft und im Allgemeinen viel Arbeit und bleiben UP für 5-6 Monate, auch mit der “blutenden Kante” Mono.

Hoffe das hilft.

Die Empfehlungen für die angenommene Antwort sind jetzt etwas veraltet.

  • Die Windows Forms Implementierung ist jetzt ziemlich gut. (Siehe Paint-Mono für einen Port von Paint.net, der eine ziemlich komplizierte Windows-Formularanwendung ist. Alles was benötigt wurde, war eine Emulationsebene für einige der P-Invoke und nicht unterstützten Systemaufrufe).
  • Path.Combine sowie Path.Seperator zum Verbinden von Pfaden und Dateinamen.
  • Die Windows-Registrierung ist in Ordnung, solange Sie sie nur zum Speichern und Abrufen von Daten aus Ihren Anwendungen verwenden (dh Sie können keine Informationen über Windows daraus erhalten, da es sich im Grunde um eine Registrierung für Mono-Anwendungen handelt).

Wenn du WPF benutzen willst, hast du kein Glück. Mono hat derzeit keine Pläne es zu implementieren.

http://www.mono-project.com/WPF

Nun, Mono ist großartig, aber soweit ich sehen kann, ist es instabil. Es funktioniert, aber Fehler, wenn Sie Mono-process eine ernsthafte Arbeit zu tun geben.

TL; DR – Verwenden Sie kein Mono, wenn Sie:

  • Verwenden Sie in Multithread-Umgebungen AppDomains (Assembly Load \ Unload)
  • Kann das “let-it-fail” -Modell nicht aufrechterhalten
  • Erleben Sie gelegentlich schwere Belastungen während des processablaufs

Also, die Fakten.

Wir verwenden mono-2.6.7 (.net v 3.5) unter RHEL5, Ubuntu und, aus meiner Sicht, ist es die stabilste Version, die von Novell entwickelt wurde. Es hat ein Problem mit dem Entladen von AppDomains (segfaults), jedoch scheitert es sehr selten und dies ist bei weitem akzeptabel (von uns).

Okay. Wenn Sie jedoch Features von .net 4.0 verwenden möchten, müssen Sie zu den Versionen 2.10.x oder 3.x wechseln, und hier beginnen die Probleme.

Im Vergleich zu 2.6.7 sind neue Versionen nur inakzeptabel. Ich habe eine einfache Stresstestanwendung geschrieben, um Monoinstallationen zu testen.

Es ist hier, mit statementen zu verwenden: https://github.com/head-thrash/stress_test_mono

Es verwendet Thread-Pool-Worker-Threads. Worker lädt dll in AppDomain und versucht, etwas zu tun. Einige der Arbeiten sind vielfädig, manche sind single. Fast alle Arbeiten sind CPU-gebunden, obwohl einige Dateien von der Festplatte gelesen werden.

Die Ergebnisse sind nicht sehr gut. In der Tat, für die Version 3.0.12:

  • sgen GC segfaults verarbeiten fast sofort
  • Mono mit Boehm lebt länger (von 2 bis 5 Stunden), aber segfaults schließlich

Wie oben erwähnt, funktioniert sgen gc einfach nicht (Mono aus der Quelle):

 * Assertion: should not be reached at sgen-scan-object.h:111 Stacktrace: Native stacktrace: mono() [0x4ab0ad] /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x2b61ea830cb0] /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x35) [0x2b61eaa74425] /lib/x86_64-linux-gnu/libc.so.6(abort+0x17b) [0x2b61eaa77b8b] mono() [0x62b49d] mono() [0x62b5d6] mono() [0x5d4f84] mono() [0x5cb0af] mono() [0x5cb2cc] mono() [0x5cccfd] mono() [0x5cd944] mono() [0x5d12b6] mono(mono_gc_collect+0x28) [0x5d16f8] mono(mono_domain_finalize+0x7c) [0x59fb1c] mono() [0x596ef0] mono() [0x616f13] mono() [0x626ee0] /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x2b61ea828e9a] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x2b61eab31ccd] 

B. für boehm segfauls – zum Beispiel (Ubuntu 13.04, mono aus der Quelle):

 mono: mini-amd64.c:492: amd64_patch: Assertion `0' failed. Stacktrace: at  <0xffffffff> at System.Collections.Generic.Dictionary`2.Init (int,System.Collections.Generic.IEqualityComparer`1) [0x00012] in /home/bkmz/my/mono/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:264 at System.Collections.Generic.Dictionary`2..ctor () [0x00006] in /home/bkmz/my/mono/mcs/class/corlib/System.Collections.Generic/Dictionary.cs:222 at System.Security.Cryptography.CryptoConfig/CryptoHandler..ctor (System.Collections.Generic.IDictionary`2,System.Collections.Generic.IDictionary`2) [0x00014] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/Crypto Config.cs:582 at System.Security.Cryptography.CryptoConfig.LoadConfig (string,System.Collections.Generic.IDictionary`2,System.Collections.Generic.IDictionary`2) [0x00013] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoCo nfig.cs:473 at System.Security.Cryptography.CryptoConfig.Initialize () [0x00697] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:457 at System.Security.Cryptography.CryptoConfig.CreateFromName (string,object[]) [0x00027] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:495 at System.Security.Cryptography.CryptoConfig.CreateFromName (string) [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:484 at System.Security.Cryptography.RandomNumberGenerator.Create (string) [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:59 at System.Security.Cryptography.RandomNumberGenerator.Create () [0x00000] in /home/bkmz/my/mono/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:53 at System.Guid.NewGuid () [0x0001e] in /home/bkmz/my/mono/mcs/class/corlib/System/Guid.cs:492 

Oder (RHEL5, mono wird hier von rpm genommen ftp://ftp.pbone.net/mirror/ftp5.gwdg.de/pub/opensuse/repositories/home%3A/vmas%3A/mono-centos5 )

 Assertion at mini.c:3783, condition `code' not met Stacktrace: at  <0xffffffff> at System.IO.StreamReader.ReadBuffer () [0x00012] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.IO/StreamReader.cs:394 at System.IO.StreamReader.Peek () [0x00006] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.IO/StreamReader.cs:429 at Mono.Xml.SmallXmlParser.Peek () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/Mono.Xml/SmallXmlParser.cs:271 at Mono.Xml.SmallXmlParser.Parse (System.IO.TextReader,Mono.Xml.SmallXmlParser/IContentHandler) [0x00020] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/Mono.Xml/SmallXmlParser.cs:346 at System.Security.Cryptography.CryptoConfig.LoadConfig (string,System.Collections.Generic.IDictionary`2,System.Collections.Generic.IDictionary`2) [0x00021] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptog raphy/CryptoConfig.cs:475 at System.Security.Cryptography.CryptoConfig.Initialize () [0x00697] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:457 at System.Security.Cryptography.CryptoConfig.CreateFromName (string,object[]) [0x00027] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:495 at System.Security.Cryptography.CryptoConfig.CreateFromName (string) [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/CryptoConfig.cs:484 at System.Security.Cryptography.RandomNumberGenerator.Create (string) [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:59 at System.Security.Cryptography.RandomNumberGenerator.Create () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Security.Cryptography/RandomNumberGenerator.cs:53 at System.Guid.NewGuid () [0x0001e] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System/Guid.cs:483 at System.Runtime.Remoting.RemotingServices.NewUri () [0x00020] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Runtime.Remoting/RemotingServices.cs:356 at System.Runtime.Remoting.RemotingServices.Marshal (System.MarshalByRefObject,string,System.Type) [0x000ba] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System.Runtime.Remoting/RemotingServices.cs:329 at System.AppDomain.GetMarshalledDomainObjRef () [0x00000] in /usr/src/redhat/BUILD/mono-3.0.3/mcs/class/corlib/System/AppDomain.cs:1363 

Beide Fehler sind irgendwie mit der AppDomains-Logik verbunden, also sollten Sie sich in Mono davon fernhalten.

BTW, getestetes Programm arbeitete 24 Stunden auf Windows-Maschine in MS .NET 4.5 env ohne Fehler.

Abschließend möchte ich sagen – verwende mono vorsichtig. Es funktioniert auf den ersten Blick, kann aber jederzeit scheitern. Sie würden mit einer Reihe von Core-Dumps und großen Glaubensverlust in Open Source-Projekten verlassen werden.

MoMA ist ein großartiges Werkzeug dafür, wie jemand anderes vorgeschlagen hat. Die größten Inkompatibilitätsquellen sind heutzutage Anwendungen, die DllImport (oder P / Invoke) in Win32-Bibliotheken enthalten. Einige Assemblys sind nicht implementiert, aber die meisten von ihnen sind nur Windows und würden unter Linux wirklich keinen Sinn machen. Ich denke, es ist ziemlich sicher zu sagen, dass die meisten ASP.NET-Anwendungen mit begrenzten Modifikationen auf Mono laufen können.

(Disclosure: Ich habe selbst zu Mono beigetragen, ebenso wie geschriebene Apps, die darüber laufen.)

In vielen Fällen können Sie vorhandenen Code verwenden und ihn einfach unter Mono ausführen, insbesondere wenn Sie eine ASP.NET-Anwendung portieren.

In einigen Fällen benötigen Sie möglicherweise ganz neue Codeabschnitte, damit es funktioniert. Wenn Sie beispielsweise System.Windows.Forms verwenden, funktioniert die Anwendung nicht unverändert. Dies gilt auch, wenn Sie einen Windows-spezifischen Code verwenden (z. B. Registrierungszugriffscode). Aber ich denke, der schlimmste Täter ist der UI-Code. Das ist besonders schlecht auf Macintosh-Systemen.

Wir haben es für ein Projekt hier bei der Arbeit verwendet, das unter Linux ausgeführt werden musste, aber einige .NET-Bibliotheken, die wir in Managed C ++ erstellt hatten, wiederverwendeten. Ich war sehr überrascht, wie gut es gelaufen ist. Unsere Haupt-ausführbare Datei wird in C # geschrieben, und wir können einfach auf unsere verwalteten C ++ – Binärdateien verweisen, ohne dass ein Problem auftritt. Der einzige Unterschied im C # -Code zwischen Windows und Linux ist der serielle RS232-Port.

Das einzige große Problem, das ich mir vorstellen kann, passierte vor ungefähr einem Monat. Der Linux-Build hatte ein Speicherleck, das auf dem Windows-Build nicht zu sehen war. Nach einigen manuellen Debugging (die grundlegenden Profiler für Mono unter Linux haben nicht viel geholfen), konnten wir das Problem auf ein bestimmtes Stück Code eingrenzen. Wir haben am Ende einen Workaround gepatcht, aber ich muss noch etwas Zeit finden, um zurück zu gehen und herauszufinden, was die Ursache des Lecks war.

Wissen Sie, wie gut die Vorschau von Mono 2.0 für Windows Forms 2.0 ist?

Von dem kleinen Teil, den ich damit gespielt habe, schien es relativ vollständig und fast brauchbar. Es sah an einigen Stellen nicht ganz richtig aus und ist insgesamt immer noch ein kleiner Treffer. Es hat mich erstaunt, dass es so gut wie mit einigen unserer Formulare funktioniert hat, wenn auch ehrlich.

Ja, es ist definitiv (wenn Sie vorsichtig sind) Wir unterstützen Mono in Ra-Ajax (Ajax-Bibliothek gefunden unter http://ra-ajax.org ) und wir haben meistens keine Probleme. Sie müssen vorsichtig mit einigen der “verrücktesten Dinge” von .Net wie WSE usw. sein, und wahrscheinlich werden auch einige Ihrer existierenden Projekte nicht 100% Monokompatibel sein, aber neue Projekte, wenn Sie sie während der Entwicklung testen werden meistens kompatibel sein, ohne Probleme mit Mono. Und der Gewinn durch die Unterstützung von Linux usw. durch die Verwendung von Mono ist wirklich cool;)

Ein großer Teil des Geheimnisses, Mono zu unterstützen, ist die Verwendung der richtigen Tools von Anfang an, zB ActiveRecord, log4net, ra-ajax etc …

Für die Art der Anwendung, die wir bauen Mono scheint leider nicht bereit für die Produktion. Wir waren insgesamt von der performance beeindruckt und von der performance sowohl auf Windows als auch auf EC2-Maschinen beeindruckt. Unser Programm stürzte jedoch ständig mit Garbage Collection-Fehlern unter Windows und Linux ab.

Die Fehlermeldung lautet: “schwerwiegende Fehler in GC: zu viele Heap-Abschnitte”, hier ist ein Link zu jemand anderem, bei dem das Problem auf eine etwas andere Art auftritt:

http://bugzilla.novell.com/show_bug.cgi?id=435906

Der erste Codeabschnitt, den wir in Mono ausgeführt haben, war eine einfache Programmieraufgabe, die wir entwickelt haben … Der Code lädt etwa 10 MB Daten in einige Datenstrukturen (zB HashSets) und führt dann 10 Abfragen mit den Daten aus. Wir haben die Abfragen 100 Mal ausgeführt, um sie zu synchronisieren und einen Durchschnittswert zu erhalten.

Der Code ist um die 55. Abfrage unter Windows abgestürzt. Auf Linux funktionierte es, aber sobald wir zu einem größeren Datensatz übergingen, würde es auch abstürzen.

Dieser Code ist sehr einfach, z. B. einige Daten in HashSets und dann Abfragen dieser HashSets usw., alle nativen c #, nichts unsicher, keine API-Aufrufe. Auf der Microsoft CLR stürzt es nie ab und läuft auf riesigen Datenmengen 1000-mal einwandfrei.

Einer unserer Leute mailte Miguel und fügte den Code hinzu, der das Problem verursacht hat, noch keine Antwort. 🙁

Es scheint auch, dass viele andere Leute dieses Problem ohne Lösung begegnet sind – eine Lösung wurde vorgeschlagen, um Mono mit verschiedenen GC-Einstellungen neu zu kompilieren, aber das scheint nur den Schwellenwert zu erhöhen, vor dem es abstürzt.

Überprüfen Sie einfach http://www.plasticscm.com. Alles (Client, Server, GUI, Merge-Tools) ist auf Mono geschrieben.

Es hängt wirklich von den Namespaces und classn ab, die Sie aus dem .NET-Framework verwenden. Ich hatte Interesse daran, einen meiner Windows-Dienste auf meinen E-Mail-Server Suse zu konvertieren, aber wir stießen auf einige harte Roadblocks mit APIs, die nicht vollständig implementiert waren. Auf der Mono-Website gibt es eine Tabelle, in der alle classn und deren Abschluss aufgeführt sind. Wenn Ihre Bewerbung abgedeckt ist, dann gehen Sie darauf.

Wie bei jeder anderen Anwendung auch, machen Sie Prototyping und Tests, bevor Sie sich natürlich vollständig verpflichten.

Ein anderes Problem, mit dem wir konfrontiert wurden, ist lizenzierte Software: Wenn Sie auf die DLL einer anderen Person verweisen, können Sie sich nicht mit Inkompatibilitäten befassen, die in dieser Assembly verborgen sind.

Ich würde mir dann vorstellen, wenn Sie eine Anwendung mit einigen Komponenten von Drittanbietern haben, könnten Sie gestopft werden. Ich bezweifle, dass sich viele Anbieter mit Mono auseinandersetzen werden

Beispiel: http://community.devexpress.com/forums/p/55085/185853.aspx

Nein, Mono ist nicht bereit für ernsthafte Arbeit. Ich habe ein paar Programme unter Windows mit F # geschrieben und sie auf Mono laufen lassen. Diese Programme verwendeten Disk, Speicher und CPU recht intensiv. Ich sah Abstürze in Mono-Bibliotheken (managed code), Abstürze im nativen Code und Abstürze in der virtuellen Maschine. Wenn Mono arbeitete, waren die Programme mindestens zweimal langsamer als in .Net in Windows und verwendeten viel mehr Speicher. Bleib weg von mono für ernsthafte Arbeit.