Czy Mono jest gotowy na najwyższy czas? [Zamknięte]

Czy ktoś używał Mono, otwartej implementacji .NET w dużym lub średnim projekcie? Zastanawiam się, czy jest gotowy na rzeczywiste środowiska produkcyjne. Czy jest stabilny, szybki, kompatybilny ... wystarczający do użycia? Czy przeniesienie projektów do środowiska wykonawczego Mono wymaga dużo wysiłku, czy też jest naprawdę wystarczająco kompatybilne, aby po prostu pobrać i uruchomić już napisany kod środowiska wykonawczego Microsoft?

Należy wziąć pod uwagę kilka scenariuszy: (a) jeśli przenosisz istniejącą aplikację i zastanawiasz się, czy Mono jest wystarczająco dobry do tego zadania; (b) zaczynasz pisać nowy kod i chcesz wiedzieć, czy Mono jest wystarczająco dojrzały.

W pierwszym przypadku możesz użyć narzędzia Mono Migration Analyzer (Moma), aby ocenić, jak daleko Twoja aplikacja jest uruchomiona na Mono. Jeśli ocena powróci z jaskrawymi kolorami, powinieneś zacząć od testowania i kontroli jakości i przygotować się do wysyłki.

Jeśli twoja ocena wróci z raportem podkreślającym brakujące funkcje lub znacznie różniącymi się ich semantyką w Mono, będziesz musiał ocenić, czy kod może zostać dostosowany, przepisany lub, w najgorszym przypadku, czy Twoja aplikacja może działać ze zmniejszoną funkcjonalnością.

Według naszych statystyk Moma opartych na zgłoszeniach użytkowników (pochodzi z pamięci) około 50% aplikacji działa od razu po wyjęciu z pudełka, około 25% wymaga około tygodnia pracy (refaktoryzacja, dostosowanie), kolejne 15% wymaga poważnego zaangażowania w przerabiaj fragmenty kodu, a reszta nie jest po prostu warta kłopotania się z portowaniem, ponieważ są one tak niesamowicie powiązane z Win32. W tym momencie albo zaczynasz od zera, albo decyzja biznesowa zwiększy wysiłek, aby twój kod był przenośny, ale mówimy o pracy wartej miesięcy (przynajmniej z raportów, które mamy).

Jeśli zaczynasz od zera, sytuacja jest o wiele prostsza, ponieważ będziesz używać tylko interfejsów API obecnych w Mono. Tak długo, jak pozostaniesz przy obsługiwanym stosie (który jest właściwie .NET 2.0, plus wszystkie podstawowe aktualizacje 3.5, w tym LINQ i System.Core, a także dowolne interfejsy API między platformami Mono), wszystko będzie dobrze.

Co jakiś czas możesz napotykać błędy w trybie mono lub ograniczenia i być może będziesz musiał je obejść, ale nie różni się to od żadnego innego systemu.

Jeśli chodzi o przenośność: aplikacje ASP.NET są łatwiejsze do przeniesienia, ponieważ te mają niewielką lub żadną zależność od Win32, a nawet można używać serwera SQL lub innych popularnych baz danych (istnieje wiele dostawców baz danych w pakiecie z Mono).

Przenoszenie Windows.Forms jest czasem trudniejsze, ponieważ programiści lubią uciec z piaskownicy .NET i P / wywołują mózgi, aby skonfigurować rzeczy tak przydatne, jak zmiana częstotliwości migania kursora wyrażonej jako dwa punkty Béziera zakodowane w postaci BCD w wParam. Lub jakieś takie śmieci.

Ma dość obszerny zasięg do .NET 4.0, a nawet zawiera niektóre funkcje z interfejsów API .NET 4.5, ale jest kilka obszarów, których zdecydowaliśmy się nie wdrażać z powodu przestarzałych interfejsów API, tworzenia nowych alternatyw lub zbyt dużego zakresu duży. Następujące interfejsy API nie są dostępne w trybie Mono:

• Windows Presentation Foundation
• Windows Workflow Foundation (żadna z dwóch wersji)
• Entity Framework
• „Dodatki” WSE1 / WSE2 do standardowego stosu usług WWW

Ponadto nasza implementacja WCF jest ograniczona do obsługiwanego przez Silverlight.

Najłatwiejszym sposobem sprawdzenia określonego projektu jest uruchomienie Mono Migration Analyzer (MoMA) . Korzyścią jest to, że powiadomi zespół Mono o problemach, które uniemożliwiają korzystanie z Mono (jeśli w ogóle), co pozwala im ustalić priorytet swojej pracy.

Niedawno uruchomiłem MoMA na SubSonic i znalazłem tylko jeden problem - dziwne użycie typów Nullable. To duża baza kodów, więc zasięg był imponujący.

Mono jest aktywnie wykorzystywane w wielu produktach komercyjnych i open source . Jest używany w niektórych dużych aplikacjach, takich jak Wikipedia i Mozilla Developer Center , i był używany w aplikacjach wbudowanych, takich jak odtwarzacze MP3 Sansa, i obsługuje tysiące opublikowanych gier.

Na poziomie językowym kompilator Mono jest w pełni zgodny ze specyfikacją języka C # 5.0 .

Po stronie komputera Mono działa świetnie, jeśli zdecydujesz się na użycie GTK #. Implementacja Windows.Forms wciąż jest trochę wadliwa (na przykład TrayIcon nie działa), ale przeszła długą drogę. Poza tym GTK # jest lepszym zestawem narzędzi niż Windows Forms.

Po stronie internetowej, Mono zaimplementowało wystarczająco dużo platformy ASP.NET, aby doskonale uruchomić większość stron. Trudność polega na tym, aby znaleźć hosta, który ma mod_mono zainstalowany na Apache, lub zrobić to sam, jeśli masz dostęp do powłoki z hosta.

Tak czy inaczej, Mono jest świetny i stabilny.

Najważniejsze rzeczy do zapamiętania podczas tworzenia programu międzyplatformowego:

• Użyj GTK # zamiast Windows.Forms
• Upewnij się, aby poprawnie wpisać nazwy plików
• Użyj Path.Separatorzamiast na stałe "\", użyj także Environment.NewLinezamiast "\n".
• Nie używaj żadnych wywołań P / Invoked do Win32 API.
• Nie używaj rejestru systemu Windows.

Ja osobiście używam Mono w env w prime-time. Prowadzę serwery mono zajmujące się gigabajtami zadań związanych z przetwarzaniem danych udp / tcp i nie może być szczęśliwszy.

Istnieją osobliwości, a jedną z najbardziej irytujących rzeczy jest to, że nie można po prostu „zbudować” plików msbuild ze względu na obecny stan Mono:

• MonoDevelop (IDE) ma częściową obsługę msbuildów, ale w zasadzie rozwiąże każdą kompilację „PRAWDZIWĄ” poza prostym hello-world (niestandardowe zadania kompilacji, dynamiczne „właściwości”, takie jak $ (SolutionDir), prawdziwa konfiguracja, aby wymienić kilka martwych -kończy się)
• xbuild, który POWINNO być systemem dostarczanym mono-msbuild-w pełni kompatybilny-kompilacja-system jest jeszcze bardziej okropny, więc budowanie z linii poleceń jest w rzeczywistości gorszym doświadczeniem niż używanie GUI, co jest bardzo „niekonwencjonalnym” stanem unia dla środowisk Linux ...

Raz / w trakcie faktycznego budowania twoich rzeczy, możesz zobaczyć dzikie sekrety, nawet dla kodu, który POWINNO być obsługiwany, jak:

• kompilator dostaje bork na niektóre konstrukcje
• i niektóre bardziej zaawansowane / nowe klasy .NET rzucają w ciebie nieoczekiwanymi badziewiami (XLinq czy ktoś?)
• niektóre niedojrzałe „funkcje” środowiska wykonawczego (limit sterty 3 GB na x64 ... WTF!)

ale falujący powiedział, że ogólnie rzecz biorąc rzeczy zaczynają działać bardzo szybko, a rozwiązania / obejścia są obfite .

Po przejściu przez te początkowe przeszkody, moje doświadczenie jest takie, że mono ROCKS i staje się coraz lepsze z każdą iteracją .

Mam serwery działające w trybie mono, przetwarzające 300 GB danych dziennie, z tonami p / wywołań i ogólnie mówiąc, wykonują DUŻO pracy i pozostają w gotowości przez 5-6 miesięcy, nawet przy „krwawej mono”.

Mam nadzieję że to pomoże.

Zalecenia dotyczące przyjętej odpowiedzi są już trochę nieaktualne.

• Implementacja formularzy Windows jest teraz całkiem dobra. (Zobacz Paint-Mono, aby zapoznać się z portem Paint.net, który jest dość zaangażowaną aplikacją do tworzenia formularzy Windows. Wymagana była tylko warstwa emulacji dla niektórych P-Invoke i nieobsługiwanych wywołań systemowych).
• Path.Combine oraz Path.Seperator do łączenia ścieżek i nazw plików.
• Rejestr systemu Windows jest w porządku, o ile używasz go tylko do przechowywania i pobierania danych z aplikacji (tzn. Nie możesz uzyskać z niego żadnych informacji o systemie Windows, ponieważ jest to w zasadzie rejestr aplikacji Mono).

Jeśli chcesz korzystać z WPF, nie masz szczęścia Mono obecnie nie planuje go wdrożyć.

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

Cóż, mono jest świetne, ale o ile widzę, jest niestabilne. Działa, ale powoduje błędy, gdy proces monofoniczny wymaga poważnej pracy.

TL; DR - Nie używaj mono, jeśli:

• użyj AppDomains (zestaw Load \ Unload) w środowiskach wielowątkowych
• Nie można utrzymać modelu „niech to zawiedzie”
• Od czasu do czasu doświadczaj dużych obciążeń podczas przebiegu procesu

Więc fakty.

Używamy mono-2.6.7 (.net v 3.5) na RHEL5, Ubuntu i, z mojego punktu widzenia, jest to najbardziej stabilna wersja zbudowana przez Novell. Ma problem z rozładowaniem AppDomains (segfaults), jednak zawiesza się bardzo rzadko i jest to zdecydowanie dopuszczalne (przez nas).

W porządku. Ale jeśli chcesz korzystać z funkcji .net 4.0, musisz przełączyć się do wersji 2.10.x lub 3.x i tam zaczynają się problemy.

W porównaniu z wersją 2.6.7 nowe wersje są po prostu niedopuszczalne. Napisałem prostą aplikację do testów warunków skrajnych do testowania instalacji mono.

Jest tutaj, z instrukcją użycia: https://github.com/head-thrash/stress_test_mono

Używa wątków roboczych puli wątków. Pracownik ładuje bibliotekę DLL do AppDomain i próbuje wykonać pracę matematyczną. Część pracy jest wielowątkowa, część pojedyncza. Prawie cała praca jest związana z procesorem, chociaż niektóre odczyty plików z dysku.

Wyniki nie są bardzo dobre. W rzeczywistości dla wersji 3.0.12:

• sgen GC segfaulty przetwarzają prawie natychmiast
• mono z boehmem żyje dłużej (od 2 do 5 godzin), ale w końcu segfault

Jak wspomniano powyżej, sgen gc po prostu nie działa (mono zbudowany ze źródła):

* 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]

Jeśli chodzi o boehm segfauls - na przykład (Ubuntu 13.04, mono zbudowany ze źródła):

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

Lub (RHEL5, mono jest pobierane z rpm tutaj 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

Obie awarie są w jakiś sposób powiązane z logiką AppDomains, więc powinieneś trzymać się od nich z daleka w mono.

BTW, testowany program pracował bez żadnych problemów 24 godziny na komputerze z systemem Windows w MS .NET 4.5 env.

Podsumowując, chciałbym powiedzieć - ostrożnie używaj mono. Działa od pierwszego spojrzenia, ale może łatwo zawieść za każdym razem. Pozostanie ci kilka podstawowych zrzutów i poważna utrata wiary w projekty typu open source.

MoMA jest świetnym narzędziem do tego, jak sugerował ktoś inny. Największymi źródłami niezgodności są obecnie aplikacje, które DllImport (lub P / Invoke) do bibliotek Win32. Niektóre zestawy nie są zaimplementowane, ale większość z nich jest przeznaczona tylko dla systemu Windows i naprawdę nie miałaby sensu w systemie Linux. Myślę, że dość bezpiecznie jest powiedzieć, że większość aplikacji ASP.NET może działać na Mono z ograniczonymi modyfikacjami.

(Ujawnienie: Przyczyniłem się do samego Mono, a także do napisanych aplikacji, które działają na nim.)

W wielu przypadkach możesz pobrać istniejący kod i po prostu uruchomić go na Mono, szczególnie jeśli portujesz aplikację ASP.NET.

W niektórych przypadkach możesz potrzebować zupełnie nowych sekcji kodu, aby działał. Jeśli na przykład używasz System.Windows.Forms, aplikacja nie będzie działać bez modyfikacji. Podobnie jeśli używasz kodu specyficznego dla systemu Windows (na przykład kod dostępu do rejestru). Ale myślę, że najgorszym przestępcą jest kod interfejsu użytkownika. Jest to szczególnie złe w systemach Macintosh.

Używaliśmy go do pracującego tutaj projektu, który musiał działać w systemie Linux, ale wykorzystał ponownie niektóre biblioteki .NET, które zbudowaliśmy w Managed C ++. Byłem bardzo zaskoczony, jak dobrze się udało. Nasz główny plik wykonywalny jest napisany w języku C # i możemy bez problemu odwoływać się do naszych plików binarnych Managed C ++. Jedyną różnicą w kodzie C # między Windows a Linuksem jest kod portu szeregowego RS232.

Jedyny duży problem, o którym mogę pomyśleć, wydarzył się około miesiąca temu. Kompilacja Linuksa miała wyciek pamięci, którego nie widać w kompilacji Windows. Po ręcznym debugowaniu (podstawowe profile dla Mono w Linuksie niewiele pomogły), byliśmy w stanie zawęzić problem do określonej części kodu. Skończyło się załatanie obejścia, ale wciąż muszę znaleźć trochę czasu, aby wrócić i dowiedzieć się, jaka była pierwotna przyczyna wycieku.

Czy wiesz, jak dobra jest obsługa podglądu Mono 2.0 dla Windows Forms 2.0?

Z tego, z czym się bawiłem, wydawało się, że jest stosunkowo kompletny i prawie użyteczny. Po prostu nie wyglądało to dobrze w niektórych miejscach i wciąż jest trochę hitem lub chybił. Zadziwiło mnie, że działało tak samo dobrze, jak w przypadku niektórych naszych form, choć szczerze.

Tak, to zdecydowanie tak (jeśli jesteś ostrożny) Wspieramy Mono w Ra-Ajax (biblioteka Ajax znajduje się na stronie http://ra-ajax.org ) i przeważnie nie mamy żadnych problemów. Musisz być ostrożny z niektórymi „najbardziej szalonymi rzeczami” z .Net, takimi jak GPW itp., A także prawdopodobnie kilka z twoich istniejących projektów nie będzie w 100% kompatybilnych z Mono, ale nowe projekty, jeśli przetestujesz je podczas programowania, będą głównie być kompatybilnym bez problemów z Mono. A korzyść ze wsparcia Linuksa itp. Za pomocą Mono jest naprawdę świetna;)

Duża część sekretu obsługi Mono, myślę, że od samego początku używa odpowiednich narzędzi, np. ActiveRecord, log4net, ra-ajax itp.

Dla tego typu aplikacji, którą budujemy, Mono niestety nie wydaje się gotowe do produkcji. Byliśmy pod wrażeniem tego wszystkiego i byliśmy pod wrażeniem jego wydajności zarówno w systemie Windows, jak i na komputerach EC2, jednak nasz program konsekwentnie powodował awarie związane z odśmiecaniem pamięci w systemie Windows i Linux.

Komunikat o błędzie brzmi: „krytyczne błędy w GC: zbyt wiele sekcji sterty”, oto link do kogoś, kto doświadcza problemu w nieco inny sposób:

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

Pierwszy kawałek kodu, który uruchomiliśmy w Mono, to proste wyzwanie programistyczne, które opracowaliśmy ... Kod ładuje około 10 MB danych do niektórych struktur danych (np. HashSets), a następnie uruchamia 10 zapytań względem danych. Uruchomiliśmy zapytania 100 razy, aby je ustalić i uzyskać średnią.

Kod zawiesił się wokół 55. zapytania w systemie Windows. Na Linuksie działało, ale jak tylko przenieśliśmy się do większego zestawu danych, również się zawiesił.

Ten kod jest bardzo prosty, np. Umieść niektóre dane w HashSets, a następnie zapytaj o te HashSets itp., Wszystkie natywne c #, nic niebezpiecznego, brak wywołań API. Na Microsoft CLR nigdy się nie zawiesza i działa na ogromnych zestawach danych 1000 razy w porządku.

Jeden z naszych facetów przesłał Miguelowi wiadomość e-mail i podał kod, który spowodował problem, na razie brak odpowiedzi. :(

Wydaje się również, że wiele innych osób napotkało ten problem bez rozwiązania - zaproponowano jedno rozwiązanie, aby ponownie skompilować Mono z różnymi ustawieniami GC, ale wydaje się, że po prostu zwiększa próg, przed którym się zawiesza.

Wystarczy sprawdzić www.plasticscm.com. Wszystko (klient, serwer, GUI, narzędzia do scalania) jest napisane mono.

To naprawdę zależy od przestrzeni nazw i klas, których używasz ze środowiska .NET. Chciałem przekonwertować jedną z moich usług Windows do działania na moim serwerze pocztowym, którym jest Suse, ale natrafiliśmy na kilka twardych blokad z interfejsami API, które nie zostały w pełni zaimplementowane. Gdzieś na stronie Mono znajduje się tabela, która zawiera listę wszystkich klas i ich poziomu ukończenia. Jeśli Twoja aplikacja jest objęta ubezpieczeniem, wybierz ją.

Oczywiście, podobnie jak w przypadku każdej innej aplikacji, wykonaj prototypowanie i testy, zanim podejmiesz pełne zaangażowanie.

Innym problemem, na który natrafiliśmy, jest licencjonowane oprogramowanie: jeśli odwołujesz się do cudzej biblioteki DLL, nie możesz kodować obejścia niezgodności zakopanych w tym zestawie.

Wyobrażam sobie wtedy, że jeśli masz aplikację z niektórymi komponentami innych firm, możesz być wypchany. Wątpię, aby wielu sprzedawców rozwijało się z myślą o Mono

Przykład: http://community.devexpress.com/forums/p/55085/185853.aspx

Nie, mono nie jest gotowe do poważnej pracy. Napisałem kilka programów w systemie Windows przy użyciu F # i uruchomiłem je na Mono. Te programy dość intensywnie wykorzystywały dysk, pamięć i procesor. Widziałem awarie w bibliotekach mono (kod zarządzany), awarie w natywnym kodzie i awarie na maszynie wirtualnej. Kiedy mono działało, programy były co najmniej dwa razy wolniejsze niż w .Net w Windows i zużywały znacznie więcej pamięci. Trzymaj się z dala od mono za poważną pracę.