Mono (oprogramowanie)

Mono

Logo programu
Autor	Xamarin (wcześniej Ximian przejęty później przez Novell) oraz społeczność Mono
Pierwsze wydanie	30 czerwca 2004
Aktualna wersja stabilna	6.12.0.206 (13 lutego 2024) [±]
Aktualna wersja testowa	6.12.0.184 (4 sierpnia 2022) [±]
Platforma sprzętowa	x86, x86-64, ARM, MIPS, PowerPC, SPARC, IA-64
System operacyjny	Windows, GNU/Linux, OS X, Unix, BSD, Solaris, iOS, Android, Windows Phone
Rodzaj	środowisko uruchomieniowe
Licencja	GPLv2, LGPLv2 i MIT
Strona internetowa

Mono – zestaw narzędzi umożliwiający uruchamianie programów stworzonych dla platformy .NET Framework, w skład których wchodzi między innymi kompilator języka C# oraz środowisko CLR (Common Language Runtime).

Celem Mono jest nie tylko umożliwienie uruchamiania aplikacji stworzonych dla platformy Microsoft .NET na różnych platformach, ale również umożliwienie twórcom oprogramowania dla systemu GNU/Linux znacznie szerszego rozwoju.

Mono może być uruchamiane na wielu systemach operacyjnych, włączając w to Androida, Windows Phone, większość dystrybucji GNU/Linuksa, BSD, OS X, Windows, Solaris. Wspierane są również konsole do gier, takie jak: PlayStation 3, Nintendo Wii i Xbox 360.

Logiem Mono jest głowa małpy widziana z profilu. Z języka hiszpańskiego mono oznacza właśnie małpę.

Historia Mono

Historia Mono sięga roku 2000, w którym to Microsoft opublikował .NET Framework, określając go jako „nową platformę bazującą na internetowych standardach”. W grudniu tego roku CLI, czyli Common Language Infrastructure, została ogłoszona jako otwarty standard ECMA-335, otwierając tym samym drogę do powstania niezależnych i otwartych implementacji tego standardu.

Miguel de Icaza z firmy Ximian zauważył, że w platformie .NET drzemie potencjał, który umożliwi zwiększenie produktywności powstającego kodu i ułatwi pracę programistów. Dodatkowo umożliwi ona tworzenie aplikacji wieloplatformowych bez konieczności korzystania z natywnego języka dla danej platformy. W związku z tym rozpoczęto prace nad przygotowaniem implementacji platformy .NET dla systemu Linux. Wkrótce okazało się, że projekt ten jest zbyt obszerny, aby poradziła sobie z nim niewielka garstka programistów. W związku z tym, 19 lutego 2001 roku, na konferencji O’Reilly ogłoszono rozpoczęcie prac nad otwartym projektem Mono.

Po trzech latach pracy, 30 stycznia 2004 roku opublikowano Mono 1.0. Z małego projektu, którego początkowym założeniem było stworzenie platformy programistycznej dla desktopowej wersji systemu Linux, stało się ono platformą programistyczną, która umożliwiała uruchamianie aplikacji przystosowanych dla środowiska .NET Framework na szerokiej gamie platform sprzętowych i na wielu systemach operacyjnych, wliczając w to systemy wbudowane.

Po tym, jak w kwietniu 2011 roku Novell został wykupiony przez Attachmate i rozpoczęła się fala zwolnień pracowników Novella, istnienie i dalszy rozwój projektu Mono stanął pod znakiem zapytania. 16 maja 2011 roku po tym, jak został zwolniony z firmy Novell, Miguel de Icaza ogłosił na swoim blogu, że prace nad Mono będą kontynuowane przez firmę Xamarin, którą właśnie założył. Grupa, która w Novellu pracowała nad projektem Mono, została zatrudniona w Xamarinie. Wtedy też pojawiła się informacja, że Xamarin będzie nie tylko kontynuował prace nad Mono w swojej pierwotnej formie, ale również stworzy od podstaw port komercyjnego środowiska .NET dla systemy iOS i Android, gdyż Novell posiadał prawa do MonoTouch dla iOS i Mono for Android dla systemu mobilnego firmy Google.

Po tym wpisie na blogu głównego twórcy Mono pojawiło się wiele komentarzy na temat dalszego rozwoju projektu, gdyż MonoTouch i Mono for Android były własnością Attachmate, które przejęło Novella. Nowej inicjatywie zarzucano, że pojawią się trudności z udowodnieniem tego, że nie będzie ona bezpośrednio wykorzystywać technologii, które zostały wcześniej opracowane przez tych samych pracowników, którzy tworzyli je w Novellu.

Jednak w lipcu 2011 roku Novell będący już częścią Attachmate i Xamarin zawarły porozumienie, w którym udzielono wieczystej licencji na Mono, MonoTouch i Mono for Android firmie Xamarin. Dzięki temu Xamarin może oficjalnie wykorzystywać wcześniejsze prace i gospodarować całym projektem.

Aktualny status prac i plany na przyszłość

Wersja 3.2.1 (wydana w sierpniu 2013 roku) oferuje podstawowe API .NET Framework, wsparcie dla języków Visual Basic.NET i C# w wersjach 2.0, 3.0 i 4.0, technologię LINQ to Objects, XML i SQL.

W chwili obecnej C# 4.0 jest domyślnie wykorzystywany przez kompilator języka C# dostępny w Mono. Dodatkowo wspierany jest graficzny interfejs programowania aplikacji Windows Forms 2.0, ale jego implementacja nie jest jeszcze kompletna. Obecnie głównym celem Mono jest zapewnienie pełnego wsparcia dla wszystkich udogodnień .NET 4.0 takich jak WF (Windows Workflow Foundation) oraz w pewnym stopniu WCF (Windows Communication Foundation). Wyjątkiem jest tutaj WPF (Windows Presentation Foundation), który nie jest wspierany ze względu na ogrom pracy, jaki należałoby włożyć, aby funkcjonował on poprawnie.

Część z funkcjonalności .NET Framework będących w fazie rozwoju jest częścią subprojektu Mono, któremu nadano nazwę Olive. W projekcie Mono znalazło się również miejsce dla kompilatora i środowiska uruchomieniowego Visual Basic .NET. Pracami nad portem VB.NET zajmuje się Rolf Bjarne Kvinge.

Moonlight

W skład projektu Mono wchodzi również otwarta implementacja technologii Silverlight, która nazwana została Moonlight. Jest ona dostępna od wersji Mono 1.9. Moonlight 1.0, które wspiera API Silverlight 1.0 zostało udostępnione w 20 stycznia 2009 roku. Moonlight 2.0 daje możliwości Silverlight 2.0 oraz część z funkcjonalności Silverlight 3.0. Wersja preview Moonlight 3.0, ogłoszona w lutym 2010 roku, dodała wsparcie Silverlight w wersji 3. Jednak rozwój Moonlight został oficjalnie zakończony 29 maja 2012 roku. Oficjalnym powodem była decyzja Miguela, który stwierdził, iż istnieją dwa czynniki, które powodują, że dalszy rozwój skazany jest na porażkę – sztuczne ograniczenia Microsoft, które powodują, że Silverlight jest bezużyteczny przy tworzeniu aplikacji na komputery osobiste oraz brak wystarczającej popularności w Internecie, która napędzałaby dalszy rozwój.

Sam rozwój Silverlight został porzucony przez Microsoft w 2012 roku.

Komponenty Mono

Mono składa się z trzech grup komponentów:

1. Głównych komponentów (Core Components)
2. Stosu deweloperskiego Mono/Linux/GNOME
3. Stosu zgodności z systemami Microsoft

Główne komponenty

Główne komponenty zawierają kompilator C#, wirtualną maszynę dla CLI oraz główne biblioteki klas .NET. Bazują one na standardach Ecma-334 i Ecma-335, przez co Mono jest wolną i otwartą wirtualną maszyną CLI.

Oba standardy na których bazuje projekt mono, zostały udostępnione przez Microsoft jako OSP (Open Specification Promise), czyli zobowiązanie Microsoft do otwartego rozpowszechniania specyfikacji.

Mono/Linux/GNOME

Stos rozwojowy Mono/Linux/GNOME dostarcza narzędzi i aplikacji deweloperskich z wykorzystaniem istniejącego środowiska GNOME oraz wolnych i otwartych bibliotek kodu. W jego skład wchodzą:

• Gtk# do tworzenia GUI (Graphical User Interface)
• biblioteki Mozilli do pracy z silnikiem renderującym Gecko
• biblioteki zgodności z Unix (Mono.Posix)
• biblioteki do komunikacji z bazami danych
• stos zabezpieczeń
• RelaxNG (REgular Language for XML Next Generation) – czyli schemat językowy dla XML-a.

Gtk# umożliwia integrację aplikacji tworzonych w Mono z pulpitem Gnome jako aplikacji natywnych. Biblioteki baz danych dostarczają możliwość połączenia z najpopularniejszymi bazami danych, takimi jak: db4o, Firebird, Microsoft SQL Server (MSSQL), MySQL, ODBC, Oracle, PostgreSQL, SQLite oraz z innymi popularnymi silnikami baz danych. O tym, jakie bazy danych są obsługiwana twórcy projektu informują na bieżąco na swojej stronie internetowej.

Zgodność z systemami Microsoft

Stos zgodności z produktami firmy Microsoft zapewnia możliwość portowania aplikacji MS .NET Framework do systemu GNU/Linux. Ta część umożliwia wykorzystanie ADO.NET, ASP.NET i Windows Forms. Komponenty te nie są ustandaryzowane przez Ecma, część z nich możliwa była do udostępnienia dzięki umowom między Novellem a Microsoftem.

Architektura frameworka

Główne komponenty Mono zawierają;

• Silnik wykonania kodu (Code Execution Engine)
• Biblioteki klas
  • Podstawowe biblioteki klas
  • Biblioteki zapewniające zgodność z platformą.NET
  • Charakterystyczne dla Mono biblioteki klas:
    • Międzyplatformowe biblioteki klas dla Mono i .NET Framework (Gtk#, Mono.Cecil, Mono.CSharp, Text.Templating)
    • Charakterystyczne dla Unixa biblioteki klas (POSIX, FUSE (Filesystem in Userspace))
    • Specyficzne dla danej platformy biblioteki klas (umożliwiające połączenie Mono z Mac, iOS, Android i MeeGo)
  • Kompilatory CLI
  • Metadane CLI
  • MonoCLR (Mono Common Language Runtime)
    • Zgodne ze standardami ECMA CLI/.NET CLR
    • Rozszerzenia typowe dla Mono:
      • Wsparcie dla Mono.SIMD
      • Dodatkowe funkcje, metody, kontynuacje i podproframy
  • Charakterystyczne dla Mono rozszerzenia
  • Natywne usługi do współpracy z istniejącymi już komponentami i obiektami COM
  • Wsparcie dla Microsoftowego Security – Transparent Code Framework (.NET 4.5)

Code Execution Engine

Środowisko uruchomieniowe Mono zawiera silnik, który umożliwia tłumaczenie kodu bitowego ECMA CIL do kodu natywnego, który może zostać wykonany na różnych architekturach procesorów: ARM, MIPS (jedynie wersji 32-bit), SPARC, PowerPC, S390 (w trybie 64-bit), x86, x86-64 I IA-64 w trybie 64-bit.

Generator kodu może działać w trzech trybach:

• JIT (Just-in-time) – środowisko uruchomieniowe może w locie zamieniać kod ECMA CIL do natywnego kodu, który może zostać wykonany na urządzeniu
• AOT (Ahead-of-Time) – w tym trybie kompilator zamienia kod ECMA CIL na kod natywny, który przechowywany jest w formacie charakterystycznym dla danego systemu operacyjnego, architektury systemu komputerowego i CPU) (np. dla plików *.exe, w systemie Linux zostaną wygenerowane pliki *.exe.so). Ten sposób generowania kodu jest najszerzej stosowany, gdyż większość kodu jest kompilowana przed jego użyciem, a nie tak jak ma to miejsce w przypadku kompilatora JIT, tuż przed użyciem. Oczywiście część kodu nadal potrzebuje kompilatora JIT (np. obsługa trampolin czy kodu zarządzającego), także powstałe pliki nie są do końca samowystarczalne.
• Pełna kompilacja statyczna – w tym przypadku kod kompilowany jest całkowicie. Wykorzystane są wszystkie elementy z kompilacji AOT oraz dodatkowo wszelkie trampoliny, funkcje obudowujące (wrappery) i dane Proxy, które zostały wykorzystane są wkompilowane do ostatecznego pliku, który może zostać podłączony do programu i kompletnie wyeliminować użycie kompilatora JIT. Możliwość takiej kompilacji istnieje tylko na niektórych z platform, wykorzystana jest w szczególności na systemie iOS i na konsolach PlayStattion 3 i Xbox 360.

Począwszy od wersji Mono 2.6, istnieje możliwość takiej konfiguracji środowiska, aby używać LLVM (ang. Low Level Virtual Machine – maszyna wirtualna niskiego poziomu) jako głównego silnika generowania kodu, zamiast silnika Mono. Ta funkcjonalność jest bardzo przydatna w przypadku programów wykorzystujących duże zasoby komputera oraz w przypadku, gdy szybkość i wydajność wykonania kodu jest ważniejsza niż wydajność uruchomienia aplikacji.

Od Mono w wersji 2.7 Preview nie ma już potrzeby wyboru silnika generującego kod w trakcie konfiguracji, gdyż może on zostać wybrany jako parametr startowy środowiska (jako jedna z dwóch opcji startowych: –llvm lub –nollvm). Dzięki temu w szybki sposób można wybrać potrzebny w danej chwili generator kodu.

Garbage Collector

Od Mono 2.8 dostarczane były 2 wersje garbage collectora: wielopoziomowy garbage collector (generational collector) oraz konserwatywny garbage collector Bohema (Bohem conservative collector).

Przed wersją Mono 3.1.1 domyślny garbage collector (Bohem-Demers-Weiser GC) zawierał kilka poważnych ograniczeń w stosunku do komercyjnych silników GC zaimplementowanych w środowiskach takich jak maszyna wirtualna Javy czy .NET Framework.

Użycie garbage collectora w długo działających aplikacjach serwerowych może powodować poważne błędy, ze względu na fakt, iż silniki GC mogą wywoływać chwilowe wycieki pamięci w niektórych typach aplikacji.

W październiku 2010 roku zaprezentowano garbage collector nowej generacji – Sgen-GC (Simple Generational Garbage Collector). Stał się on integralną częścią Mono 3.1.1 i jest on tam domyślnym silnikiem GC. W wersjach Mono 2.8 – 3.1.0 może on zostać wybrany przez użytkownika jako silnik garbage collectora poprzez argument, z którym zostanie uruchomione środowisko (–gc=sgen). Nowy garbage collector ma wiele udogodnień w stosunku do swoich poprzedników, w szczególności do najbardziej rozpowszechnionego sinika CG Bohema. Wykorzystuje on mechanizm generational garbage collection.

Biblioteki klas

Biblioteki klas dostarczają kompleksowy zestaw narzędzi do tworzenia aplikacji. Są one w większości napisane w języku C#, ale zgodnie ze specyfikacją CLS (Common Language Specification) mogą one zostać użyte w którymkolwiek języku dostępnym na platformę .NET. Biblioteki klas zebrane są w przestrzenie nazw i opublikowane w postaci współdzielonych bibliotek zebrane w większe zestawy.Odwoływanie się do jakichkolwiek klas .NET Framework powoduje właśnie wywołanie wspomnianych bibliotek.

Przestrzenie nazw i klasy

Przestrzenie nazw (ang. namespaces) są mechanizmem logicznego zebrania podobnych do siebie klas w hierarchiczną strukturę. Dzięki temu o wiele łatwiej uniknąć jest konfliktów w nazewnictwie. Przestrzenie nazw zaimplementowane są z wykorzystaniem notacji słów oddzielonych kropkami, dzięki czemu zawsze wiadomo, z której przestrzeni nazw w danej chwili się korzysta. Dodatkowo w większości przypadków nadrzędną przestrzenią nazw jest przestrzeń System, więc podrzędne przestrzenie otwierane są jako System.IO (dla operacji wejścia/wyjścia) czy System.Net (dla elementów składowych .NET Framework). Oczywiście istnieje o wiele więcej nadrzędnych przestrzeni nazw, jak na przykład Accessibility czy Windows.

Środowisko MonoDevelop

MonoDevelop jest darmowym, zintegrowanym środowiskiem programistycznym dla środowiska graficznego GNOME, które zostało zaprojektowane do współpracy z językiem C# i innymi językami .NET, takimi jak Nemerle, Boo i Java (poprzez IKVM.NET). Dodatkowo wspiera ono takie języki jak C, C++, Python, Java czy Vala.

Początkowo MonoDevelop było portem środowiska SharpDevelop do Gtk#, ale później wyewoluowało w narzędzie, które miało sprostać potrzebom bardzo szybko rozrastającej się społeczności użytkowników. Obecnie IDE zawiera system zarządzania klasami, wbudowaną pomoc, uzupełnianie kodu, program Stetic umożliwiający tworzenie interfejsu użytkownika, wsparcie dla projektów i zintegrowany debugger.

Przeglądarka MonoDoc daje dostęp do dokumentacji API i do przykładowego kodu. Dokumentacja wykorzystuje styl wiki, umożliwiając dostęp do edycji i poprawek dla każdego użytkownika.

MonoTouch i Mono for Android

MonoTouch i Mono for Android są implementacjami Mono dla smartfonów opartych o system iOS i Android. Są one wydane jedynie na licencji komercyjnej, za którą należy zapłacić.

Xamarin.iOS (MonoTouch)

Xamarin.iOS (wcześniej nazywane MonoTouch) jest biblioteką, która umożliwia programistom tworzenie aplikacji w języku C# opartych na platformie .NET, które można uruchomić na urządzeniach firmy Apple, takich jak: iPhone, iPod czy iPad. Bazuje ona na frameworku Mono i powstaje przy współpracy firmy Xamarin z firmą Novell.

Niestety poprzez architekturę systemu na urządzeniach wyprodukowanych przez firmę Apple, aplikacje nie mogą wykorzystywać kompilatora JIT. Wynika to z faktu, że jądro systemu iOS nie umożliwia uruchomienia maszyny wirtualnej. Aplikacje tworzone z użyciem bibliotek zawartych w Xamarin.iOS są kompilowane do kodu maszynowego, który może zostać zinterpretowany przez iPada, iPhone’a czy iPoda.

W skład Xamarin.iOS wchodzą:

• Kompilatory:
  • Kompilator C# (ten sam, który wchodzi w skład Mono)
  • Kompilatory firm trzecich, takie jak RemObject's Oxygene, który może być nakierowany na kompilację Xamarin.iOS
• Biblioteki .NET
• Deweloperskie SDK:
  • Linker – wykorzystany do powiązania kodu wykorzystanego w ostatecznej wersji aplikacji
  • Mtouch – natywny kompilator i narzędzie, które umożliwia opublikowanie aplikacji na urządzeniu końcowym
  • Interface Builder – narzędzie do budowy interfejsu graficznego
• Biblioteki, które umożliwiają wykorzystanie natywnego CocoaTouch API
• Xamarin Studio IDE – IDE do pracy z kodem

Xamarin Studio używane jest jako domyślne IDE, ale korzystając z systemu Mac OS X można użyć programu Xcode i wbudowanego w niego symulatora systemu iOS.

Od kwietnia do września 2010 roku, dalsze losy MonoTouch stanęły pod znakiem zapytania. Powodem tego były zapowiedziane przez Apple nowe warunki dla twórców aplikacji, które jednoznacznie zabraniały korzystania z innych języków niż C, C++ czy Objective-C na tej platformie oraz zakazywały stosowania dodatkowej warstwy wirtualizacji pomiędzy platformą iOS a aplikacjami. Te same restrykcje miały objąć również inne technologie, jak na przykład UNITY. Jednak we wrześniu 2010 roku Apple zniosło te restrykcje i umożliwiło dalszy rozwój projektu.

Xamarin.Android (Mono for Android)

Xamarin.Android (pierwotnie znano jako Mono for Android) zostało stworzone przez firmę Novell, a następnie rozwinięte przez firmę Xamarin jako implementacja Mono dla smartfonów bazujących na systemie Android.

Pierwsze wydanie pojawiło się 6 kwietnia 2011 roku. Mono for Android zostało stworzone, aby umożliwić twórcom oprogramowania w znacznie łatwiejszy sposób pisanie multiplatformowych aplikacji, które mogą zostać uruchomione na urządzeniach mobilnych.

W wywiadzie udzielonym dla H-Online, Miguel de Icaza powiedział:

Our vision is to allow developers to reuse their engine and business logic code across all mobile platforms and swapping out the user interface code for a platform-specific API.

Miguel de Icaza

Słowa te utorowały drogę do rozwoju implementacji platform .NET dla system Android.

W sierpniu 2010 roku rzecznik firmy Microsoft, Tom Hanrahan pracujący w Microsoft Open Source Technology Centre odniósł się do pozwu sądowego wniesionego przeciwko Google, które używało w Androidzie Javy rozwijanej przez Oracle:

The type of action Oracle is taking against Google over Java is not going to happen. If a .NET port to Android was through Mono it would fall under the Microsoft Community PromiseAgreement.

Tom Hanrahan

Przyczyniło się to do szybkiego rozwoju implementacji .NET dla Androida.

W skład Xamarin.Android wchodzą:

• Środowisko uruchomieniowe Mono
• Edytor interfejsu graficznego dla systemu Android
• Biblioteki:
  • Bazowe biblioteki klas .NET
  • Biblioteki, które umożliwiają połączenie z natywnym Android/Java API
• Narzędzia SDK do tworzenia wynikowych projektów, publikacji na urządzeniach i debugowania aplikacji
• Oprogramowanie integrujące XamarinStudio i Visual Studio 2010, dzięki czemu z poziomu VS 2010 można zarówno publikować, jak i debugować aplikacje.

Systemy operacyjne

Mono współpracuje z systemami operacyjnymi GNU/Linux, UNIX, Mac OS X, Solaris, FreeBSD, OpenBSD, NetBSD, Wii, PlayStation 3, iOS, Android i Microsoft Windows.

Języki programowania

Możliwe jest uruchamianie aplikacji przeznaczonych dla .NET. Z platformą Mono mogą być używane m.in. kompilatory następujących języków programowania: C#, Java, Boo, Nemerle, Visual Basic.NET, Python, JavaScript, Oberon, PHP, Object Pascal, Lua oraz Cobra.

Zobacz też

• DotGNU

Linki zewnętrzne

• Strona domowa Mono
• Zbiór blogów ludzi rozwijających Mono
• Artykuł nt.: .NET sięgnie poza Windows
• Lista przydatnych narzędzi programistycznych dla Mono
• Prezentacja poświęcona tworzeniu przenośnych aplikacji w Mono