Ist Mono bereit für die Hauptsendezeit? [geschlossen]

Hat jemand Mono, die Open Source .NET-Implementierung, für ein großes oder mittleres Projekt verwendet? Ich frage mich, ob es für reale Produktionsumgebungen bereit ist. Ist es stabil, schnell, kompatibel, ... genug, um es zu verwenden? Ist das Portieren von Projekten auf die Mono-Laufzeit sehr aufwändig oder ist es wirklich, wirklich kompatibel genug, um bereits geschriebenen Code für die Microsoft-Laufzeit zu übernehmen und auszuführen?

Es sind einige Szenarien zu berücksichtigen: (a) wenn Sie eine vorhandene Anwendung portieren und sich fragen, ob Mono für diese Aufgabe gut genug ist; (b) Sie beginnen, neuen Code zu schreiben, und möchten wissen, ob Mono ausgereift genug ist.

Im ersten Fall können Sie mit dem Mono Migration Analyzer-Tool (Moma) bewerten, wie weit Ihre Anwendung von Mono entfernt ist. Wenn die Bewertung mit Bravour zurückkommt, sollten Sie mit Ihren Tests und der Qualitätssicherung beginnen und sich auf den Versand vorbereiten.

Wenn Ihre Bewertung einen Bericht enthält, in dem Funktionen hervorgehoben werden, die in Mono fehlen oder sich in ihrer Semantik erheblich unterscheiden, müssen Sie bewerten, ob der Code angepasst, neu geschrieben werden kann oder im schlimmsten Fall, ob Ihre Anwendung mit eingeschränkter Funktionalität arbeiten kann.

Laut unserer Moma-Statistik, die auf Benutzerbeiträgen basiert (dies ist aus dem Speicher), arbeiten ungefähr 50% der Anwendungen sofort, ungefähr 25% erfordern ungefähr eine Woche Arbeit (Refactoring, Anpassung), weitere 15% erfordern eine ernsthafte Verpflichtung Wiederholen Sie Teile Ihres Codes, und der Rest ist es einfach nicht wert, die Portierung zu stören, da sie so unglaublich an Win32 gebunden sind. An diesem Punkt beginnen Sie entweder bei Null, oder eine Geschäftsentscheidung wird den Aufwand für die Portabilität Ihres Codes erhöhen, aber wir sprechen von monatelanger Arbeit (zumindest aus den Berichten, die wir haben).

Wenn Sie bei Null anfangen, ist die Situation viel einfacher, da Sie nur die in Mono vorhandenen APIs verwenden. Solange Sie beim unterstützten Stack bleiben (der so ziemlich .NET 2.0 ist, plus aller Kern-Upgrades in 3.5, einschließlich LINQ und System.Core, sowie einer der plattformübergreifenden Mono-APIs), ist alles in Ordnung.

Hin und wieder können Fehler in Mono oder Einschränkungen auftreten, und Sie müssen diese möglicherweise umgehen, aber das unterscheidet sich nicht von anderen Systemen.

In Bezug auf die Portabilität: ASP.NET-Anwendungen lassen sich am einfachsten portieren, da diese kaum oder gar nicht von Win32 abhängig sind und Sie sogar SQL Server oder andere beliebte Datenbanken verwenden können (es gibt viele gebündelte Datenbankanbieter mit Mono).

Die Portierung von Windows.Forms ist manchmal schwieriger, da Entwickler gerne aus der .NET-Sandbox entkommen und ihr Gehirn aufrufen, um Dinge zu konfigurieren, die so nützlich sind wie das Ändern der Cursor-Blinkrate, ausgedrückt als zwei in BCD-Form in einem wParam codierte Bezier-Punkte. Oder so ein Müll.

Es bietet eine ziemlich umfangreiche Abdeckung bis zu .NET 4.0 und enthält sogar einige Funktionen von .NET 4.5-APIs. Es gibt jedoch einige Bereiche, die wir nicht implementieren möchten, da die APIs veraltet sind, neue Alternativen erstellt werden oder der Umfang ebenfalls vorhanden ist groß. Die folgenden APIs sind in Mono nicht verfügbar:

• Windows Presentation Foundation
• Windows Workflow Foundation (keine der beiden Versionen)
• Entity Framework
• Die WSE1 / WSE2 "Add-Ons" zum Standard-Webdienst-Stack

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

Der einfachste Weg, um nach Ihrem spezifischen Projekt zu suchen, besteht darin, den Mono Migration Analyzer (MoMA) auszuführen . Der Vorteil besteht darin, dass das Mono-Team über Probleme informiert wird, die Sie daran hindern, Mono (falls vorhanden) zu verwenden, sodass sie ihre Arbeit priorisieren können.

Ich habe kürzlich MoMA auf SubSonic ausgeführt und nur ein Problem gefunden - eine seltsame Verwendung von Nullable-Typen. Das ist eine große Codebasis, daher war die Berichterstattung dort ziemlich beeindruckend.

Mono wird sowohl in kommerziellen als auch in 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 unterstützt Tausende von veröffentlichten Spielen.

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

Auf der Desktopseite funktioniert Mono hervorragend, wenn Sie sich für die Verwendung von GTK # entscheiden. Die Windows.Forms-Implementierung ist immer noch ein wenig fehlerhaft (zum Beispiel funktioniert TrayIcon 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 ASP.NET implementiert, um die meisten Websites perfekt auszuführen. Die Schwierigkeit besteht darin, einen Host zu finden, auf dem mod_mono auf Apache installiert ist, oder es selbst zu tun, wenn Sie Shell-Zugriff auf Ihren Host haben.

In jedem Fall ist Mono 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 Ihre Dateinamen richtig geschrieben sind
• Verwenden Sie Path.Separatoranstelle von Hardcoding "\", verwenden Sie auch Environment.NewLineanstelle von "\n".
• Verwenden Sie keine P / Invoked-Aufrufe an die Win32-API.
• Verwenden Sie nicht die Windows-Registrierung.

Ich persönlich benutze Mono in einer Prime-Time-Umgebung. Ich betreibe Monoserver, die sich mit Gigabytes von Aufgaben im Zusammenhang mit der udp / tcp-Datenverarbeitung befassen, und könnte nicht zufriedener sein.

Es gibt Besonderheiten, und eines der nervigsten Dinge ist, dass Sie Ihre msbuild-Dateien aufgrund des aktuellen Status von Mono nicht einfach "erstellen" können:

• MonoDevelop (die IDE) hat teilweise MSbuild-Unterstützung, wird aber im Grunde genommen bei jedem "REAL" Build-Conf über eine einfache Hallo-Welt hinausgehen (benutzerdefinierte Build-Aufgaben, dynamische "Eigenschaften" wie $ (SolutionDir), echte Konfiguration, um nur einige Tote zu nennen -ends)
• xbuild , das habe sein sollen , das Mono-supplied-msbuild-voll-kompatibel-build-System ist noch schrecklicher, so von der Kommandozeile Gebäude ist eigentlich eine schlechte Erfahrung als die GUI, die ein sehr „unorthodox“ state of the ist Union für Linux-Umgebungen ...

Einmal / Während Sie Ihre Sachen tatsächlich BAUEN lassen, sehen Sie möglicherweise einige Wildheiten, selbst für Code, der unterstützt werden sollte, wie:

• Der Compiler wird an bestimmten Konstrukten gestört
• und bestimmte fortgeschrittenere / neue .NET-Klassen, die unerwarteten Mist auf dich werfen (XLinq jemand?)
• Einige unreife Laufzeit- "Funktionen" (3 GB Heap-Limit auf x64 ... WTF!)

Aber im Allgemeinen sagte man, dass die Dinge im Allgemeinen sehr schnell funktionieren und es viele Lösungen / Problemumgehungen gibt .

Sobald Sie diese anfänglichen Hürden überwunden haben, ist meine Erfahrung, dass Mono-FELSEN und mit jeder Iteration immer besser werden .

Ich hatte Server, die mit Mono betrieben wurden, 300 GB Daten pro Tag verarbeiteten, mit Tonnen von p / invokes und im Allgemeinen viel Arbeit erledigten und 5-6 Monate lang wach blieben, selbst mit dem Mono "Bleeding Edge".

Hoffe das hilft.

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

• Die Implementierung von Windows Forms ist jetzt ziemlich gut. (Unter Paint-Mono finden Sie einen Port von Paint.net, einer ziemlich komplizierten Windows Forms-Anwendung. Erforderlich war lediglich 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 abrufen, da es sich im Grunde um eine Registrierung für Mono-Anwendungen handelt).

Wenn Sie WPF verwenden möchten, haben Sie 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 dem Mono-Prozess eine ernsthafte Arbeit geben.

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

• Verwenden Sie AppDomains (Assembly Load \ Unload) in Multithread-Umgebungen
• Das "Let-it-Fail" -Modell kann nicht aufrechterhalten werden
• Während des Prozesslaufs treten gelegentlich Ereignisse mit hoher Last auf

Also die Fakten.

Wir verwenden Mono-2.6.7 (.net v 3.5) unter RHEL5, Ubuntu und meiner Meinung nach ist es die stabilste Version, die von Novell erstellt wurde. Es gibt ein Problem beim Entladen von AppDomains (Segfaults), es schlägt jedoch sehr selten fehl und dies ist bei weitem akzeptabel (von uns).

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

Im Vergleich zu 2.6.7 sind neue Versionen für die Verwendung einfach nicht akzeptabel. Ich habe eine einfache Stresstest-Anwendung geschrieben, um Mono-Installationen zu testen.

Hier finden Sie Anweisungen zur Verwendung: https://github.com/head-thrash/stress_test_mono

Es werden Thread Pool Worker-Threads verwendet. Worker lädt die DLL in AppDomain und versucht, etwas Mathe zu machen. Einige der Arbeiten sind vielschichtig, andere 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 Version 3.0.12:

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

Wie oben erwähnt, funktioniert sgen gc einfach nicht (Mono aus 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]

Wie für Böhm Segfauls - zum Beispiel (Ubuntu 13.04, Mono aus Quelle gebaut):

mono: mini-amd64.c:492: amd64_patch: Assertion `0' failed.
Stacktrace:
at <unknown> <0xffffffff>
at System.Collections.Generic.Dictionary`2.Init (int,System.Collections.Generic.IEqualityComparer`1<TKey>) [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<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [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<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [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 U / min übernommen 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 <unknown> <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<string, System.Type>,System.Collections.Generic.IDictionary`2<string, string>) [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 hängen irgendwie mit der AppDomains-Logik zusammen, daher sollten Sie sich in Mono von ihnen fernhalten.

Übrigens, das getestete Programm funktionierte 24 Stunden auf einem Windows-Computer in MS .NET 4.5 env ohne Fehler.

Abschließend möchte ich sagen: Verwenden Sie Mono mit Vorsicht. Es funktioniert auf den ersten Blick, kann aber jederzeit leicht ausfallen. Sie würden mit einer Reihe von Core-Dumps und einem großen Vertrauensverlust in OpenSource-Projekte zurückbleiben.

MoMA ist ein großartiges Werkzeug dafür, wie jemand anderes vorgeschlagen hat. Die größten Ursachen für Inkompatibilität sind heutzutage Anwendungen, die DllImport (oder P / Invoke) in Win32-Bibliotheken ausführen. Einige Assemblys sind nicht implementiert, aber die meisten sind nur für Windows und unter Linux nicht sinnvoll. Ich denke, es ist ziemlich sicher zu sagen, dass die meisten ASP.NET-Anwendungen mit begrenzten Änderungen auf Mono ausgeführt werden können.

(Offenlegung: Ich habe zu Mono selbst beigetragen sowie Apps geschrieben, die darauf ausgeführt werden.)

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

In einigen Fällen benötigen Sie möglicherweise ganz neue Codeabschnitte, damit dies funktioniert. Wenn Sie beispielsweise System.Windows.Forms verwenden, funktioniert die Anwendung nicht unverändert. Ebenso, wenn Sie einen Windows-spezifischen Code verwenden (z. B. Registrierungszugriffscode). Aber ich denke, der schlimmste Täter ist 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 haben, wiederverwenden. Ich war sehr überrascht, wie gut es geklappt hat. Unsere ausführbare Hauptdatei wird in C # geschrieben und wir können ohne Probleme auf unsere verwalteten C ++ - Binärdateien verweisen. Der einzige Unterschied im C # -Code zwischen Windows und Linux ist der serielle RS232-Portcode.

Das einzige große Problem, an das ich denken kann, ist vor ungefähr einem Monat passiert. Der Linux-Build hatte einen Speicherverlust, der beim Windows-Build nicht aufgetreten war. Nach einigen manuellen Debugging-Vorgängen (die grundlegenden Profiler für Mono unter Linux haben nicht viel geholfen) konnten wir das Problem auf einen bestimmten Codeabschnitt eingrenzen. Am Ende haben wir eine Problemumgehung behoben, aber ich muss noch etwas Zeit finden, um herauszufinden, was die Hauptursache für das Leck war.

Wissen Sie, wie gut die Unterstützung der Mono 2.0-Vorschau für Windows Forms 2.0 ist?

Von dem kleinen Stück, das ich damit gespielt habe, schien es relativ vollständig und fast brauchbar zu sein. Es sah an einigen Stellen einfach nicht richtig aus und ist insgesamt immer noch ein kleiner Hit oder Miss. Es hat mich erstaunt, dass es genauso gut funktioniert hat wie bei einigen unserer Formen, wenn auch ehrlich.

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

Ein großer Teil des Geheimnisses der Unterstützung von Mono besteht meiner Meinung nach darin, von Anfang an die richtigen Tools zu verwenden, z. B. ActiveRecord, log4net, ra-ajax usw.

Für die Art der Anwendung, die wir erstellen, scheint Mono leider nicht produktionsbereit zu sein. Wir waren insgesamt beeindruckt und von der Leistung sowohl auf Windows- als auch auf EC2-Computern beeindruckt. Unser Programm stürzte jedoch konsistent 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 einer anderen Person, bei der das Problem auf etwas andere Weise auftritt:

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

Der erste Code, den wir in Mono ausgeführt haben, war eine einfache Programmieraufgabe, die wir entwickelt hatten ... Der Code lädt etwa 10 MB Daten in einige Datenstrukturen (z. B. HashSets) und führt dann 10 Abfragen für die Daten aus. Wir haben die Abfragen 100 Mal ausgeführt, um sie zeitlich zu bestimmen und einen Durchschnitt zu erhalten.

Der Code stürzte bei der 55. Abfrage unter Windows ab. Unter Linux hat es funktioniert, aber sobald wir zu einem größeren Datensatz gewechselt sind, würde es auch abstürzen.

Dieser Code ist sehr einfach, z. B. einige Daten in HashSets einfügen und dann diese HashSets usw. abfragen, alle nativen c #, nichts unsicheres, keine API-Aufrufe. Auf der Microsoft CLR stürzt es nie ab und läuft 1000-mal mit riesigen Datenmengen.

Einer unserer Jungs hat Miguel eine E-Mail geschickt und den Code angegeben, der das Problem verursacht hat. Noch keine Antwort. :(

Es scheint auch, dass viele andere Menschen auf dieses Problem ohne Lösung gestoßen sind - eine Lösung wurde vorgeschlagen, um Mono mit unterschiedlichen GC-Einstellungen neu zu kompilieren, aber dies scheint nur den Schwellenwert zu erhöhen, vor dem es abstürzt.

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

Dies hängt wirklich von den Namespaces und Klassen ab, die Sie aus dem .NET Framework verwenden. Ich hatte Interesse daran, einen meiner Windows-Dienste so zu konvertieren, dass er auf meinem E-Mail-Server ausgeführt wird, nämlich Suse, aber wir stießen auf mehrere harte Hindernisse mit APIs, die nicht vollständig implementiert wurden. Irgendwo auf der Mono-Website befindet sich eine Tabelle, in der alle Klassen und ihr Abschlussgrad aufgeführt sind. Wenn Ihre Bewerbung abgedeckt ist, dann machen Sie es.

Führen Sie wie bei jeder anderen Anwendung Prototyping und Tests durch, bevor Sie sich vollständig verpflichten.

Ein weiteres Problem, auf das wir gestoßen sind, ist lizenzierte Software: Wenn Sie auf die DLL einer anderen Person verweisen, können Sie sich nicht um Inkompatibilitäten herum codieren, die in dieser Assembly vergraben sind.

Ich würde mir dann vorstellen, wenn Sie eine Anwendung mit Komponenten von Drittanbietern haben, könnten Sie vollgestopft sein. Ich bezweifle, dass sich viele Anbieter mit Blick auf Mono entwickeln werden

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

Nein, Mono ist nicht bereit für ernsthafte Arbeit. Ich habe einige Programme unter Windows mit F # geschrieben und sie unter Mono ausgeführt. Diese Programme verwendeten Festplatte, Speicher und CPU ziemlich intensiv. Ich habe Abstürze in Monobibliotheken (verwalteter Code), Abstürze in nativem Code und Abstürze in der virtuellen Maschine gesehen. Wenn Mono funktionierte, waren die Programme mindestens zweimal langsamer als in .Net unter Windows und verwendeten viel mehr Speicher. Halten Sie sich für ernsthafte Arbeit von Mono fern.