it-swarm.dev

Mono genellikle "Evet, .NET çapraz platformdur" demek için kullanılır. Bu iddia ne kadar geçerli?

Projeniz için .NET ve Java şu anda?) Arasında neyi seçerdiniz? “Her zaman Windows'a dağıtacak mısınız? "yeni bir web projesinde ön plana çıkmak için en önemli teknik karar ve cevap" hayır "ise, Java) öneriyoruz.

Çok yaygın bir karşı argüman şudur: "Eğer Linux/OS X/Ne olursa olsun koşmak istiyorsak, sadece Mono'yu çalıştırırız"1, bu yüzeyde çok zorlayıcı bir argüman, ama birkaç nedenden dolayı katılmıyorum.

  • OpenJDK ve JVM tarafından tedarik edilen tüm satıcılar, işlerin düzgün çalışmasını sağlamak için resmi Sun TCK'yı geçti. Mono'nun bir Microsoft TCK'yı geçtiğinin farkında değilim.
  • Mono, .NET sürümlerini izler. Şu anda tam olarak hangi .NET düzeyi destekleniyor?
  • Mono'da tüm GUI öğeleri (WinForms?) Düzgün çalışıyor mu?
  • İşletmeler resmi plan B olarak Açık Kaynak çerçevelerine güvenmek istemeyebilirler.

Java yeni yönetişim ile geleceğin güvensiz olduğunu biliyorum, ancak örneğin IBM, Linux dahil birçok platform için JDK sağlar . açık kaynaklı.

Peki, Mono hangi koşullar altında .NET uygulamaları için geçerli bir iş stratejisidir?


1Mark H bunu şöyle özetledi : "İddia şu ise " .NET ile yazılmış bir windows uygulamam var, mono üzerinde çalışmalıdır " değil, geçerli bir iddia değil - ancak Mono bu tür uygulamaları taşımayı kolaylaştırmak için çaba sarf etti. "

171
user1249

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

".NET çapraz platformdur" hem çerçeve hem de başlangıçta yaratıldığı dünya değiştiği ve geliştiği için belirsiz bir ifadedir.

Kısa cevap:

.NET ve türevlerine güç veren temel motor, Ortak Dil Altyapı Standardı çapraz platformdur ve kodunuzu birden çok platforma taşımak istiyorsanız, kullanmayı planlamanız gerekir her platformda en iyi deneyimi sunmak için doğru platformdaki doğru API'leri .

CLI ailesi "Bir Kez Yaz, Her Yerde Çalıştır" yaklaşımını denemedi, çünkü bir telefondan bir ana kareye olan farklar çok büyük. Bunun yerine, geliştiricilere her platformda harika deneyimler oluşturmak için doğru araçları vermek üzere 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ı hedeflemiyor. Artık dünya, PC'lerden, oyun konsollarına, güçlü telefonlara, set üstü kutulara, büyük sunuculara ve dağıtılmış makine kümelerine uzanan büyüleyici platformlarla çevrilidir. Tüm platforma tek beden sığması sadece küçük cihazlarda şişkin hissediyor ve büyük sistemlerde yetersiz kalıyor .

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

Bugün .NET tabanlı teknolojilerle tüm ana işletim sistemlerini, telefonu, mobil cihazı, gömülü sistemi ve sunucuyu 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 -> Genellikle .NET veya Silverlight çalıştırırsınız, ancak burada tam Mono da kullanabilirsiniz.
    • linux, BSD veya Solaris çalıştıran -> Tam Mono veya Silverlight çalıştırıyorsunuz
    • macOS X çalıştıran -> Tam Mono veya Silverlight çalıştırıyorsunuz
    • running Android -> Mono/Android alt kümesini çalıştırıyorsunuz
  • ARM bilgisayarlar:
    • Windows Phone 7'yi çalıştırma: Compact Framework 2010'u çalıştırıyorsunuz
    • Windows 6.5 ve daha eski sürümleri çalıştırma: Eski Compact Framework'ü çalıştırıyorsunuz
    • Android cihazlar: Mono/Android'i çalıştırıyorsunuz
  • PowerPC bilgisayarlar:
    • Tam Linux, BSD veya Unix işletim sistemleri için tam Mono çalıştırı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ırsınız
  • S390, S390x, Itanium, SPARC bilgisayarlar:
    • Mono'yu tam olarak çalıştırıyorsun
  • Diğer tümleşik işletim sistemleri:
    • Mobil profil ile .NET MicroFramework veya Mono çalıştırıyorsunuz.

İhtiyaçlarınıza bağlı olarak yukarıdakiler yeterli olabilir veya olmayabilir. Her yerde çalıştırmak için aynı kaynak kodunu almayacaksınız. Örneğin, XNA kodu her masaüstünde çalışmazken, .NET Masaüstü yazılımı XNA veya telefonda çalışmaz. .NET Framework'ün diğer profillerinde çalıştırmak için genellikle kodunuzda değişiklik yapmanız gerekir. İşte farkında olduğum profillerden bazıları:

  • .NET 4.0 Profili
  • Silverlight Profili
  • Windows Phone 7 Profili
  • XBox360 Profili
  • Mono çekirdek Profili - .NET profilini izler ve Linux, MacOS X, Solaris, Windows ve BSD'de kullanılabilir.
  • .NET Micro Framework
  • İPhone profilinde mono
  • Mono on Android Profil
  • Mono sisteminde PS3 Profili
  • Mono on Wii Profili
  • Ay ışığı profili (Silverlight ile uyumlu)
  • Moonlight genişletilmiş profili (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, Host platformuna sığacak ve anlamlı olan API'ları ortaya çıkaracak ve anlamlı olmayanları kaldıracak şekilde tasarlanmıştır.

Örneğin, Silverlight'ın Host tarayıcısını kontrol eden API'leri telefonda bir anlam ifade etmiyor. Ve XNA'daki gölgelendiriciler, eşdeğer desteğe sahip olmayan PC donanımında bir anlam ifade etmiyor.

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

Bununla birlikte, bazı API'lar ve yığınlar birden fazla platformda kullanılabilir, örneğin ASP.NET Windows, Linux, Solaris, MacOS X üzerinde kullanılabilir, çünkü bu API'lar hem .NET hem de Mono'da bulunur. ASP.NET, Microsoft'un XBox veya Windows Phone 7 gibi desteklenen bazı platformlarında mevcut değildir ve Mono'nun Wii veya iPhone gibi desteklediği diğer platformlarda da desteklenmez.

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

Aynı ilkeler diğer yığınlara uygulanabilir, tam bir liste burada nasıl sunulacağına dair hiçbir fikrim olmayan uygun bir tablo gerektirir, ancak burada belirli bir platformda bulunmayan teknolojilerin bir listesi. Burada listelenmeyen herhangi bir şeyin mevcut olduğunu varsayabilirsiniz (kaçırdığım şeyler için düzenlemeler göndermekten çekinmeyin):

Çekirdek Çalışma Zamanı Motoru [her yerde]

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

Diller

  • C # 4 [her yerde]
  • Hizmet Olarak C # Derleyici (Linux, MacOS, Solaris, BSD, Android)
  • IronRuby [her yerde WP7, CF, Xbox, MonoTouch, PS3'ü yürütün]
  • IronPython [her yerde, WP7, CF, Xbox, MonoTouch, PS3'ü yürütün]
  • F # [her yerde, WP7, CF, Xbox, MonoTouch, PS3'ü yürütü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 yerde)
  • LINQ to XML (her yerde)
  • System.Json [Silverlight, Linux, MacOS, MonoTouch, MonoDroid]
  • System.Messaging [Windows; Linux, MacOS ve Solaris için RabbitMQ gerekir]
  • .NET 1 Enterprise Hizmetleri [yalnızca Windows]
  • WCF [Windows üzerinde tamamlandı; Silverlight, Solaris, MacOS, Linux, MonoTouch, MonoDroid üzerinde küçük bir alt küme]
  • Windows İş Akışı [yalnızca Windows]
  • Cardspace kimliği [yalnızca Windows]

GUI yığınları

  • Silverlight (Windows, Mac, Linux - Moonlight 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 Entegrasyon (yalnızca Android)
  • Media Center API'ları - yalnızca Windows
  • Dağınıklık (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 X, PS3, Wii)

Mono Kitaplıklar - Çapraz Platform, .NET'te kullanılabilir, ancak manuel olarak oluşturulmasını gerektirir

  • C # 4 Hizmet Olarak Derleyici
  • Cecil - CIL Manipülasyon, iş akışı, CIL enstrümantasyonu, Bağlayıcılar
  • RelaxNG kütüphaneleri
  • Mono.Data. * Veritabanı sağlayıcıları
  • Full System.Xaml (.NET'in yığını sunmadığı 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 bağlantı noktaları yalnızca Sony ve Nintendo yetkili geliştiricileri tarafından kullanılabilir.

Formalite eksikliğinden dolayı özür dilerim.

195
miguel.de.icaza

İlk olarak, Ortak Dil Altyapısı (Açık standart) ve .NET (Microsoft'un bu standardı uygulaması) arasında bir ayrım yapmanız gerekir. Mono CLI'nin bir uygulamasıdır ve hiçbir zaman "taşınabilir bir .NET" olduğunu iddia etmemiştir. 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ı bilmiyorum, ancak eğer yaparlarsa, mono adamların buna sahip olduğundan ve kullandığından eminim.

Mono .Net'in arkasından geliyor, ancak zar zor. Mono, C # 4.0 kodunu çalıştırabilir (geçerli .NET sürümü). Ayrıca, Microsoft son zamanlarda mono'nun IronPython, IronRuby ve F # gibi dilleri kullanmasına izin veren tüm DLR kod ve kütüphanelerini açık kaynak (Apache 2.0 lisansı altında) yaptı. Buna ek olarak, Microsoft, mono geliştiricilerin güncel sürümlerle güncel kalmasını sağlayan .NET'te gelecek özelliklerin CTP'lerini düzenli olarak yayınlamaktadır.

.NET'te, örneğin Kod Sözleşmeleri gibi bir dizi araç ve uzantı vardır. Bunlar her zaman mono olarak tam olarak uygulanmaz. (Şu anda, Sözleşmeler gerektirir için kısmi bir sözleşme doğrulayıcı 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. Bunlar .NET'e özeldir ve CLI'nin bir parçası değildir. CLI herhangi bir widget seti belirtmez. Ancak çapraz platform widget setleri vardır (GTK # ve Silverlight). Sıfırdan taşınabilirliği göz önünde bulundurarak bir uygulama yazıyorsanız, Winforms/WPF yerine bunlardan birini kullanırsınız. Ayrıca mono, Winforms API'sı için ince bir sarmalayıcı sağlar - bu, mevcut winforms uygulamalarının GTK # içine daha kolay taşınmasını sağlar (tüm yeniden yazma olmadan).

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

Açık Kaynak'a bağımlı olmak istemeyen işletmeler için mono yeniden lisanslanabilir. Monoya eklenen kodun sahipliği, normal LGPL lisansı dışında alternatif yollarla lisanslayabilen (zaten çok az kısıtlama olan) novell'e teslim edilir.

".NET taşınabilir" iddiasına gelince, kodu sıfırdan yazıyorsanız ve çerçeve ile ilgili taşınabilirlik sorunlarının farkındaysanız, bu geçerli bir iddia olabileceğini düşünüyorum. İddia ".NET ile yazılmış bir windows uygulamam var, mono üzerinde çalışmalıdır" ise, geçerli bir iddia değildir - ancak Mono bu tür uygulamaları taşımayı kolaylaştırmak için çaba sarf etmiştir.

115
Mark H

Noktadan noktaya:

  • OpenJDK ve JVM tarafından sağlanan tüm satıcılar, şeylerin doğru çalışmasını sağlamak için resmi Sun TCK'yı geçti. Mono'nun bir Microsoft TCK'yı geçtiğinin farkında değilim.
    Microsoft CLR'nin uyumlu olduğu bir şartname var. Mono, Microsoft'un CLR'sinin bir kopyası değil, aynı spesifikasyonun bir uygulamasıdır. Bir yandan, bunun daha da fazla uyumsuzluğa neden olma ihtimali vardır. Uygulamada, bu mono için çok iyi çalıştı.
  • Mono, .NET sürümlerini izler. Şu anda tam olarak hangi .NET düzeyi desteklenmektedir?
    .Net belgelerinin asıl sürümden önce gelmesi nedeniyle, mono aslında .Net 4 çıkışı için daha önce (beta = değil) desteğini tamamlamıştı resmi Microsoft sürümü. Ayrıca, mono, hangi şeylerin 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şı çalıştırabileceğiniz birkaç araca sahiptir.
  • Mono'da tüm GUI öğeleri (WinForms?) Doğru ç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 desteklenmiyor.
  • İşletmeler resmi plan B olarak Açık Kaynak çerçevelerine güvenmek istemeyebilirler.
    Eğer durum buysa, kesinlikle Java ile gitmeyecekler, o zaman, bu açık kaynak çerçevesini A planında daha da yükseltir.

Özetle, şu anda bir çapraz platform uygulaması oluşturmak istiyorsanız , get-go'dan mono ile başlayıp bunu şu şekilde kullanmakla ilgili bir sorun yoktur. çerçeve. İsterseniz Windows'ta mono bile dağıtabilirsiniz.

Öte yandan, bugün , bilinmeyen bir noktada çapraz platform olabileceğini düşündüğünüz bir Windows uygulaması oluşturmaya çalışıyorsanız Gelecekte, muhtemelen yerel Windows widget'ları ve araçları ile gitmek istersiniz. .Net, Java'dan çok daha iyi bir iş çıkarıyor ve mono, bu senaryoda mükemmel bir şekilde kabul edilebilir bir düşüş.

Diğer bir deyişle: Evet. Hayır, mono sadece tüm .Net programlarını kutudan çıkarmaz, aynı zamanda sorunuz yeni bir proje bağlamındadır. Özellikle .Net için geliştirmektense mono için geliştirme açısından düşünüyorsanız, yeni projeleri beladan uzak tutmak ve uyumluluk sorunlarından kaçınmak için çok fazla iş gerektirmez.

En önemlisi, bence bu en başta yanlış olan soru. Sıfırdan yeni bir geliştirme ekibi kurmadıkça, bir alanda veya başka bir alanda uzmanlığa sahip programcılarla başlıyorsunuz. En iyi sonuçlarınız, programcılarınızın zaten bildiklerine ulaşarak elde edilecektir. Bir platformlar arası uygulama oluşturmak kadar önemli görünebilir, eğer Java deneyimi olan .Net programcılarıyla dolu bir ekibiniz varsa, onları ateşlemeniz veya hepsinin öğrenmesini istemeniz mümkün değildir [Java sonraki projeniz için. Java programcıyla dolu bir ekibiniz varsa, onlardan yalnızca Windows projesi için .Net öğrenmelerini istemeyeceksiniz. Bunların her ikisi de fındık olur.

14
Joel Coehoorn

Mono ile çalıştım ve açık kaynaklı ve Microsoft tarafından doğrudan desteklenmeyen alternatif bir platformla elde edebileceğiniz kadar iyi olduğunu söyleyebilirim. Clojure veya Scala gibi bir alternatif açık kaynaklı platform kullanarak rahat edebiliyorsanız, muhtemelen Mono kullanmakta rahat olabilirsiniz.

Mono tarafından desteklenen .NET düzeyi her zaman Mono Yol Haritası sayfasında bulunabilir.

Tüm GUI öğeleri çalışıyor mu? Bildiğim kadarıyla, her öğeyi kapsamlı bir şekilde denememiş olmama rağmen, biliyorlar.

Mono .NET ile aynı mıdır? Hayır. Burada ve orada gerekli küçük (ve belki de büyük) ince ayarlar olacağından şüpheleniyorum. Şu anda, Varlık Çerçevesini bununla çalıştıramazsınız.

11
Robert Harvey

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

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

Çerçevedeki sürekli iyileştirme hoş karşılanırken, birden fazla platformda uyumluluk istiyorsanız da sorunludur. Red Hat Enterprise Linux gibi uzun vadeli destek platformları, yeni teknolojiyi benimseme konusunda buzulca yavaş ilerliyor ve herhangi bir noktada Mono platformunda son birkaç ay içinde meydana gelen önemli gelişmeler olacak. Bu yüzden havalı ç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. Güzel değil.

Öte yandan Java, çocuk havuzu kadar durgundur. Özellikle şu anda sadece Java) isteyen bir şirkete ait olduğu için, öngörülebilir gelecekte dilde veya çalışma zamanında herhangi bir algılanabilir değişiklik olmayacağından emin olun. Java FORTRAN kadar istikrarlı bir platformdur. ancak kurumsal bir uygulamayı dağıtmaya çalışıyorsanız o kadar da kötü değil.

9
tylerl

Kullanıcı açısından bakıldığında Mono, Windows .NET uygulamalarını Linux ile uyumlu hale getirmekte berbat. Eğer Mono'da iyi yazılmış bir Windows uygulaması çalıştırmayı denerseniz, işe yaramaz.

Bir paketleyicinin bakış açısından (PortableApps'de biraz iş yapardım), .NET hem bir nimet 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ğlı şeyler anlamına gelir (en önemlisi Windows sürümleri arasında, sanırım), ancak Windows'ta bile son derece kafa karıştırıcıdır. uyumlu veya ileri uyumlu. Farklı programlar için farklı .NET sürümleri indirmeniz gerekir.

Bununla birlikte, Mono, C # programlarını çapraz platform haline getirmek için iyi bir başlangıç ​​noktasıdır. Sadece programı en son WINE ile paketlemeyin ve olsa da deyin. Bakın Picasa'yı nereye götürdü.

İki dilde/platformda politik istikrarda olduğu gibi, RMS muhtemelen Mono'nun Microsoft ile balayı oldukça kötü olan Novell tarafından nasıl yönetildiğine dair sıralamaya başlayacaktı. .

Gerçekten kolay çapraz platform istiyorsanız, denenmiş ve gerçek yol şu anda olduğu gibi siyasi olarak oldukça istikrarlı olan QT'dir: a) LGPL'd, b) yıllar önce ana lisanslama sorunları ile yapıldı ve c) Nokia tarafından desteklendi, gerçekten çok popüler telefonlar satıyor.

7
digitxp

Mono, Microsoft'un .net'in 1: 1 bağlantı noktası değildir. Mono'nun uygulayamayacağı veya herhangi bir planının bulunmadığı teknolojiler vardır (örn., Workflow Foundation veya WPF ). Microsoft .NET'in yapmadığı teknolojiler, örneğin SIMD Uzantıları.

Kısa Yanıt: Mono ve Microsoft .NET, aynı temel olan CIL ve BCL'yi temel alır, ancak ayrı projelerdir.

4
Michael Stum

Orijinal yayındaki ifadelere küçük bir yorum. TCK'nın Oracle'ın Java iddiasının açık bir standart olduğunu iddia etmesine izin veren teorik bir araç olarak kaldığını iddia edeceğim. Çünkü fark ederseniz, Apache Harmony birkaç yıldır başarısız bir şekilde "Java" sertifikası almaya çalışıyor. Oracle'ın bağlı oldukları uygulama ve az ya da çok kontrol (OpenJDK) dışında açık kaynaklı bir uygulama ile gerçekten ilgilenmediği açıktır. Mono gibi, tam değildir (yani Java Web Start desteği yok) ve kapalı kaynak HotSpot uygulamasında bazı optimizasyonlar eksik.

Tartışmalı bir şekilde, 2010 itibariyle; (çoğu) Java açık kaynak, ancak açık bir standart değil, (çoğu) .NET açık kaynak değil, açık bir standarttır. Tabii istisnalar var, DLR, IronPython, IronRuby ve F # aslında açık kaynak. Mono ilginçtir, çünkü açık standartların her iki dünyanın en iyi açık kaynak uygulamalarını sağlar.

2
Casper Bang

Tüm teknik özellikleri bir kenara koyarsak, kodu gerçekten yazarken çok önemli bir yer tutar.

Herhangi bir çapraz platform teknolojisinde olduğu gibi (Java, Python, Ruby ... olsun), kod taşınabilirlik göz önünde bulundurularak yazılmadıysa, kodun düzgün çalışması için temelde sıfır şans olduğunu varsaymalısınız (böyle bir şans olsa bile) gerçekte çok, çok daha yüksek), çünkü garip yanlış davranış oldukça kritik olabilir. Okuyun: Rastgele Meclisi almayın ve Mono altında çalıştırın.

Yine de yeni bir proje için (veya kolayca yeniden düzenleme yapabilirsiniz), .Net/Mono'yu potansiyel olarak taşınabilir bir çalışma zamanı olarak seçmek mantıklıdır, ancak proje, çok platforma geçişte sadece küçük bir değişiklik. Sürekli bir tümleştirme sunucusu kullanıyorsanız, bu bir Mono derleme düğümü kurmak kadar basit olabilir. Geliştirme sırasında birçok sorun çözülebilir, sadece bir alışkanlık yaparak (yol dizeleri oluşturmak gibi) ve kodunuzun büyük bir kısmı sadece aklı başında uygulamalar ve biraz da öngörü kullanarak Mono'da taşınabilir ve birim test edilebilir. Kalan kısım (yani başarısız birim testleri) platforma özgüdür (PInvoke kullanan kod gibi), ancak hedeflenen platform başına alternatif bir uygulama sağlayabilecek kadar kapsüllenmelidir. Bu şekilde proje sonunda taşınmaya geldiğinde, işin büyük bir kısmı neredeyse hiçbir ücret ödemeden yapılmıştır ve geri kalanı Tam Zamanında geliştirilecektir.

Tabii ki, Mono'da mevcut olmayan (.Net) veya uyumlu (üçüncü taraf) bir kitaplık kullanmak bunlardan herhangi birini engeller, ancak alanımda bu henüz görülmedi. Aslında işte kullandığımız strateji budur ve uygularken .Net + Mono'nun çapraz platform olduğunu iddia etmekten korkmuyorum.

1
Lloeki

Bu dürüst cevap değişir. Küçük web sunucusu şeyler IIS Apache, neredeyse hiç zorluk ile mono altında çalışan taşındık gördüm. Linux üzerinde Win Forms kullanarak değişmeyen Windows .Net uygulamaları çalıştırdım.

Ancak, çalışabilirken, mono üzerine uygulanmayan bir API çağrısı kullanıyorsanız, o zaman işe yaramaz ve tek çözüm ya uygulamanızı yeniden yazmak, pencerelere sadık kalmak veya ekstraları mono olarak yazmaktır.

0
Michael Shaw