Mono ist bereit für die prime time?[geschlossen]

https://stackoverflow.com/questions/18450

09-06-2019
|

Frage

Hat jemand verwendet, Mono, der open-source -.NET-Implementierung auf einer großen oder mittelgroßen Projekt?Ich Frage mich, ob es bereit für die Reale Welt, Produktions-Umgebungen.Ist es stabil, schnell, kompatibel, ...genug, um zu verwenden?Dauert es eine Menge Aufwand, um das port-Projekte, die Mono-runtime, oder ist es wirklich, wirklich kompatibel genug, einfach zu nehmen und führen bereits geschriebenen code für die Microsoft-Laufzeit?

Lösung

Es gibt eine Reihe von Szenarien zu betrachten:(a) wenn Sie bei der Portierung einer bestehenden Anwendung und Frage mich, ob Mono ist gut genug für diese Aufgabe;(b) Sie beginnt zu schreiben, neue code, und Sie möchten wissen, ob Mono reif genug ist.

Für den ersten Fall, Sie verwenden können die Mono Migration Analyzer (Moma) zu beurteilen, wie weit Ihre Anwendung vom laufen auf Mono.Wenn die Bewertung kommt zurück mit den fliegenden Farben, sollten Sie beginnen, auf Ihre Test-und QA und machen Sie sich bereit zu versenden.

Wenn Sie Ihre Bewertung kommt zurück mit einem Bericht highlighting features, die fehlen oder unterscheiden sich erheblich in Ihrer Semantik in Mono haben Sie, um zu bewerten, ob der code kann angepasst werden, umgeschrieben oder im schlimmsten Fall, ob Ihre Anwendung funktioniert mit eingeschränkter Funktionalität.

Nach unserer Moma-Statistiken, basierend auf Benutzer-Einreichungen (dies ist aus dem Gedächtnis) über 50% der Anwendungen aus der box, etwa 25% benötigen etwa eine Woche im Wert von Arbeit (refactoring, Adaption) in weiteren 15% erfordern eine ernsthafte Verpflichtung zu wiederholen Stücke von Ihrem code, und der rest ist einfach nicht Wert die Mühe zu portieren, da Sie so unglaublich gebunden Win32.An diesem Punkt, entweder Sie starten von null, oder eine geschäftliche Entscheidung die Mühe zu machen, Ihr code portabel, aber wir sprechen Monaten im Wert von Arbeit (zumindest aus den berichten, die wir haben).

Wenn Sie von vorne anfangen, ist die situation viel einfacher, da Sie nur über die APIs, die anwesend sind in Mono.Wie lange Sie bleiben mit der stack unterstützt (das ist ziemlich viel .NET 2.0, plus alle die core-upgrades, 3.5, darunter LINQ und System.Core plus Mono cross-Plattform-APIs) werden Sie in Ordnung sein.

Jeder einmal in eine Weile, Sie könnte Lauf in die bugs in Mono oder Einschränkungen, und Sie müssen möglicherweise an die Arbeit um Sie herum, aber das ist nicht anders als jedes andere system.

Wie für die Portabilität:ASP.NET Anwendungen sind einfacher, diejenigen zu Hafen, als diejenigen, die wenig bis keine Abhängigkeiten auf Win32 und Sie können sogar verwenden Sie SQL server oder anderen gängigen Datenbanken (es sind viele gebündelte Datenbank-Anbieter mit Mono).

Windows.Formen Portierung ist manchmal schwieriger, da Entwickler wie zu entkommen .NET-sandbox und P/Invoke-Ihre Gehirne aus zu konfigurieren Dinge, die so nützlich ist, wie das ändern der cursor blinkt rate ausgedrückt als zwei bezier-Punkte-codiert BCD-form in einem wParam.Oder einige junk-so.

Andere Tipps

Es hat eine ziemlich umfangreiche Abdeckung von bis zu .NET 4.0 und sogar einige features aus .NET 4.5-APIs, aber es gibt ein paar Bereiche, die wir nicht gewählt haben, zu implementieren aufgrund der APIs als veraltet, neue alternativen geschaffen werden oder der Umfang zu groß.Die folgenden APIs sind nicht verfügbar in Mono:

Windows Presentation Foundation
Windows Workflow Foundation (keine der beiden Versionen)
Entity Framework
Die WSE1/WSE2 "add-ons", um die standard-Web-Services-stack

Zusätzlich, unsere WCF-Implementierung beschränkt sich auf das Silverlight unterstützt.

Der einfachste Weg zu prüfen, ob Ihr bestimmtes Projekt zu führen Mono Migration Analyzer (MoMA).Der Vorteil ist, dass es teilt das Mono-team der Themen, die verhindert, dass Sie bei der Verwendung von Mono - (falls vorhanden), können Sie priorisieren Sie Ihre Arbeit.

Ich habe vor kurzem lief MoMA auf Unterschall und fand nur ein Problem - eine seltsame Verwendung von Nullable-Typen.Das ist eine große Codebasis, also die Abdeckung, es war ziemlich beeindruckend.

Mono ist im aktiven Gebrauch in mehrere kommerzielle als auch open source Produkte.Es ist im Gebrauch in einigen großen Anwendungen, wie Wikipedia und Mozilla Developer Center, und wurde in embedded-Anwendungen, wie den Sansa MP3-Player und versorgt Tausende von veröffentlichten spielen.

Bei den Sprachkenntnissen, die Mono-compiler ist voll kompatibel mit der C# 5.0 language-Spezifikation.

Auf der desktop-Seite, Mono funktioniert hervorragend, wenn Sie sich verpflichten, wobei GTK#.Die Windows.Formen der Umsetzung ist noch ein wenig buggy (zum Beispiel TrayIcon ist nicht arbeiten), aber es hat einen langen Weg zurückgelegt.Außerdem GTK# ist ein besseres toolkit als Windows Forms als es ist.

Auf der web-Seite, Mono implementiert hat genug von ASP.NET zur Ausführung der meisten Seiten perfekt.Die Schwierigkeit hier ist die Suche nach einem host, der über mod_mono installiert apache, oder es selbst tun, wenn Sie shell-Zugriff auf Ihren host.

Entweder Weg, Mono ist groß und stabil.

Wichtige Dinge zu erinnern, bei der Entwicklung von cross-Plattform-Programm:

Die Verwendung von GTK - # anstelle von Windows.Formen
Stellen Sie sicher, um ordnungsgemäß Fall Ihre Dateinamen
Verwenden Path.Separator instead of hardcoding "\", verwenden Sie auch Environment.NewLine statt "\n".
Verwenden Sie keine P/Aufgerufen Aufrufe von Win32-API.
Verwenden Sie nicht die Windows-Registry.

Ich persönlich benutze Mono in einer prime-time-env.Ich Laufe mono-Servern Umgang mit giga-Byte udp - /tcp-Daten-Verarbeitung-bezogenen Aufgaben und könnte nicht glücklicher sein.

Gibt es Besonderheiten, und eines der nervigsten Dinge ist, dass man nicht einfach "bauen" Ihre msbuild-Dateien aufgrund von Mono aktuellen Zustand:

MonoDevelop (die IDE) hat, teilweise msbuild-Unterstützung, aber im Grunde bork auf einen "ECHTEN" build-conf über eine einfache Hallo-Welt (benutzerdefinierte build-Aufgaben, dynamische "Eigenschaften" wie " $(SolutionDir), real-Konfiguration um ein paar zu nennen Sackgassen)
xbuild die Hätte die mono-geliefert-msbuild-voll kompatibel-build-system ist noch schrecklich, so erstellen über die Befehlszeile ist eigentlich ein schlechter Erfahrung, als über die GUI, die eine sehr "unorthodoxe" state of the union-für Linux-Umgebungen...

Nachdem/Während immer Ihre Sachen tatsächlich GEBAUT, sehen Sie vielleicht einige wildnis auch für die code, die unterstützt werden SOLLTEN, wie:

der compiler immer geschlafen auf bestimmte Konstrukte
und bestimmte erweiterte/neue .NET-Klassen werfen un-erwartet Mist auf Sie (XLinq jemand?)
einige unreife runtime "features" (3GB heap limit AUF x64...WTF!)

aber er begnügte sich, sagte, dass im Allgemeinen die Dinge anfangen zu arbeiten sehr schnell und Lösungen/workarounds sind reichlich vorhanden.

Nachdem Sie durchgegangen sind diese ersten Hürden genommen haben, meine Erfahrung ist, dass mono-FELSEN, und immer besser mit jeder iteration.

Ich habe Server läuft mit mono -, Verarbeitungs-300 GB Daten pro Tag, mit Tonnen von p/aufruft und in der Regel tun, eine MENGE Arbeit und bleiben UP für 5-6 Monate, auch mit der "bleeding edge" mono.

Hoffe, das hilft.

Die Empfehlungen für die akzeptierte Antwort ein wenig out-of-date jetzt.

Die windows forms-Implementierung ist ziemlich gut jetzt.(Siehe Paint-Mono für einen Hafen Paint.net das ist ein ziemlich aufwändiger Windows forms-Anwendung.Alles, was erforderlich war, war eine Emulationsschicht für einige der P-Invoke und nicht unterstützte Systemaufrufe).
Path.Kombinieren als auch als Pfad.Seperator zum zusammenschließen von Pfaden und Dateinamen.
Die windows Registry ist OK, solange Sie Sie nur für das speichern und abrufen von Daten aus Ihren Anwendungen (z.B.Sie können nicht Holen Sie sich alle Informationen zu Windows-von ihm, da ist es im Grunde eine Registrierung für Mono-Anwendungen).

Wenn Sie möchten, WPF verwenden Sie'rr Pech Mono hat derzeit keine Pläne, es zu implementieren.

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

Nun, mono Super, aber soweit ich sehen kann, es ist instabil.Es funktioniert, aber es Störungen geben, wenn Sie mono-Prozess eine schwere Arbeit zu tun.

TL;DR - verwenden Sie mono, wenn Sie :

verwenden AppDomains (Assembly Load\Unload) in Multithread-Umgebungen
Nicht verkraften können " lass-es-fail-Modell
Erfahrung gelegentlichen heavy-load-Ereignisse, die während des Prozesses ausgeführt werden

Also, zu den Fakten.

Wir verwenden mono-2.6.7 (.net v 3.5) auf RHEL5, Ubuntu, und zu meiner Sicht, es ist die meisten stabile version, gebaut von Novell.Sie hat ein Problem mit der Entladung AppDomains (segfaults), jedoch nicht sehr selten, und das, mit Abstand, ist akzeptabel (durch uns).

Okay.Aber wenn Sie wollen Funktionen .net 4.0, Sie haben zu Schalter auf Version 2.10.x oder 3.x, und das ist, wo die Probleme beginnen.

Im Vergleich zu 2.6.7, neue Versionen sind einfach nur inakzeptabel, verwendet werden.Ich schrieb ein einfaches stress-test-Anwendung, um tests mono-Installationen.

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

Es verwendet Thread-Pool Worker-Threads.Arbeiter lädt dll Anwendungsdomäne, und versucht zu tun, einige Mathe-arbeiten.Einige Arbeit ist, viele Threads, einige single ist.Fast alle arbeiten, die CPU-gebunden ist, obwohl es einige Lesen, die Dateien von der Festplatte.

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

sgen GC segfaults Prozess fast sofort
mono mit boehm lebt länger (2 bis 5 Stunden), aber segfaults schließlich

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

Für boehm segfauls - zum Beispiel (Ubuntu 13.04, mono, gebaut von der Quelle):

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 entnommen rpm hier 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 sind irgendwie mit AppDomains Logik, so dass Sie sollten bleiben Weg von Ihnen in mono.

BTW, getestet, Programm gearbeitet, 24 Stunden am Windows-Rechner in MS .NET 4.5 env, ohne scheitern.

So, zum Schluss, möchte ich sagen - use mono mit Vorsicht.Es funktioniert auf den ersten Blick, aber können leicht scheitern, wenn.Sie würde werden Links mit einer Reihe von core-dumps und großen glauben loss in Open-Source-Projekten.

MoMA ist ein großes Werkzeug für diese, wie jemand anderes vorgeschlagen.Die größten Quellen von Inkompatibilität in diesen Tagen sind Anwendungen, die DllImport (oder P/Invoke) in Win32-Bibliotheken.Einige Baugruppen sind nicht implementiert, aber die meisten von Ihnen sind nur Windows-und wirklich Sinn machen würde nicht auf Linux.Ich denke, es ist ziemlich sicher zu sagen, dass die meisten ASP.NET Anwendungen können auf Mono mit begrenzten änderungen.

(Offenlegung:Ich habe dazu beigetragen, Mono selbst, als auch die schriftliche apps, die im Vordergrund ausgeführt.)

In vielen Fällen, Sie können nehmen bestehenden code und führen Sie es einfach auf Mono, vor allem, wenn Sie die Portierung eines ASP.NET Anwendung.

In einigen Fällen können Sie erfordern ganz neue Abschnitte von code, damit es funktioniert.Wenn Sie System.Windows.Formen, für Beispiel, die Anwendung nicht funktionieren unverändert.Ebenso, wenn Sie die Verwendung jeglicher Windows-spezifischen code (registry-Zugriff-code, zum Beispiel).Aber ich denke, das Schlimmste Täter ist in der UI-code.Das ist besonders schlecht auf Macintosh-Systemen.

Wir benutzen es für ein Projekt hier bei der Arbeit, die nötig ist für die Ausführung auf Linux, aber einige Wiederverwendung .NET-Bibliotheken, die wir gebaut haben, die in Verwaltetem C++.Ich war sehr überrascht, wie gut es geklappt hat.Unser Hauptprogramm ist in C# geschrieben und wir können nur zu Referenz unsere Managed C++ - Binärdateien mit kein Problem.Der einzige Unterschied in der C# - code zwischen Windows und Linux ist RS232 serial port code.

Die einzige große Frage, die ich denken kann, geschah vor etwa einem Monat.Der Linux-build hatte ein Speicherverlust, der gesehen, war nicht auf dem Windows-build.Nach einer manuellen Entstörung (die basic-Profiler für Mono unter Linux nicht viel helfen), waren wir in der Lage, verengen Sie die Frage bis zu einem bestimmten Stück code.Wir landeten patching workaround, aber ich brauche noch einige Zeit, um zurück zu gehen und herauszufinden, was die Ursache des Lecks war.

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

Aus dem bisschen, dass ich mit gespielt, es schien relativ vollständig und fast brauchbar.Es hat einfach nicht ganz richtig Aussehen, in einigen Orten, und ist noch ein bisschen hit oder miss insgesamt.Es erstaunt mich, dass es auch funktioniert so wie es bei einigen Formularen, aber ehrlich.

Ja, es ist definitiv (wenn Sie vorsichtig sind, wenn) Wir unterstützen Mono-Ra-Ajax (Ajax-Bibliothek gefunden bei http://ra-ajax.org) und wir sind meistens nicht Probleme zu alle.Sie müssen vorsichtig sein, mit einigen der "verrücktesten Dinge" aus .Net wie WSE etc, und auch wohl einige wenige von Ihren vorhandenen Projekten wird nicht werden 100% Mono-kompatibel, aber neue Projekte beim testen während der Entwicklung meist ohne Probleme kompatibel mit Mono.Und das gewinnen von Unterstützung von Linux etc. durch Verwendung von Mono ist wirklich cool ;)

Ein großer Teil der geheimen Unterstützung Mono, denke ich, ist die Verwendung der richtigen tools von Anfang an, z.B.ActiveRecord, log4net, ra-ajax etc...

Für die Art der Anwendung, die wir bauen, Mono leider scheint das nicht für die Produktion bereit.Wir waren beeindruckt von der es insgesamt, und beeindruckte mit seiner Leistung sowohl auf Windows und auf EC2-Maschinen, aber unser Programm ist abgestürzt consistenly mit garbage collection-Fehler auf Windows-und linux.

Die Fehlermeldung ist:"schwerwiegender Fehler in der GC:zu viele Haufen Abschnitte", hier ist ein link zu jemand sonst das problem Auftritt, das in eine etwas andere Weise:

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

Das erste Stück code, den wir liefen in Mono war eine einfache Programmierung Herausforderung, der wir uns entwickelt hatte,...Der code lädt etwa 10 MB Daten in eine Daten-Strukturen (z.B.HashSets), dann läuft 10 Abfragen für die Daten.Wir liefen die Abfragen, die 100-mal, um Zeit und erhalten Sie einen monatlichen Durchschnitt.

Der code stürzte rund um 55th Abfrage auf Windows.Auf linux-es hat funktioniert, aber sobald wir zogen in eine größere Daten einstellen, es würde Abstürzen zu.

Dieser code ist sehr einfach, z.B.setzen Sie einige Daten in HashSets und dann die Abfrage von HashSets etc, alle native, c#, nichts unsicher, keine API-Aufrufe.Auf die Microsoft CLR, die es nie abstürzt, und läuft auf große Datenmengen 1000 mal nur in Ordnung.

Einer unserer Jungs, Miguel per E-Mail und enthalten den code, der das problem verursacht hat, keine Antwort noch.:(

Es scheint auch, wie viele andere Leute hatten dieses problem ohne Lösung - eine Lösung vorgeschlagen wurde, zu kompilieren, Mono mit verschiedenen GC-Einstellungen aber, die nur erscheint, erhöhen Sie den Schwellenwert, vor dem es abstürzt.

Überprüfen Sie einfach www.plasticscm.com.Alles (client -, server -, GUI -, merge-tools) ist auf mono.

Es hängt wirklich davon ab, die namespaces und Klassen, die Sie verwenden, aus dem .NET-framework.Ich hatte Interesse bei der Umwandlung einer meiner windows-Dienste laufen über meine E-Mail-server, Suse, aber wir lief in einige harte Hürden mit APIs, die bisher nicht vollständig umgesetzt.Es ist ein Diagramm, das sich irgendwo auf der Mono-website, die eine Liste aller Klassen und Ihre Ebene der Vollendung.Wenn Ihre Anwendung abgedeckt ist, dann gehen Sie für es.

Wie bei jeder anderen Anwendung, tun das prototyping und testen, bevor Sie eine vollständige Verpflichtung, natürlich.

Ein weiteres problem wir liefen in lizenzierten software:wenn Sie auf jemand anderes die DLL, die Sie nicht Programmieren kann, sich Ihren Weg durch Inkompatibilitäten, die begraben sind in dieser Baugruppe.

Ich könnte mir vorstellen dann, wenn Sie eine Anwendung mit einigen 3rd-party-Komponenten, die Sie gefüllt werden.Ich bezweifle, dass eine Menge von Anbietern entwickeln mit Mono mind

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

Nein, mono ist nicht bereit für ernsthafte Arbeit.Ich schrieb ein paar Programme, die unter Windows mit F# und lief Sie auf Mono.Diejenigen, die das Programm verwendet, Festplatte, Arbeitsspeicher und cpu-intensiv nutzt.Ich sah stürzt in mono-Bibliotheken (verwalteter code), stürzt in nativen code und Abstürze der virtuellen Maschine.Wenn "mono" arbeitete die Programme wurden mindestens zwei-mal langsamer als in .Net in Windows und verwendet viel mehr Speicher.Bleiben Sie Weg von mono für ernsthafte Arbeit.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow