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ę?
Odpowiedzi:
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).
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.
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ę).
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.
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).
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:
Napotkane problemy:
Lepiej jest używać mono wewnętrznie (np. Systemu ERP) jako kontrolowanego środowiska.
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.