Kurumsal Windows tabanlı çözümler için, .NET bazen en iyi seçimdir. Mono Linux kullanmak zorunda olan (ya da Linux kullanmayı tercih eden) işletmelere nasıl bakıyor? Geliştiricilerin bir sorun olmadığını ve .NET / Mono ile Java gibi diğer olası rakipleri tanıdıklarını varsayarsak.
Bir orta / büyük şirket Mono'yu sunucularında Java gibi teknolojilerin tersine çalıştırabilir mi? Böyle bir firma biliyor musunuz?
Yanıtlar:
Çalıştığım büyük şirkette kullandık. Projenin başlangıcından itibaren planlamadık ama bu şekilde başladı.
.NET'te geliştirdiğimiz bir iç projemiz vardı, UAT'a girdiğimizde, işletme sahibi uygulamayı bazı müşterilere ve dahili personele açmak istedi. Harici (DMZ) sunucularımızın çoğu Linux tabanlıdır ve DMZ’deki Windows sunucuları uygun değildi (kapasiteye çok yakın). Yeni donanım satın almak yerine, biri uygulamayı Mono'da çalıştırmayı önerdi. Kendi testimizi yapmak için birkaç gün harcadık ve ardından QA'ya, sonra da UAT'ye uyguladık. Sorun yaşamadık.
Proje başlangıcında gereksinim bize bildirilmişse, .NET'te yazmayı seçmemiş olabilirdik, ancak bu çok, çok geç bir gereksinim değişikliğinin güzel bir sonucuydu. Şimdi tekrar ortaya çıkarsa Mono’ya başarılı bir şekilde yerleştirebileceğimize eminiz (nihayetinde bazı kodları değiştirmek zorunda kalacağımızı düşünürsem de, şanslı olduğumuzu düşünüyorum).
Mono'yu ticari olarak kullanmamıştım, ancak özel olarak kullanıyorum, çünkü bir Windows şirketinde çalışıyorum, ancak özel olarak bir Linux kullanıcısıyım (bu yüzden işyerinde yaptığım şeyi yeniden kullanabilirim).
Genel olarak, şöyle diyor Miguel de Icaza ile aynı fikirdeyim:
- .NET uygulamalarının% 25'i mono ile kutunun dışında çalışıyor
- % 25 oranında bir gün veya daha kısa sürede çalışmak için yapılabilir
- bir hafta içinde% 25 daha çalışabilir
- Son% 25, uygulamanın tamamen yeniden yazılmasını gerektirir (WinForms / COM)
Mono oldukça iyi çalışıyor, ancak bazı sorunlar var:
- VB.NET sadece .NET için destek <= 2.0
- Windows kimlik doğrulaması uygulanmadı
- WPF uygulanmadı
- WCF desteği eksik
- Entity Framework uygulanmadı ve uygulama planları yok
- "ASP.NET Web Parts" uygulanmadı
- COM-birlikte çalışma desteği yok
- 15.5 sürümü için Sybase bağlantısı (en yeni) çalışmıyor
- C # sınıfı kütüphanesindeki hatalar ve eksiklikler (örneğin, XML mono <2.6'da buggy idi)
- Linux web tarayıcı kontrolü GTK # gerektirir
Sonra küçük sorunlar:
- Windows Forms çalışır, ancak her zaman düzgün şekilde oluşturulmaz
- MonoDevelop, Windows formları tasarlayamaz
- MonoDevelop 'adım adım' hata ayıklama gerçekten işe yaramıyor
- Mono-Service 5 saat sonra çöküyor ...
Söyleyebileceğim formu oluştur:
- Web Servisleri mükemmel çalışıyor
- Bir Web Uygulaması çalıştırırsanız, (WebParts kullanmıyorsa) oldukça iyi çalışır.
- WindowsForms çalıştırıyorsanız, her zaman çok hoş görünmeyecektir (en azını söyleyiniz).
- Microsoft Reporting Service için çalışma eşdeğeri yok (FYIreporting buna en yakın şey, ancak yavaş, hatalı ve çok eksik, artı bir yıldan beri hiçbir faaliyet yok)
- Word veya Excel belgeleri oluşturmanız gerekirse sorun yaşayacaksınız.
Linux üzerinde .NET geliştirmek istiyorsanız
- Orada ASP.NET geliştirebilirsiniz (hata ayıklama ve adım adım çok kötü çalışır)
- Linux'ta WinForms'i gerçekten geliştiremezsiniz
- WinForms yerine GTK # kullanmanız gerekir
Diğer bir deyişle:
- Mono, web uygulamalarını ve WebServisleri ve MailServisleri çalıştıran bir yere sahiptir.
- Ancak, WindowsForms uygulamalarını çalıştırmak uygun değildir, GTK # ile uygulama yazmanız gerekir.
- Bir raporlama çözümü ve MS dosya formatı desteği (veya bu nedenle çalışan kütüphanelerden) yoksundur
Düzenleme (2015 güncelleme):
Şimdiye kadar 'adım adım' hata ayıklamanın mükemmel şekilde çalıştığını ve Linux'ta web uygulamalarını geliştirmek için nuGet bağımlılıklarıyla bile MonoDevelop'u kullanabileceğini eklemek istedim. Excel ve Word kitaplıklarıyla ilgili problem de ortadan kalktı ve varlık çerçevesi şimdi açık kaynaklı. Gerisi "olduğu gibi" dır (mono-servisin sabit olup olmadığını bilmiyorum, ama umarım).
Bunun da artması, şimdi dağıtımınız için mevcut paketler alabilmenizdir, yani bir sonraki sürümüne kadar beklemenize gerek kalmaz, diyor Debian / Ubuntu, en son mono sürümünü alana kadar (kendiniz derlemek zorunda kalmadan) ). Bu önemli bir zaman tasarrufu.
Ayrıca, Roslyn'in piyasaya sürülmesi ile birlikte, VB.NET desteğinin yakın gelecekte daha iyi olması gerekir.
Şirketim, çoğunlukla - net bir masaüstü uygulaması geliştiriyor ve Mono'da çalışan Linux versiyonlarını yayınlıyor, bu yüzden evet diyeceğim, Mono'nun kurumsal Windows tabanlı çözümlerinde kesinlikle bir yer var.
Mono'yu uygulamamızın kurulumuyla paketliyoruz, kullanıcıların ayrı ayrı yüklemelerini istemiyoruz (ve böylece sürümü de kontrol ediyoruz).
Bence çoğu şirketin sahip olacağı asıl mesele Mono ve Microsoft arasındaki lisans sorunları. Anladığım kadarıyla, Microsoft Mono'nun çekirdek .NET teknolojilerini kullanabileceğini resmen kabul etmiş olsa da, bunun dışında, yaygın olarak kullanılan şeyler de dahil olmak üzere, yasal olarak Microsoft'un bir şekilde ya da hiç kesin bir konumu olmadığını belirten gri bir alan olduğu belirtiliyor. diğer.
Bu açık bir şekilde, lisans ücretlerini talep etme ya da sadece patent ihlali için dava açmaları olasılığını açık bırakmaktadır. Her ikisinin de şu anki davranış biçimlerinden kaynaklanması muhtemel değildir, ancak çoğu şirket bu tür belirsizlikten hoşlanmaz, özellikle de potansiyel yükümlülükler ve maliyetler söz konusu olduğunda değil.
Orada Mono için fazla yer olduğunu sanmıyorum:
Java, hem ticari hem de açık kaynak kodlu büyük bir topluluk ve çok sayıda kurumsal kalite kütüphanesi ve aracıyla Linux üzerine kurulmuş bir platformdur. Belirli bir durum söz konusu olmadıkça, Linux (veya Mac) hedefli yeni bir projeye başlarken Java üzerinden Mono'yu seçmem için hiçbir sebep göremiyorum (bakınız Walter'ın cevabı).
Mono kullanmadan önce, programda seri port için yol dizgisi ('Path.Combine ()) veya "COM" öneki (tamsayı yerine sadece dizgiyi kabul et)) sabit kodlanmış' \ 'olmamamız gerekir.
Ne işe yarar:
Karşılaşılan sorunlar:
Monoyu dahili olarak (ERP sistemi gibi) kontrollü bir ortam olarak kullanmak daha iyidir.
Mono, platformlar arası bir ortamda çalıştırılması gereken .NET kodunuz varsa, harika bir alternatiftir. Mono özellikle bu sorunu çözmek için iş dünyasında oldukça yaygın bir şekilde kullanılıyor.
Mono'nun varlığını, .NET ile platformlar arası olması gerektiğini bildiğiniz bir projeye başlamak için bir bahane olarak kullanmaya karşı çıkacağım. Bunun nedeni, en son teknoloji ile .NET ile Mono'nun geliştirme hızları arasındaki gecikmedir.
Öte yandan, Mono'yu gelecekteki bir projede kullanmayı düşünürseniz , Mono çerçevesini hedeflemeniz ve .NET'te ikincil bir alternatif olarak çalıştırmanız konusunda sizi uyarırım çünkü Mono büyük ölçüde tam olarak işlevselliğin bir alt kümesidir.