Mono birinci sınıf için hazır mı? [kapalı]

Herkes büyük veya orta ölçekli bir projede açık kaynaklı .NET uygulaması olan Mono'yu kullandı mı? Gerçek dünyaya, üretim ortamlarına hazır olup olmadığını merak ediyorum. İstikrarlı, hızlı, uyumlu, ... kullanmak için yeterli mi? Projeleri Mono çalışma zamanına taşımak çok çaba gerektiriyor mu, yoksa Microsoft'un çalışma zamanı için önceden yazılmış kodu alıp çalıştırmak için gerçekten, gerçekten uyumlu mu?

Dikkate alınması gereken birkaç senaryo vardır: (a) mevcut bir uygulamayı taşıyorsanız ve Mono'nun bu görev için yeterince iyi olup olmadığını merak ediyorsanız; (b) yeni bir kod yazmaya başlıyorsunuz ve Mono'nun yeterince olgun olup olmadığını öğrenmek istiyorsunuz.

İlk durumda, uygulamanızın Mono'da ne kadar çalıştığını değerlendirmek için Mono Migration Analyzer aracını (Moma) kullanabilirsiniz. Değerlendirme uçan renklerle geri gelirse, testinize ve KG'ye başlamalı ve gönderilmeye hazır olmalısınız.

Değerlendirmeniz Mono'daki anlambiliminde eksik veya önemli ölçüde farklılık gösteren özellikleri vurgulayan bir raporla birlikte gelirse, kodun uyarlanıp uygulanamayacağını, yeniden yazılabileceğini veya en kötü durumda uygulamanızın işlevselliği azaltıp azaltamayacağını değerlendirmeniz gerekecektir.

Kullanıcı gönderimlerine (bu bellekten) dayalı Moma istatistiklerimize göre, uygulamaların yaklaşık% 50'si kutudan çıkar, yaklaşık% 25'i bir haftalık çalışma gerektirir (yeniden düzenleme, uyarlama),% 15'i ciddi bir taahhüt gerektirir kodunuzu yeniden yapın ve gerisi Win32 için inanılmaz derecede bağlı oldukları için geri çekmeye değmez. Bu noktada, ya sıfırdan başlarsınız ya da bir işletme kararı, kodunuzu taşınabilir hale getirme çabasını yönlendirir, ancak aylarca çalışmadan bahsediyoruz (en azından sahip olduğumuz raporlardan).

Sıfırdan başlıyorsanız, durum çok daha basittir, çünkü yalnızca Mono'da bulunan API'ları kullanacaksınız. Desteklenen yığınla kaldığınız sürece (ki hemen hemen .NET 2.0, ayrıca LINQ ve System.Core dahil olmak üzere 3.5'teki tüm temel yükseltmeler ve Mono çapraz platform API'lerinden herhangi biri) iyi olacaksınız.

Arada bir Mono ya da sınırlamalarda hatalarla karşılaşabilirsiniz ve bunların etrafında çalışmanız gerekebilir, ancak bu diğer sistemlerden farklı değildir.

Taşınabilirlik gelince: ASP.NET uygulamaları, Win32 üzerinde çok az bağımlılığa sahip olan veya hiç bağımlı olmayan ve hatta SQL sunucusunu veya diğer popüler veritabanlarını (Mono ile birlikte paketlenmiş veritabanı sağlayıcıları da vardır) kullanabildiğinden, bağlantı noktası daha kolay olanlardır.

Windows.Forms porting bazen daha zordur çünkü geliştiriciler .NET sanal alanından kaçmayı sever ve P / B / wBaram'da BCD formunda kodlanmış iki bezier noktası olarak ifade edilen imleç yanıp sönme oranını değiştirme gibi yararlı şeyler yapılandırmak için beyinlerini çağırırlar. Ya da böyle bir ıvır zıvır.

.NET 4.0'a kadar oldukça kapsamlı bir kapsama sahip ve hatta .NET 4.5 API'lerinden bazı özellikler içeriyor, ancak API'lerin kullanımdan kaldırılması, yeni alternatifler yaratılması veya kapsamın çok fazla olması nedeniyle uygulamak istemediğimiz birkaç alan var. büyük. Aşağıdaki API'lar Mono'da mevcut değildir:

• Windows Presentation Foundation
• Windows Workflow Foundation (iki sürümden hiçbiri)
• Varlık Çerçevesi
• WSE1 / WSE2 standart Web Hizmetleri yığınına "eklentiler"

Ayrıca, WCF uygulamamız Silverlight'ın desteklediğiyle sınırlıdır.

Özel projenizi kontrol etmenin en kolay yolu Mono Migration Analyzer'ı (MoMA) çalıştırmaktır . Bunun yararı, Mono ekibine Mono'yu (varsa) kullanmanızı engelleyecek ve çalışmalarına öncelik vermelerini sağlayacak sorunları bildirmesidir.

Son zamanlarda MoMA'yı SubSonic üzerinde çalıştırdım ve sadece bir sorun buldum - Nullable türlerinin garip bir kullanımı. Bu büyük bir kod tabanı, bu yüzden kapsama alanı oldukça etkileyiciydi.

Mono, çeşitli ticari ve açık kaynaklı ürünlerde aktif olarak kullanılmaktadır . Wikipedia ve Mozilla Geliştirici Merkezi gibi bazı büyük uygulamalarda kullanılmaktadır ve Sansa MP3 çalarlar gibi gömülü uygulamalarda kullanılmıştır ve binlerce yayınlanmış oyunu desteklemektedir.

Dil düzeyinde, Mono derleyici C # 5.0 dil spesifikasyonuyla tamamen uyumludur .

GTK # kullanmayı taahhüt ederseniz, masaüstü tarafında Mono harika çalışıyor. Windows.Forms uygulaması hala biraz hatalı (örneğin, TrayIcon'un çalışmıyor) ama çok yol kat etti. Ayrıca GTK #, Windows Forms'dan daha iyi bir araç takımıdır.

Web tarafında, Mono çoğu siteyi mükemmel şekilde çalıştırmak için yeterince ASP.NET uyguladı. Buradaki zorluk, apache'de mod_mono yüklü bir ana bilgisayar bulmak veya ana makinenize kabuk erişiminiz varsa bunu kendiniz yapmaktır.

Her iki durumda da, Mono harika ve kararlı.

Çapraz platform programı oluştururken hatırlanması gereken önemli noktalar:

• Windows yerine GTK # kullanın.
• Dosya adlarınızı doğru şekilde kullandığınızdan emin olun
• Kullanım Path.Separatoryerine değişmeyeceği varsayılan "\"ayrıca kullanmak, Environment.NewLineyerine "\n".
• Win32 API için P / Invoked çağrıları kullanmayın.
• Windows Kayıt Defterini kullanmayın.

Şahsen Mono'yu bir prime time env'de kullanıyorum. Ben udp / tcp veri işleme ile ilgili görevler giga-bayt ile ilgili mono sunucular çalıştırın ve daha mutlu olamazdı.

Tuhaflıklar var ve en sinir bozucu şeylerden biri, Mono'nun şu anki durumu nedeniyle msbuild dosyalarınızı "oluşturamazsınız":

• MonoDevelop (IDE) bazı kısmi msbuild desteğine sahiptir, ancak basit bir merhaba dünyanın ötesinde herhangi bir "REAL" yapısında (özel inşa görevleri, $ (SolutionDir) gibi dinamik "özellikler", birkaç ölü adını vermek için gerçek yapılandırma) -ends)
• mono-sağlanan-msbuild-tam uyumlu-inşa-sistemi olması gereken xbuild daha da korkunçtur, bu yüzden komut satırından bina aslında GUI'yi kullanmaktan daha kötü bir deneyimdir, ki bu çok "alışılmadık" bir durumdur. Linux ortamları birliği ...

Bir kez / Eşyalarınızı gerçekten OLUŞTURURKEN, aşağıdaki gibi desteklenmesi gereken kodlar için bile bazı vahşi durumlar görebilirsiniz:

• derleyici belirli yapılarda dalgalanıyor
• ve size beklenmedik bir saçmalık getiren bazı daha gelişmiş / yeni .NET sınıfları (XLinq kimse?)
• bazı olgunlaşmamış çalışma zamanı "özellikleri" (3 GB yığın sınırı AÇIK x64 ... WTF!)

ancak kabarma, genel olarak konuşulan şeylerin çok hızlı çalışmaya başladığını ve çözümlerin / geçici çözümlerin bol olduğunu söyledi .

İlk engelleri aştığında, benim deneyimim mono ROCKS ve her yinelemede daha iyi olmaya devam ediyor .

Mono ile çalışan, tonlarca p / invokes ile günde 300GB veri işleyen ve genellikle "kanama kenarı" mono bile olsa, çok fazla iş yapıyor ve 5-6 ay kadar kalmak sunucuları vardı.

Bu yardımcı olur umarım.

Kabul edilen cevap için öneriler şu anda biraz güncel değil.

• Windows form uygulaması şimdi oldukça iyi. ( Oldukça ilgili bir Windows form uygulaması olan Paint.net bağlantı noktası için Paint-Mono'ya bakın . Gereken tek şey, bazı P-Invoke ve desteklenmeyen sistem çağrıları için bir öykünme katmanıydı).
• Path.Combine yanı sıra yolları ve dosya adlarına katılmak için Path.Seperator.
• Windows Kayıt Defteri, uygulamalarınızdaki verileri depolamak ve almak için kullandığınız sürece Tamamdır (yani, temel olarak Mono uygulamaları için bir kayıt defteri olduğundan, Windows hakkında herhangi bir bilgi alamazsınız).

WPF kullanmak istiyorsanız, şanssızsınız Mono'nun şu anda bunu uygulamak için bir planı yok.

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

Mono harika, ama görebildiğim kadarıyla kararsız. Çalışır, ancak mono işleme ciddi bir çalışma yaptığınızda hata yapar.

TL; DR - Aşağıdaki durumlarda mono kullanmayın:

• çok iş parçacıklı ortamlarda AppDomains (Assembly Load \ Unload) kullanın
• 'Başarısız olsun' modelini sürdüremiyorum
• Proses çalışması sırasında zaman zaman ağır yük olaylarını deneyimleyin

Yani, gerçekler.

RHEL5, Ubuntu üzerinde mono-2.6.7 (.net v 3.5) kullanıyoruz ve benim görüşüme göre Novell tarafından üretilen en kararlı sürüm. Unloading AppDomains (segfaults) ile ilgili bir sorunu var, ancak çok nadiren başarısız oluyor ve bu, (bizim tarafımızdan) kabul edilebilir.

Tamam. Ancak .net 4.0'ın özelliklerini kullanmak istiyorsanız, 2.10.x veya 3.x sürümlerine geçmelisiniz ve sorunların başladığı yer burasıdır.

2.6.7 ile karşılaştırıldığında, yeni sürümlerin kullanılması kabul edilemez. Mono kurulumları test etmek için basit bir stres testi uygulaması yazdım.

Kullanım talimatları ile burada: https://github.com/head-thrash/stress_test_mono

İş parçacığı havuzu alt iş parçacığı kullanır. İşçi AppDomain için dll yükler ve bazı matematik işi yapmaya çalışır. Bazı işler çok iş parçacıklı, bazıları bekar. Diskten bazı dosyalar okunmasına rağmen, hemen hemen tüm işler CPU'ya bağlıdır.

Sonuçlar çok iyi değil. Aslında, 3.0.12 sürümü için:

• sgen GC segfaults neredeyse anında işlemektedir
• Boehm'li mono daha uzun yaşar (2 ila 5 saat arasında), ancak sonunda segfaultlar

Yukarıda belirtildiği gibi, sgen gc sadece işe yaramaz (mono kaynağından inşa edilmiştir):

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

Boehm segfauls'a gelince - örneğin (Ubuntu 13.04, kaynaktan oluşturulmuş mono):

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

Veya (RHEL5, mono rpm'den 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

Her iki hata da bir şekilde AppDomains mantığına bağlıdır, bu nedenle onlardan mono olarak uzak durmalısınız.

BTW, test edilmiş program, MS .NET 4.5 env'de Windows makinesinde 24 saat sorunsuz çalıştı.

Sonuç olarak şunu söylemek isterim - mono'yu dikkatli kullanın. İlk bakışta çalışır, ancak her zaman kolayca başarısız olabilir. Bir sürü çekirdek döküm ve açık kaynak projelerinde büyük bir inanç kaybınız olacak.

Başka birinin önerdiği gibi MoMA bunun için harika bir araçtır. Günümüzde en büyük uyumsuzluk kaynakları, Win32 kütüphanelerine DllImport (veya P / Invoke) uygulayan uygulamalardır. Bazı derlemeler uygulanmaz, ancak çoğu yalnızca Windows'tur ve Linux'ta gerçekten mantıklı değildir. Çoğu ASP.NET uygulamasının Mono üzerinde sınırlı değişikliklerle çalışabileceğini söylemek oldukça güvenli olduğunu düşünüyorum.

(Açıklama: Mono'nun kendisine ve ayrıca üzerinde çalışan yazılı uygulamalara katkıda bulundum.)

Çoğu durumda, özellikle bir ASP.NET uygulaması taşıyorsanız, mevcut kodu alıp Mono üzerinde çalıştırabilirsiniz.

Bazı durumlarda, çalışmasını sağlamak için tamamen yeni kod bölümlerine gereksinim duyabilirsiniz. Örneğin, System.Windows.Forms kullanırsanız, uygulama değiştirilmeden çalışmaz. Aynı şekilde, Windows'a özel herhangi bir kod (örneğin, kayıt defteri erişim kodu) kullanıyorsanız. Ama en kötü suçlunun UI kodu olduğunu düşünüyorum. Bu özellikle Macintosh sistemlerinde kötüdür.

Burada, Linux'ta çalışması gereken, ancak Yönetilen C ++ ile oluşturduğumuz bazı .NET kitaplıklarını yeniden kullanan bir proje için kullanıyoruz. Ne kadar iyi çalıştığına çok şaşırdım. Bizim ana çalıştırılabilir C # yazılıyor ve biz sadece Yönetilen C ++ ikili dosyaları hiçbir sorun ile başvurulabilir. Windows ve Linux arasındaki C # kodundaki tek fark RS232 seri port kodudur.

Düşünebildiğim tek büyük sorun yaklaşık bir ay önce oldu. Linux derlemesinde, Windows derlemesinde görülmeyen bir bellek sızıntısı vardı. Bazı manuel hata ayıklamalarını yaptıktan sonra (Linux'ta Mono için temel profiller çok yardımcı olmadı), sorunu belirli bir kod grubuna indirgedik. Bir geçici çözüm ekledik, ancak yine de geri dönüp sızıntının temel nedeninin ne olduğunu bulmak için biraz zaman bulmam gerekiyor.

Mono 2.0 önizleme desteğinin Windows Forms 2.0 için ne kadar iyi olduğunu biliyor musunuz?

Onunla oynadığım birazdan, nispeten tam ve neredeyse kullanılabilir görünüyordu. Sadece bazı yerlerde oldukça doğru bakmadı ve hala biraz vurmak ya da genel özledim. Dürüst olmak gerekirse, bazı formlarımızda olduğu gibi çalıştığı beni de şaşırttı.

Evet kesinlikle (yine de dikkatli olursanız) Ra-Ajax'ta ( http://ra-ajax.org adresinde bulunan Ajax kütüphanesi) Mono'yu destekliyoruz ve çoğunlukla hiç sorun yaşamıyoruz. WSE vb. Mono ile sorunsuz bir şekilde uyumlu olun. Ve Mono kullanarak Linux vb.'yi desteklemekten kazanç gerçekten harika;)

Sanırım Mono'yu desteklemenin sırrının büyük bir kısmı doğru araçları en baştan kullanmaktır, örneğin ActiveRecord, log4net, ra-ajax vb.

Yaptığımız uygulama türü için Mono maalesef üretime hazır görünmüyor. Genel olarak bundan etkilendik ve hem Windows hem de EC2 makinelerindeki performansından etkilendik, ancak programımız hem Windows hem de Linux'ta çöp toplama hatalarıyla tutarlı bir şekilde çöktü.

Hata iletisi: "GC'deki önemli hatalar: çok fazla yığın bölümü", sorunu biraz farklı bir şekilde yaşayan başka birine bir bağlantı:

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

Mono'da çalıştırdığımız ilk kod parçası, geliştirdiğimiz basit bir programlama zorluğuydu ... Kod, bazı veri yapılarına (örn. HashSets) yaklaşık 10mb veri yükler, ardından verilere karşı 10 sorgu çalıştırır. Sorguları zamanlamak ve ortalama almak için 100 kez çalıştırdık.

Kod, Windows'taki 55. sorgunun etrafında çöktü. Linux'ta işe yaradı, ancak daha büyük bir veri kümesine taşındığımız anda da çökecekti.

Bu kod çok basit, örneğin HashSets içine bazı veriler koymak ve daha sonra bu HashSets vb, tüm yerel c #, güvenli olmayan bir şey, hiçbir API çağrıları sorgu. Microsoft CLR'de asla çökmez ve büyük veri kümelerinde 1000 kez iyi çalışır.

Adamlarımızdan biri Miguel'e e-posta gönderdi ve soruna neden olan kodu henüz yanıtlamadı. :(

Diğer birçok insan da bu sorunu çözümsüz olarak görmüş gibi görünüyor - Mono'yu farklı GC ayarlarıyla yeniden derlemek için bir çözüm önerildi, ancak bu, daha önce çöktüğü eşiği artırdığı görülüyor.

Sadece www.plasticscm.com adresini kontrol edin. Her şey (istemci, sunucu, GUI, birleştirme araçları) mono üzerine yazılır.

Bu gerçekten .NET çerçevesinden kullandığınız ad alanlarına ve sınıflara bağlıdır. Windows hizmetlerimden birini Suse olan e-posta sunucumda çalışacak şekilde dönüştürmeye ilgi duydum, ancak tamamen uygulanmayan API'larla birkaç zor engelle karşılaştık. Mono web sitesinde, tüm sınıfları ve tamamlanma seviyelerini listeleyen bir grafik var. Başvurunuz kapsanıyorsa, devam edin.

Diğer tüm uygulamalar gibi, elbette tam bir taahhütte bulunmadan önce prototipleme ve test yapın.

Karşılaştığımız başka bir sorun lisanslı yazılımdır: Başkasının DLL'sine başvuruyorsanız, bu derlemede gömülü olan uyumsuzluklar konusunda yolunuzu kodlayamazsınız.

Sonra bazı üçüncü taraf bileşenleri ile bir uygulama varsa doldurulmuş olabilir hayal ediyorum. Mono düşünülerek çok fazla tedarikçi geliştirileceğinden şüpheliyim

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

Hayır, mono ciddi çalışmaya hazır değil. Windows'ta F # kullanarak birkaç program yazdım ve Mono'da çalıştırdım. Bu program oldukça yoğun bir şekilde disk, bellek ve cpu kullandı. Mono kitaplıklarda (yönetilen kod) çökmeler, yerel kodda çökmeler ve sanal makinede çökmeler gördüm. Mono çalıştığında, programlar Windows'ta .Net'ten en az iki kat daha yavaştı ve çok daha fazla bellek kullandı. Ciddi işler için monodan uzak durun.