Czy Mono ma miejsce w świecie przedsiębiorstw?

22

W przypadku rozwiązań opartych na systemie Windows dla przedsiębiorstw najlepszym rozwiązaniem jest .NET. Jak patrzą na Mono przedsiębiorstwa, które muszą korzystać z Linuksa (a raczej wolą Linuksa)? Zakładając, że programiści nie stanowią problemu i znają platformę .NET / Mono oraz innych potencjalnych konkurentów, takich jak Java.

Czy średnia / duża firma uruchomiłaby Mono na swoich serwerach jako przeciwieństwo technologii takich jak Java? Czy znasz taką firmę?

Daniel
źródło

Odpowiedzi:

22

Użyliśmy go w dużej korporacji, w której pracuję. Nie planowaliśmy tego od początku projektu, ale tak się po prostu udało.

Mieliśmy wewnętrzny projekt, który opracowaliśmy w .NET. Po wejściu do UAT właściciel firmy chciał otworzyć aplikację dla niektórych klientów, a także dla personelu wewnętrznego. Większość naszych zewnętrznych serwerów (DMZ) jest oparta na systemie Linux, a serwery Windows znajdujące się w strefie DMZ nie były dobrze dopasowane (zbyt blisko pojemności). Zamiast kupować nowy sprzęt, ktoś zaproponował uruchomienie aplikacji na Mono. Spędziliśmy kilka dni na przeprowadzaniu własnych testów, a następnie wydaliśmy aplikację do kontroli jakości, a następnie UAT. Nie mieliśmy problemów.

Gdybyśmy otrzymali wymaganie na początku projektu, moglibyśmy nie napisać go w .NET, ale był to jeden miły wynik bardzo, bardzo późnej zmiany wymagań. Teraz jesteśmy całkiem pewni, że gdyby to się powtórzyło, moglibyśmy z powodzeniem wdrożyć Mono (chociaż sądzę, że w końcu będziemy musieli ulepszyć kod, myślę, że po prostu mieliśmy szczęście).

Walter
źródło
5
Ładna historia wojenna.
15

Nie korzystałem z mono w celach komercyjnych, ale używam go prywatnie, ponieważ pracuję w firmie Windows, ale prywatnie jestem użytkownikiem Linuksa (dzięki czemu mogę ponownie wykorzystać to, co robię w pracy).

Ogólnie zgadzam się z Miguelem de Icazą, który mówi:

  • 25% aplikacji .NET działa od razu z mono
  • kolejne 25% można zmusić do pracy w ciągu jednego dnia lub krócej
  • kolejne 25% może zostać wprowadzone do pracy w ciągu tygodnia
  • Ostatnie 25% wymaga pełnego przepisania aplikacji (WinForms / COM)

Mono działa dość dobrze, ale są pewne problemy:

  • Obsługa VB.NET tylko dla .NET <= 2.0
  • Uwierzytelnianie systemu Windows nie zostało zaimplementowane
  • WPF nie został zaimplementowany
  • Obsługa WCF jest niekompletna
  • Entity Framework nie został zaimplementowany i nie ma planów wdrożenia
  • „Składniki Web Part ASP.NET” nie zostały zaimplementowane
  • Brak obsługi COM-interop
  • Połączenie Sybase dla wersji 15.5 (najnowszej) nie działa
  • Błędy i niekompletność w bibliotece klasy C # (np. XML był błędny w mono <2.6)
  • Sterowanie przeglądarką Linux w przeglądarce wymaga GTK #

Następnie drobne problemy:

  • Formularze Windows działają, ale nie zawsze są poprawnie renderowane
  • MonoDevelop nie może projektować formularzy Windows
  • Debugowanie „krok po kroku” MonoDevelop tak naprawdę nie działa
  • Mono-Service ulega awarii po 5 godzinach ...

Utwórz to, co mogę powiedzieć:

  • WebServices działa doskonale
  • Jeśli uruchomisz aplikację sieci Web, działa ona dość dobrze (jeśli nie korzysta z WebParts).
  • Jeśli korzystasz z WindowsForms, nie zawsze będzie to ładnie wyglądało (co najmniej).
  • Nie ma działającego odpowiednika dla Microsoft Reporting Service (raportowanie FYI jest najbliższe, ale jest powolne, błędne i bardzo niekompletne, a także brak aktywności od ponad roku)
  • Będziesz mieć problemy, jeśli będziesz musiał utworzyć dokumenty Word lub Excel.

Jeśli chcesz rozwijać .NET w systemie Linux

  • Możesz tam stworzyć ASP.NET (debugowanie i krok po kroku działa bardzo źle)
  • Naprawdę nie można opracować WinForms w systemie Linux
  • Musisz użyć GTK # zamiast WinForms

Innymi słowy:

  • Mono ma swoje miejsce w uruchamianiu aplikacji internetowych oraz WebServices i MailServers.
  • Ale uruchamianie aplikacji WindowsForms nie jest opłacalne, musisz pisać aplikacje za pomocą GTK #
  • Brakuje w nim rozwiązania raportowania i obsługi formatu plików MS (lub bibliotek roboczych)



Edycja (aktualizacja 2015):
Chciałem dodać, że do tej pory debugowanie krok po kroku działa doskonale i możesz używać MonoDevelop do tworzenia aplikacji internetowych w systemie Linux, nawet z zależnościami nuGet. Problem z bibliotekami Excel i Word również zniknął, a struktura encji jest teraz typu open source. Reszta jest właściwie „taka, jaka jest” (nie wiem, czy mono-usługa jest naprawiona, ale mam taką nadzieję).
Poprawił się także fakt, że możesz teraz mieć aktualne pakiety dla swojej dystrybucji, co oznacza, że ​​nie musisz czekać do następnej wersji, powiedzmy Debian / Ubuntu, do momentu otrzymania najnowszej wersji mono (bez konieczności samodzielnego kompilowania ich) ). Jest to znacznie bezpieczniejsze czasowo.

Ponadto wraz z wydaniem Roslyn obsługa VB.NET powinna być znacznie lepsza w najbliższej przyszłości.

Kłopot
źródło
Nie miałem trudności ze wsparciem Winforms w Mono. To prawda, że ​​wynik nie jest dokładnie dziełem sztuki, ale dlatego, że nie działa w systemie Windows.
Robert Harvey
3
Uwaga: struktura encji jest teraz open source. zespół mono zaczął
włączać
@Robert Harvey: Grantet, wiele podstawowych rzeczy działa (np. Przycisk, widok drzewa, pola tekstowe, etykiety, a nawet siatki danych), ale jak tylko dodasz rozdzielacz, jest to „Nie zaimplementowany wyjątek”.
Quandary
14

Moja firma rozwija główną aplikację komputerową głównie w technologii .NET i wydaje wersje systemu Linux działające na Mono, więc powiedziałbym, że tak, zdecydowanie jest miejsce na Mono w korporacyjnych rozwiązaniach opartych na systemie Windows.

Pakujemy Mono wraz z instalacją naszej aplikacji, nie wymagając od użytkowników instalacji osobno (i w ten sposób kontrolujemy również wersję).

Adam Lear
źródło
Tak, musisz kontrolować, która wersja mono ma być używana. Ten wyposażony w dystrybucje linuksowe jest zwykle dość stary, więc zawiera więcej błędów. Od czasu do czasu wysyłamy to z gałęzi git mono-2-10 w celu ograniczenia błędów i wiemy, jakie ewentualne błędy może spotkać nasz program.
linquize
3

Myślę, że głównym problemem wielu korporacji jest kwestia licencji między Mono a Microsoft. Rozumiem, że chociaż Microsoft formalnie zgodził się, że Mono może korzystać z podstawowych technologii .NET, ale poza tym, w tym o bardzo często używanych rzeczach, jest to bardziej szara strefa z prawem, przy czym Microsoft nie określa jednoznacznej pozycji w ten sposób ani inny.

To oczywiście pozostawia otwartą możliwość, że w dalszej kolejności będą żądać opłat licencyjnych lub po prostu pozwać o naruszenie patentu. Jest mało prawdopodobne, aby tak się stało z ich obecnym zachowaniem, ale większość korporacji nie lubi tego rodzaju niepewności, szczególnie jeśli chodzi o potencjalne zobowiązania i koszty.

Jon Hopkins
źródło
3
Zrozumiałem, że specyfikacja CLR / C # nie jest zastrzeżona i Mono implementuje tę specyfikację bez większego (jeśli w ogóle) polegania na oryginalnym źródle .NET.
Adam Lear
5
@Anna: Może nie jestem ekspertem od tych rzeczy, ale jestem całkiem pewien, że Mono jest nadal zagrożone, niezależnie od tego, jak mało zależy od oryginalnego źródła .NET. Wynika to z patentów Microsoftu (które można egzekwować z Mono lub bez kopiowania kodu Microsoft). Myślę, że FSF zwięźle streścił problem tutaj: fsf.org/news/2009-07-mscp-mono
Adam Paynter
3

Nie sądzę, żeby było tam dużo miejsca dla Mono:

Java jest już ugruntowaną platformą Linux, z ogromną społecznością i mnóstwem bibliotek i narzędzi jakości dla przedsiębiorstw, zarówno komercyjnych, jak i open source. Nie widzę żadnego powodu, aby wybierać Mono zamiast Javy, kiedy rozpoczynam nowy projekt ukierunkowany na Linuksa (lub Maca), chyba że istnieją jakieś szczególne okoliczności (patrz odpowiedź Waltera).

Mladen Jablanović
źródło
7
Jednym z powodów może być to, że C # jest po prostu bardziej dojrzałym, lepiej zaprojektowanym językiem niż Java oraz łatwiejszą i bezproblemową pracą. To brzmi dla mnie bardzo przekonujący powód.
Konrad Rudolph
3
@Konrad: Dotyczy to najnowszych wersji C # (zaczęły się mniej więcej tak samo, ale rozwija się znacznie szybciej niż Java). Niestety z mojego doświadczenia wynika, że ​​przedsiębiorstwa rzadko wybierają język ze względu na swoje zalety. Z drugiej strony, zarówno .NET, jak i JVM oferują alternatywne języki, prawdopodobnie lepiej zaprojektowane niż zarówno C #, jak i Java, więc tak naprawdę nie faworyzowałbym się nawzajem na tej podstawie.
Mladen Jablanović,
Gdyby Mono było dostępne wcześniej, rozważylibyśmy .Net / Mono dla naszego środowiska. Tak się jednak nie stało, więc jesteśmy już na ścieżce Java. Możemy trochę popracować w .Net / Mono, ale podstawowym środowiskiem jest Java i oczekuje się, że tak pozostanie przez dłuższy czas. Będąc kimś, kto działa w obu przypadkach, nie dostaję bashowania Java od C # ers. Są BARDZO podobne. Język C # jest nieco lepszy, ale biblioteki Java i dodatkowe języki JVM są lepsze. Ogólnie biorąc, platformy są prawie równe. Biblioteka jest dla mnie ważniejsza, więc mogę nawet pokiwać głową w Javie.
Brian Knoblauch,
1
Mono pozwala używać C # w systemie Linux. C # ma tak wiele cukru syntaktycznego, aby ułatwić rozwój.
linquize
2015: Java jest obywatelem drugiej klasy na OS X (Mac). Mono działa pięknie w systemie OS X (choć WinForms jest wciąż wolny i brzydki). A dzięki OmniSharp możesz uzyskać różnego rodzaju narzędzia do edycji jakości IDE w edytorach innych niż IDE (Sublime, Atom, Vim, Emacs).
Kent A.
1

Przed użyciem mono musimy upewnić się, że w programie nie ma zakodowanego „\” dla ciągu ścieżki (użyj Path.Combine ()) lub prefiksu „COM” (po prostu zaakceptuj ciąg zamiast liczby całkowitej) dla portu szeregowego.

Co działa dobrze:

  • Aplikacja konsoli
  • Aplikacja internetowa

Napotkane problemy:

  • WinForms niestabilny: awaria losowo.
  • Obsługa języków: Społeczność może nie znać dobrze każdego języka, zwłaszcza dialektów w niektórych krajach / miastach. Odpowiednie ustawienia narodowe / zestawienia mogą zostać pominięte.
  • Rzadko stosowane metody mogą mieć niezgodne działanie z .NET.
  • xsp obsługuje tylko HTTP 1.0. Obecnie brakuje wsparcia HTTP 1.1.
  • Kontrola przeglądarki nie działa dobrze.

Lepiej jest używać mono wewnętrznie (np. Systemu ERP) jako kontrolowanego środowiska.

linquize
źródło
0

Mono to świetna alternatywa, jeśli masz już kod .NET, który musi działać w środowisku wieloplatformowym. Mono jest dość szeroko stosowane w świecie biznesu, aby rozwiązać ten problem.

Argumentowałbym przeciwko używaniu Mono jako pretekstu do rozpoczęcia projektu z .NET, o którym wiesz, że będzie musiał być wieloplatformowy. Powodem tego jest opóźnienie między najnowocześniejszym systemem .NET a szybkością rozwoju Mono.

Z drugiej strony, jeśli nie zamierzasz używać Mono w projekcie przyszłości, chciałbym ostrzec, aby kierować ramy Mono i uruchomić na .NET jako wtórny alternatywa od Mono jest w dużej mierze podzbiorem pełnej funkcjonalności .NET.

tylerl
źródło