Mono sık sık “Evet, .NET platformlar arası” demek için kullanılır. Bu iddia ne kadar geçerli? [kapalı]

Bu süre zarfında, projeniz için .NET ile Java arasında ne tercih edersiniz? "Her zaman Windows'a dağıtabilecek misiniz?" Yeni bir web projesinde öne çıkan en önemli teknik karar ve cevabı "hayır" ise, Java yerine Java'yı tavsiye ederim.

Çok yaygın bir karşı-argüman şu ki, "Eğer Linux / OS X / Ne olursa olsun çalıştırmak istiyorsak, sadece Mono'yu çalıştıracağız" ¹ , ki bu da yüzeyde çok zorlayıcı bir argüman. nedenler.

• OpenJDK ve JVM'lerin tedarik ettiği tüm satıcı, işlerin doğru bir şekilde çalışmasını sağlamak için resmi Sun TCK'yı geçti. Mono’nun bir Microsoft TCK’yı geçtiğini bilmiyorum.
• Mono .NET sürümlerini takip eder. Hangi .NET düzeyi şu anda tam olarak desteklenmektedir?
• Tüm GUI öğeleri (WinForms?) Mono'da düzgün çalışıyor mu?
• İşletmeler, resmi B planı olan Açık Kaynaklı çerçevelere bağlı kalmak istemeyebilir.

Ben Oracle tarafından Java'nın yeni yönetim ile, gelecek güvensiz olduğunun farkındayım, ama örneğin IBM, birçok platform için JDK 's sağlar Linux dahil. Açık kaynaklı değiller.

Peki, Mono hangi durumlarda .NET uygulamaları için geçerli bir iş stratejisidir?

¹ _{Mark H bunu şöyle özetledi : "Eğer iddia " .NET'te yazılmış bir Windows uygulamam var, mono üzerinde çalışmalı " dır , öyleyse geçerli değil, ancak geçerli bir iddia değil - Mono bu tür uygulamaları taşımak için çaba gösterdi daha basit."}

Sparkie'nin cevabı anladım, biraz tamamlayayım.

".NET, platformlar arasıdır", hem çerçeve hem de başlangıçta yaratıldığı dünya değiştiği ve geliştiği için çok belirsiz bir ifadedir.

Kısa cevap:

.NET ve türevlerine, Ortak Dil Altyapısı Standardı'na güç veren temel motor çapraz platformdur ve kodunuzu birden fazla platforma yönlendirmek istiyorsanız, doğru API'leri doğru platformda sunmayı planlamanız gerekir. Her platformda en iyi deneyim.

CLI ailesi "Bir Kez Yaz, Herhangi Bir Yere Çalıştır" yaklaşımını denememiştir, çünkü bir telefondan ana bilgisayara olan farklar çok büyüktür. Bunun yerine, geliştiricilere her platformda harika deneyimler oluşturmak için doğru araçları sağlamak için platforma özgü bir API ve çalışma zamanı özellikleri evreni ortaya çıkmıştır .

Bir düşünün: programcılar artık Windows PC'leri veya Unix Sunucularını hedef almıyor. Dünya şimdi her zamankinden daha fazla bilgisayarlardan, oyun konsollarına, güçlü telefonlara, set üstü kutulara, büyük sunuculara ve dağıtılmış makine kümelerine kadar büyüleyici platformlarla çevrilidir. Tüm platformlara uyan tek beden, yalnızca küçük cihazlarda şişkin hisseder ve büyük sistemlerde güçsüz hisseder .

Microsoft'un .NET Framework ürünü çapraz platform değildir, yalnızca Windows'ta çalışır. .NET Framework'ün Microsoft'tan Windows Phone 7, XBox360 ve Silverlight aracılığıyla tarayıcılar gibi diğer sistemlerde çalışan varyasyonları var, ancak hepsi biraz farklı profiller.

Bugün her büyük ana işletim sistemi, telefon, mobil cihaz, gömülü sistem ve sunucuyu .NET tabanlı teknolojilerle hedefleyebilirsiniz. Her durumda hangi CLI uygulamasını kullanacağınızı gösteren bir liste (bu liste kapsamlı değildir, ancak vakaların% 99'unu kapsamalıdır):

• x86 ve x86-64 tabanlı PC bilgisayarları:
  • Windows çalıştırma -> Genelde .NET veya Silverlight kullanıyorsunuz ancak burada tam Mono'yu da kullanabilirsiniz.
  • Linux, BSD veya Solaris kullanıyorsanız -> Tam Mono veya Silverlight kullanıyorsunuz
  • MacOS X kullanıyorsanız -> Tam Mono veya Silverlight kullanıyorsunuz
  • Android -> Mono / Android altkümesini çalıştırıyorsun
• ARM bilgisayarlar:
  • Windows Phone 7’yi Çalıştırmak: Compact Framework 2010’u çalıştırıyorsunuz
  • Windows 6.5 ve daha eski sürümleri çalıştırıyorsanız: eski Compact Framework'ü çalıştırıyorsunuz
  • Android cihazlar: Mono / Android kullanıyorsunuz
• PowerPC bilgisayarlar:
  • Tam Linux, BSD veya Unix işletim sistemleri için Mono kullanıyorsunuz
  • PS3, Wii veya diğer gömülü sistemler için gömülü Mono çalıştırıyorsunuz.
  • XBox360'da CompactFramework'u çalıştırıyorsunuz
• S390, S390x, Itanium, SPARC bilgisayarlar:
  • Sen tam Mono koş
• Diğer gömülü işletim sistemleri:
  • Mobil profilde .NET MicroFramework veya Mono kullanıyorsunuz.

İhtiyaçlarınıza bağlı olarak yukarıdakiler yeterli olabilir veya olmayabilir. Her yerde çalıştırmak için aynı kaynak kodunu pek elde edemezsiniz. Örneğin, XNA kodu her masaüstünde çalışmaz, .NET Desktop yazılımı ise XNA veya telefonda çalışmaz. Genellikle .NET Framework'ün diğer profillerinde çalıştırmak için kodunuzda değişiklik yapmanız gerekir. İşte bildiğim profillerden bazıları:

• .NET 4.0 Profili
• Silverlight Profili
• Windows Phone 7 Profili
• XBox360 Profili
• Mono çekirdek Profili - .NET profilini takip eder ve Linux, MacOS X, Solaris, Windows ve BSD'de kullanılabilir.
• .NET Micro Framework
• İPhone profilinde Mono
• Android Profilindeki Mono
• PS3'deki Mono Profili
• Wii Profilindeki Mono
• Mehtap profili (Silverlight ile uyumlu)
• Mehtap genişletilmiş profil (Silverlight + tam .NET 4 API erişimi)

Yani bu profillerin her biri aslında biraz farklı ve bu kötü bir şey değil. Her profil kendi ana platformuna uyacak ve mantıklı olan API'leri gösterecek ve mantıklı olmayanları kaldıracak şekilde tasarlanmıştır.

Örneğin, Silverlight'ın ana bilgisayar tarayıcısını denetleme API'leri telefonda bir anlam ifade etmiyor. Ve XNA'daki gölgelendiriciler, eşdeğer desteği olmayan PC donanımı hakkında hiçbir şey ifade etmiyor.

.NET'in geliştiriciyi donanımın ve yerel platformun temel özelliklerinden izole etmenin bir çözümü olmadığını ne kadar erken fark ederseniz, o kadar iyi olursunuz.

Başlangıcında, bazı API'ler ve yığınlar birden fazla platformda mevcuttur, örneğin ASP.NET, Windows'ta, Linux'ta, Solaris'te MacOS X'de kullanılabilir çünkü bu API'ler hem .NET hem de Mono'da mevcuttur. ASP.NET, Microsoft'un XBox veya Windows Phone 7 gibi desteklenen platformlarında bulunmaz ve Mono'nun Wii veya iPhone gibi desteklediği diğer platformlarda desteklenmez.

Aşağıdaki bilgiler sadece 21 Kasım itibariyle doğrudur ve Mono dünyasında birçok şey muhtemelen değişecektir.

Aynı ilkeler diğer yığınlara da uygulanabilir, tam bir liste burada nasıl sunulacağı hakkında hiçbir fikrim olmayan uygun bir tabloya ihtiyaç duyar, ancak burada belirli bir platformda bulunmayabilecek teknolojilerin bir listesi vardır. Burada listelenmeyen bir şey olduğunu varsayabilirsin (kaçırdığım şeyler için bana düzenlemeler göndermekten çekinmeyin):

Core Runtime Engine [her yerde]

• Reflection.Emit Desteği [WP7, CF, Xbox, MonoTouch, PS3 hariç her yerde]
• CPU SIMD desteği [Linux, BSD, Solaris, MacOS X; Yakında PS3, MonoTouch ve MonoDroid]
• Devam Ediyor - Mono.Tasklets [Linux, BSD, Solaris, MacOS, PS3, Wii]
• Montaj Boşaltma [Sadece Windows]
• VM Enjeksiyonu [Linux, BSD, MacOS X, Solaris]
• DLR [Windows, Linux, MacOS X, Solaris, MonoDroid]
• Jenerikler [PS3 ve iPhone'da bazı sınırlamalar].

Diller

• C # 4 [her yerde]
• C # Bir Hizmet Olarak Derleyici (Linux, MacOS, Solaris, BSD, Android)
• IronRuby [her yerde, WP7, CF, Xbox, MonoTouch, PS3 uygulama]
• IronPython [her yerde, WP7, CF, Xbox, MonoTouch, PS3 uygulama]
• F # [her yerde, WP7, CF, Xbox, MonoTouch, PS3 uygulayın]

Sunucu Yığınları

• ASP.NET [Windows, Linux, MacOS, BSD, Solaris]
• ADO.NET [her yerde]
• LINQ to SQL [her yerde]
• Varlık Çerçevesi [her yerde]
• Çekirdek XML yığını [her yerde]
  • XML serileştirme [WP7, CF, Xbox hariç her yer)
• LINQ to XML (her yerde)
• System.Json [Silverlight, Linux, MacOS, MonoTouch, MonoDroid]
• System.Messaging [Windows; Linux'ta MacOS ve Solaris RabbitMQ gerektirir]
• .NET 1 Kurumsal Hizmetler [Yalnızca Windows]
• WCF [Windows'ta tamamlandı; Silverlight, Solaris, MacOS, Linux, MonoTouch, MonoDroid üzerinde küçük alt kümeler]
• Windows İş Akışı [Sadece Windows]
• Kart alanı kimliği [Yalnızca Windows]

GUI yığınları

• Silverlight (Windows, Mac, Linux - Ay Işığı ile)
• WPF (yalnızca Windows)
• Gtk # (Windows, Mac, Linux, BSD)
• Windows.Forms (Windows, Mac, Linux, BSD)
• MonoMac - Yerel Mac Entegrasyonu (yalnızca Mac)
• MonoTouch - Yerel iPhone Entegrasyonu (yalnızca iPhone / iPad)
• MonoDroid - Yerel Android Entegrasyonu (Sadece Android)
• Media Center API'leri - yalnızca Windows
• Dağınıklığı (Windows ve Linux)

Grafik Kütüphaneleri

• GDI + (Windows, Linux, BSD, MacOS)
• Kuvars (MacOS X, iPhone, iPad)
• Kahire (Windows, Linux, BSD, MacOS, iPhone, iPad, MacOS, PS3, Wii)

Mono Kütüphaneleri - Çapraz Platform, .NET'te kullanılabilir ancak manuel olarak oluşturulmasını gerektirir

• C # 4 Hizmet Olarak Derleyici
• Cecil - CIL Manipülasyonu, iş akışı, CIL enstrümantasyonu, Bağlayıcılar
• RelaxNG kütüphaneleri
• Mono.Data. * Veritabanı sağlayıcıları
• Tam System.Xaml (.NET'in yığın sağlamadığı kurulumlarda kullanım için)

MonoTouch iPhone'da çalışan Mono anlamına gelir; MonoDroid Android'de çalışan Mono anlamına gelir; PS3 ve Wii portları yalnızca Sony ve Nintendo yetkili geliştiricileri tarafından kullanılabilir.

Formalitenin olmayışı için özür dilerim.

Öncelikle, Ortak Dil Altyapısı (Açık standart) ve .NET (Microsoft'un bu standardın uygulanması) arasında bir ayrım yapmanız gerekir. Mono, CLI'nin bir uygulamasıdır ve asla "taşınabilir bir .NET" olduğu iddiasında değildir. Ayrıca, C # dili açık bir standarttır ve kesinlikle .NET'e bağlı değildir.

Microsoft'un bir uygulamanın uyumlu olduğunu doğrulamak için herhangi bir aracı olup olmadığının farkında değilim, ancak yaparlarsa, mono adamların kullandığından ve kullandığından eminim.

Mono .Net'in arkasından takip ediyor, ancak zorlukla. Mono C # 4.0 kodunu çalıştırabilir (geçerli .NET sürümü). Ayrıca Microsoft yakın zamanda tüm DLR kodlarını ve kitaplıklarını açık kaynaklı (Apache 2.0 lisansı altında) yapmış, bu da mono'nun IronPython, IronRuby ve F # gibi dilleri kullanabilmesini sağladı. Buna ek olarak, Microsoft, mono geliştiricilerin mevcut sürüm sürümleriyle güncel kalmasını sağlayan .NET'te düzenli olarak yaklaşmakta olan özelliklerin CTP'lerini düzenli olarak yayınlamaktadır.

.NET'te bir dizi araç ve uzantı var, örneğin Kod Sözleşmeleri. Bunlar her zaman tamamen mono olarak uygulanmamıştır. (Şu anda, Sanırım sözleşmeler için kısmi bir sözleşme doğrulayıcısı olduğunu düşünüyorum). Bunlar zaten .NET uygulamalarında yaygın olarak kullanılmaz, ancak popülariteleri artarsa, mono olarak uygulanma oranları da artar.

WinForms (tamamen) taşınabilir değildir. NET'e özgüdür ve CLI'nin bir parçası değildir. CLI, belirli bir pencere öğesi kümesi belirtmiyor. Platformlar arası çapraz kümeler var olsa da (GTK # ve Silverlight). Taşınabilirliği düşünerek sıfırdan bir uygulama yazıyorsanız, Winforms / WPF yerine bunlardan birini kullanırsınız. Ek olarak, mono Winforms API için mevcut bir sarma formatı uygulamalarının GTK # 'ya daha kolay bir şekilde taşınmasını sağlayan (tamamen yeniden yazma olmadan) ince bir sarmalayıcı sağlar.

Mono, mevcut bir Net uygulamasını alabilen ve taşınabilirliği hakkında size bilgi verebilecek bir araç olan Mono Migration Analyzer (MoMA) sağlar. (örneğin, kullanılan taşınabilir kütüphaneleri, P / Invokes vb. tanımlayın).

Açık Kaynağa bağımlı olmak istemeyen işletmeler için - mono yeniden lisanslanabilir. Monoya eklenen kodun mülkiyeti, normal LGPL lisansı dışındaki alternatif yöntemlerle lisanslayabilen (zaten çok az kısıtlaması olan) novell'e verilir.

".NET taşınabilir" iddiasına gelince, kodun temelden kod yazıp çerçeveyle taşınabilirlik sorunlarının farkındaysanız bunun geçerli bir iddia olabileceğini düşünüyorum. Eğer iddia ".NET'te yazılmış bir Windows uygulamasına sahibim, mono üzerinde çalışmalı" ise, o zaman geçerli değil - ama Mono bu tür uygulamaları taşımayı kolaylaştırmak için çaba gösterdi.

Noktadan noktaya:

• OpenJDK ve JVM'lerin tedarik ettiği tüm satıcı, işlerin doğru bir şekilde çalışmasını sağlamak için resmi Sun TCK'yı geçti. Mono’nun bir Microsoft TCK’yı geçtiğini bilmiyorum.
  Microsoft CLR'nin uygun olduğu bir belirtim var. Mono, Microsoft'un CLR'sinin bir klonu değil, aynı şartnamenin bir uygulamasıdır. Bir yandan, bunun daha da fazla uyumsuzluğa yol açma ihtimali var. Uygulamada, bu mono için çok iyi çalıştı.
• Mono .NET sürümlerini takip eder. Hangi .NET düzeyi şu anda tam olarak desteklenmektedir?
  .Net'in belgeleri gerçek sürümden önce olduğundan, mono , resmi Microsoft sürümünden önce .Net 4'ü destekledi (beta sürümü değil) . Ek olarak, mono, nelerin desteklenmediğini belgelemek için çok iyi bir iş çıkarır ve uyumsuzluk potansiyeli olan yerleri tespit etmenize yardımcı olmak için mevcut projeye karşı koyabileceğiniz birkaç araca sahiptir.
• Tüm GUI öğeleri (WinForms?) Mono'da düzgün çalışıyor mu?
  Winformların büyük çoğunluğu gayet iyi çalışıyor. WPF, çok değil. Aynı şeyin Java için de geçerli olduğunu duydum - gelişmiş widget / gui araç setlerinin çoğu tüm platformlarda iyi bir şekilde desteklenmiyor.
• İşletmeler resmi plan B olarak Açık Kaynaklı çerçevelere bağımlı olmak istemeyebilir.
  Bu durumda, kesinlikle Java ile çalışmayacaklar, o zaman bu açık planlı bir çerçeveyi A planında daha da yükseltir.

Özetle, şu anda bir platformlar arası uygulama oluşturmak istiyorsanız , başlangıçtan itibaren mono ile başlayıp bunu çerçeveniz olarak kullanmakta yanlış bir şey yoktur. İsterseniz Windows'ta mono dağıtabilirsiniz.

Öte yandan, gelecekte gelecekte bilinmeyen bir noktada çapraz platform olması gerekebileceğini düşündüğünüz bir Windows uygulaması oluşturmaya çalışıyorsanız , muhtemelen yerel Windows widget'ları ve araçlarıyla gitmek istersiniz. .Net burada Java'dan çok daha iyi bir iş çıkarır ve mono bu senaryoda geri dönüşü tamamen kabul edilebilir.

Başka bir deyişle: Evet. Net, her yönden çapraz platform ise sorunuzla ilgili. Hayır, mono sadece. Net programını kutudan çıkarmaz, ancak sorunuz yeni bir proje bağlamındadır. Yeni projeleri sıkıntıdan uzak tutmak ve uyumluluk sorunlarından kaçınmak için çok fazla iş gerektirmez, özellikle .Net için geliştirmek yerine mono için geliştirme açısından düşünüyorsanız.

Hepsinden önemlisi, bunun en başta yanlış bir soru olduğunu düşünüyorum. Sıfırdan yeni bir geliştirme ekibi oluşturmazsanız, bir alanda veya başka alanda uzmanlığı olan programcılarla başlıyorsunuz. Programcılarınızın zaten bildiği şeylere giderek en iyi sonuçlara ulaşılacaksınız. Bir platformlar arası uygulama oluşturmak kadar önemli görünebilir, eğer Java'lı deneyimi olmayan .Net programcıları ile dolu bir ekibiniz varsa, onları kovmanız ya da bir sonraki projeniz için hepsinin java öğrenmesini sağlamalısınız. Java programcılarıyla dolu bir ekibiniz varsa, onlardan öğrenmelerini istemeyeceksiniz. Yalnızca Windows projesi için net. Bunlardan biri fındık olurdu.

Mono ile çalıştım ve açık kaynaklı olan ve doğrudan Microsoft tarafından desteklenmeyen alternatif bir platformla elde edebileceğiniz kadar iyi olduğunu söyleyebilirim. Bir kullanarak rahat olabiliyorsa alternatif açık kaynak Clojure veya Scala gibi platformu, muhtemelen mono kullanarak rahat olabilir.

Mono tarafından desteklenen .NET seviyesi her zaman Mono Yol Haritası sayfasında bulunabilir.

Tüm GUI öğeleri çalışıyor mu? Bildiğim kadarıyla her şeyi ayrıntılı olarak denememiş olmama rağmen, yapıyorlar.

Mono .NET ile aynı mıdır? Hayır. Burada ve orada gerekli küçük (ve belki de büyük) tweaks olacağından şüpheleniyorum. Örneğin, şu anda Entity Framework’ü onunla birlikte çalıştıramazsınız.

Hedef olarak, .NET / mono evreni çok hızlı hareket eder .

Her birkaç yılda bir Microsoft, dili, çalışma zamanını ve .NET'i çevreleyen altyapı ile ilgili bazı zorlayıcı değişiklik ve yeniliklerle ortaya çıkıyor. Örneğin: Generics, LINQ, DLR, Entity Framework - Visual Studio'nun her yeni revizyonunda, özellik setinde ve hedeflediği çerçevenin kullanışlılığında genellikle oldukça önemli bir artış var.

Çerçevedeki sürekli gelişme memnuniyetle karşılanırken, birden fazla platformda uyumluluk istiyorsanız da sorunludur. Red Hat Enterprise Linux gibi uzun vadeli destek platformları, yeni teknolojiyi benimseme konusunda buzlu olarak yavaş ilerliyor ve herhangi bir noktada, Mono platformunda son birkaç ay içinde gerçekleşen önemli gelişmeler olacak. Bu yüzden, harika çocukların inşa ettiği şeyleri çalıştırmak istiyorsanız, Mono'yu sıfırdan derlemeniz ve kendi yamalarınızı ve güncellemelerinizi yönetmeniz gerekecek. Bu hiç hoş değil.

Diğer yandan, Java, bir çocuk havuzu kadar durgun. Özellikle şimdi, patent davaları için sadece Java'yı isteyen bir şirket tarafından kendisine ait olduğu için, öngörülebilir gelecekte dilde veya çalışma zamanında tespit edilebilir bir değişiklik olmayacağından oldukça emin olabilirsiniz. Java, FORTRAN kadar sağlam bir platformdur. Herhangi bir iyileştirme umut ediyorsanız, bu o kadar iyi değil, ancak bir kurumsal uygulamayı uygulamaya çalışıyorsanız çok da kötü değil.

Kullanıcı bakış açısından, Mono, Windows .NET uygulamalarını Linux ile uyumlu hale getirme konusunda berbat. Mono'da terbiyeli yazılmış bir Windows uygulamasını çalıştırmayı denerseniz, işe yaramaz.

Paketleyicinin bakış açısına göre (PortableApps'de biraz çalışma yaptım), .NET hem bir lütuf hem de bir lanet olabilir. Yalnızca Windows kullanıyorsanız, .NET dağıtımı çok daha kolay hale getirir, çünkü daha fazla kitaplık daha az sisteme bağımlı şeyler anlamına gelir (en önemlisi, Windows sürümleri arasında, inanıyorum), ancak Windows sürümlerinde bile kafa karıştırıcıdır çünkü .NET sürümleri de geriye doğru değildir. -uyumlu veya ileriye uyumlu. Farklı programlar için .NET'in farklı sürümlerini indirmelisiniz.

Bununla birlikte, Mono, C # programlarını platformlar arası yapmak için iyi bir başlangıç ​​noktasıdır. Sadece programı en son WINE ile paketlemeyin ve yine de bitirin. Picasa'yı nereye götürdüğüne bakın.

İki dilde / platformda siyasi istikrara gelince, RMS muhtemelen Mono’nun Microsoft’la balayının oldukça meşhur olduğu Novell’in başını çektiğini anlatmaya başladı. Her iki platform da şu anda siyasi açıdan dengesiz olarak kabul edilebilir.

Eğer gerçekten kolay platformlar istiyorsanız, denenmiş ve gerçek yol QT'dir ve şu anda olduğu gibi politik olarak oldukça istikrarlı olan QT'dir. hangi gerçekten popüler telefonlar satıyor.

Mono, Microsoft’un .net’in 1: 1 bağlantı noktası değildir. Mono'nun basitçe uygulayamayacağı veya yapamayacağı teknolojiler var (örneğin, Workflow Foundation veya WPF ), diğer yandan Microsoft .NET'in yapmadığı bazı teknolojiler var, örneğin, SIMD Extensions .

Kısa Cevap: Mono ve Microsoft .NET, aynı temele dayanan - CIL ve BCL - fakat ayrı projelerdir.

Orijinal gönderideki ifadelere küçük yorum. TCK’nın Oracle’ın Java’nın açık bir standart olduğunu iddia etmesine izin veren teorik bir araç olduğunu savunuyorum. Çünkü fark ederseniz, Apache Harmony birkaç yıldır "Java" olarak onaylanmaya çalışıyor, başarısız oldu. Oracle'ın, bağlı oldukları uygulama dışında açık kaynak kodlu bir uygulama ile gerçekten ilgilenmediği açıktır. Mono gibi, tam değil (yani, Java Web Start desteği yok) ve kapalı kaynaklı HotSpot uygulamasında mevcut bazı optimizasyonlar eksik.

Yani tartışmalı, 2010 itibariyle; (çoğu) Java açık kaynak kodlu ancak açık bir standart değil. (Çoğu) .NET açık kaynak kodlu değil, açık bir standart. Elbette istisnalar var, DLR, IronPython, IronRuby ve F # aslında açık kaynak. Mono ilginç çünkü her iki dünyanın da en iyisini, açık standartların açık kaynak kodlu uygulamalarını sağlıyor.

Tüm teknikleri bir kenara koymak, kodu yazarken çok önemli bir kısımdır.

Tüm platformlar arası teknolojilerde olduğu gibi (Java, Python, Ruby ...), kod taşınabilirlik göz önünde bulundurulmadığında, kodun doğru şekilde çalışması için temelde sıfır şansın olduğunu varsaymalısınız (böyle bir şans olsa bile) gerçekte çok, çok daha yüksek), garip yanlış davranışlar oldukça kritik olabilir. Oku: rastgele montajı yapma ve Mono altında çalıştırma.

Yine de yeni bir proje için (veya kolayca refaktör olabilirsiniz), potansiyel olarak taşınabilir bir çalışma zamanı olarak .Net / Mono'yu seçmek mantıklıdır, ancak proje üzerinde çok erken olsa bile Mono'da kodunuzu test ederek kendinizi çok fazla güçlükten kurtarırsınız. çok platformlu çok küçük bir değişiklik. Sürekli bir entegrasyon sunucusu kullanıyorsanız, bu bir Mono derleme düğümü ayarlamak kadar basit olabilir. Geliştirme sırasında pek çok sorun çözülebilir, sadece bir alışkanlık haline getirerek (inşaat yolu dizeleri gibi) ve kodunuzun çok büyük bir kısmı taşınabilir görünebilir ve Mono'da sadece akıllıca uygulamalar ve biraz ön görülerle test edilebilir. Kalan kısım (yani başarısız ünite testleri) daha sonra platforma özgüdür (PInvoke kullanan kod gibi) ancak hedeflenen platform başına alternatif bir uygulama sağlayabilmek için yeterince kapsüllenmelidir.

Tabii ki, Mono'da mevcut olmayan (.Net) veya uyumlu (üçüncü taraf) bir kütüphane kullanmak bunların hiçbirini engellemektedir, ancak benim alanımda bu henüz görülmemiştir. Aslında işte kullandığımız strateji budur ve uygularken .Net + Mono'nun çapraz platform olduğunu iddia etmekten korkmuyorum.

Değişiyor dürüst cevaptır. IIS'den Apache'ye taşınan küçük web sunucusu öğelerinin, mono altında neredeyse hiç zorluk çekmeden çalıştığını gördüm. Başarılı bir şekilde Linux üzerinde Win Forms kullanarak değiştirilmemiş Windows. Net uygulamaları çalıştırın.

Bununla birlikte, çalışabilse de, mono üzerinde gerçekleştirilmemiş bir API çağrısı kullanıyorsanız, o zaman işe yaramaz ve tek çözüm ya uygulamanızı yeniden yazmak, pencerelerle yapıştırmak veya fazladan şeyleri mono olarak yazmaktır.