Mono 2.6 i Monodevelop 2.2
- Dodano: 16 grudnia 2009
- Wprowadził:
- Komentarze: 50
Otwartoźródłowa implementacja niektórych części .Net oraz związane z nią środowisko programistyczne Monodevelop doczekały się nowych wersji. Dwa słowa które najlepiej podsumują to wydanie to: debugger i wieloplatformowość twierdzi na swoim blogu – twórca projektu – Miguel De Icaza
Być może najbardziej ciekawe (oprócz listy nowości) w nowym mono 2.6 jest to, że ‘środek ciężkości’ zmian w projekcie, zdaje się przesuwać z reimplementacji technologii związanych z matczyną platformą windowsową ku pisaniu rzeczy nowych oryginalnie nieobecnych .NET
Nowe wydanie to prawie milion linii nowego kodu. Lista nowości jest równie imponująca i przynosi między innymi:
- Nowy soft debugger, który działa nieco inaczej od tradycyjnie rozumianego debuggera, jest stabilniejszy od swojego poprzednika i można go stosować do debugowania zarówno normalnych aplikacji biurkowych, jak i do programów mono na iPhone (komercyjny biblioteka monotouch) czy konsoli PS3.
- Implementację części WCF (framework komunikacyjny), która jest ‘rozumiana’ przez aplikację Silverlight 2.0.
- Wsparcie dla niskopoziomowej maszyny wirtualnej LLVM jako końcówki wymiennej z JIT engine, dzięki której można uzyskać bardziej wydajne programy wyjściowe, za cenę większego zużycia pamięci i dłuższego czasu kompilacji Tutaj więcej informacji
- Implemetacja LINQTOSQL w postaci LINQTODB (w przeciwieństwie do oryginału wspiera także mysql,firebird, postgresql i sqlite)
- Mono.Tasklets – bardzo ciekawy framework mikrowątków – szczegóły tutaj
- Lepsze pokrycie biblioteki .NET framework 3.5
- Dodano open sourcowe biblioteki Microsoftu: ASP.NET MVC , ASP.NET AJAX i Microsoft’s Dynamic Language Runtime (niezbędny dla .NET 4.0)
- Komenda csharp (coś a’la irb z Ruby) wspiera uzupełnianie komend
Środowisko programistyczne Monodevelop jest teraz licencjonowane wyłącznie na LGPL2 i MIT11. (usunięto wszystkie część na GPL aby umożliwić pisanie komercyjnych wtyczek). Najważniejsze zmiany w Monodevelop od wydania 2.0 to:
- IDE działa teraz na Linuksie, Windows i Mac Os
- Odświeżony wygląd aplikacji
- Obsługa języka makr T4 (również jako biblioteka do własnych zastosowań)
- Wsparcie dla projektów Moonlight (implemetacja Silverlight dla
Linuksa) - Nowe komendy refaktoryzacji
- Wtyczka do Python jest teraz oficjalnie wspierana
- Wtyczka do iPhone (wspomniany własnościowy framework Monotouch)
Oryginalna informacja o wydaniu 2.6 tutaj
Więcej informacji: http://www.mono-project.com/Release_Note...s_Mono_2.6
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze (RSS) | Trackback (URI)
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
50 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
Bardzo ładnie się to rozwija. Może kiedyś przegoni implementację Microsoftu
Nie tylko nigdy nie przegoni, ale i nigdy nie DOGONI, nawet jak Novell będzie w to pakował 5 miliardów dolarów rocznie. Dlaczego? Bo standardem de facto dla całego .Net jest Windows, a jak Mono zrobi .Net 4, to Microsoft ogłosi .Net 5 od razu demonstrując referencyjną implementację (jako zamknięte oprogramowanie rzecz jasna i nie pytając nikogo o zdanie jak ma to wyglądać).
@maciek – może i nigdy nie dogoni, ale możliwy jest inny rozwój sytuacji: ze względu na trudność dodawania nowej funkcjonalności do już bardzo bogatego oprogramowania, może się zdarzyć że któraś wersja .NET będzie uważana za coś w rodzaju Office 2007. Niby numerek wyższy i interfejs inny, ale firmy mogą chcieć być bardziej wieloplatformowe i skupić się np. na Mono implementujące w pełni .NET 5. Microsoft będzie oferował wtedy .NET 6 lub 7, ale różnica z Mono będzie się sprowadzać do niewielkiej różnicy w funkcjonalności i wielkiej różnicy w wieloplatformowości.
Powyżej .NET 2.0 wszystkie zmiany były przyrostowe – dodawały nowe technologie, jedne bardziej udane (WCF, LINQ), inne mniej. Mono rzeczywiście nigdy nie dogoni implementacji Microsoftu, bo zawsze będzie trochę z tyłu, a tempo dodawania nowych rzeczy (nie zawsze udanych) do .NETa jest ostatnio naprawdę duże; są też rzeczy które nie mają sensu na platformie innej niż Windows (COM+, MSMQ). Ale już teraz Mono niemal całkowicie implementuje .NET 2.0, który nadal stanowi 'rdzeń' wszystkich współczesnych .NET-owych aplikacji. Natomiast pozostałe technologie implementuje według stopnia użyteczności/popularności (np. WCF-HTTP, LINQ); mniej popularne zostawia (np. WF). Podsumowując: podobnie jak powiedział przedmówca – mimo że Mono będzie zawsze trochę z tyłu w stosunku do .NETa, to implementując pewien użyteczny/popularny podzbiór technologii .NET, może być wystarczające dla tych, którzy potrzebują wieloplatformowości.
AJ – 'mniej popularne' to chyba WPF a nie Windows Forms (WF) ?
Windows.Forms jest już w pełni zaimplementowane.
Ech, te skróty… Chodziło mi o WF – (Windows) Workflow Foundation (nie mylić z WWF – World Wildlife Fund albo World Wrestling Federation (obecnie Entertainment)
Mono w tym momencie nie ma zamiaru tego implementować (podobnie jak WPF), zwłaszcza że ma się sporo zmienić w .NET 4.0. 'Windows Forms' nie wiedzieć czemu nie skraca się do WF 
Mono już dogoniło c# 4.0, które będzie oficjalnie dopiero w przyszłym roku wraz z VS 2010.
Niezupełnie dogoniło – dopiero przyszła wersja ma mieć _kompilator_ zgodny z 4.0 – i zapewne DLR żeby było te nowości w czym uruchomić. (tak przynajmniej jest na Mono Roadmap). Nie znaczy to że będzie zaimplementowana pełna bibliotekę klas – niektórych nie zamierzają na razie (albo w ogóle) implementować. Moim zdaniem całkiem słusznie, bo nie wszystkie technologie w .NET >= 3.0 były udane, a i niektóre były bardzo szybko zastąpione zupełnie nowymi wersjami.
Akurat nieimplementowanie WPF'a uważam za największą bzdurę. Teraz może nie jest popularny, ale daje ogromne możliwości i w przyszłości na pewno będzie wykorzystywany. Windows Forms jest przestarzałe i w porównaniu z WPF nie tak wygodne i uniwersalne. Jest co prawda szybsze, ale to tylko kwestia czasu (postęp technologiczny sprzętu) i odrobiny optymalizacji, co pewnie będzie można uświadczyć w .NET 4.0 lub kolejnej.
Z technicznego punktu widzenia też uważam WPF za jedną z ciekawszych propozycji Microsoftu. Patrząc na to, jak bardzo Microsoft stara się promować Silverlight (a więc XAML, a więc pośrednio i WPF), widać jak bardzo próbują na to stawiać. Ale na razie jest to trochę zaklinanie rzeczywistości. Chociaż podobno samo Visual Studio 2010 zostało przepisane na WPF.
BTW to chyba WPF powinno być szybsze, bo komunikuje się bezpośrednio z DirectX, pomijając WinAPI (którego używa WinForms). Tyle że jak na razie designery WPF w VS kuleją w porównaniu do designerów WinFormsów – chociaż to się pewnie zmieni.
@NDyA, @AJ:
WPF się nie przyjmie. Już teraz widać, że MS całą parę pompuje w Silverlight, a Silverlight 4 ma właściwie wszystkie rzeczy które ma WPF, łącznie z trybem desktop (dostępnym już w 3 wersji), drukowaniem, obsługą kamery i mikrofonu, a nawet interfejsem COM (można np. zrobić ctrl-c ctrl-v z excela do aplikacji sl 4) a do tego wszystkiego jest z natury sieciowe (a WPF nigdy nie będzie). Pewne rzeczy jak np. framework animacji (Visual State manager) są już teraz lepsze w SL niż WPF, bo silverlight to po prostu poprawiony WPF.
Dlatego strategicznie olanie WPF i inwestowanie w moonlight bylo najlepsza rzeczą jaka się mogła monowcom przydarzyć.
Równoległy rozwój WPF i Silverlighta (wraz ze wszystkim podtypami) jest zapewne próbą Microsoftu pójścia "szerokim frontem" z nadzieją, że któryś z wariantów "zaskoczy". Ale rzeczywiście teraz chyba bardziej stawiają na Silverlight.
Tyle że jak na razie – pomimo tych wszystkich ciekawych rzeczy które w niego włożyli i posiadania bardziej nowoczesnego modelu programowania – Silverlight nie zdołał się jakoś przebić. Powody są różne – Flasha trudno wygryźć; ludzie też nie lubią instalować coraz to nowych wtyczek. Ktoś kiedyś filozoficznie stwierdził, że to karma – przez lata Microsoft zdążył napsuć krwi webmasterom i -developerom przez nietrzymające się standardów IE, to teraz webdeveloperzy ignorują to, co pochodzi od Microsoftu. Paradoksalnie z tego powodu Moonlight może pomóc Silverlightowi.
@NDyA – "Akurat nieimplementowanie WPF’a uważam za największą bzdurę. Teraz może nie jest popularny, ale daje ogromne możliwości i w przyszłości na pewno będzie wykorzystywany"
To jest temat na długą wojnę, ale zauważ że niekoniecznie WPF jest najlepszym rozwiązaniem kwestii GUI z punktu widzenia wszystkich zainteresowanych stron (użytkownicy różnych OS, MIcrosoft i inne firmy). Zgadzam się że WPF daje ogromne możliwe, ale też daje NIE WIĘKSZE możliwości niż np. SVG. SVG jest standardem, jest otwarty, posiada animacje i jest wektorowy. WPF jest oparty na XML (XAML), tak jak SVG. Stąd uważam, że WPF to wyważanie już otwartych drzwi. Takie wyważanie ma wg mnie sens TYLKO gdy Microsoft nie chce widzieć WPF na innych platformach niż Windows.
Jeszcze tego brakuje, aby M$ miał dogadzać wszystkim i wszystkich pytać o zdanie… demokrata się znalazł….
Ich produkt, ich prawo. Obowiązku używania nie ma.
A że mono wywaliło się z torów, to już inna broszka – jak każdy projekt OS dodają własne rzeczy zanim gotowe
Mono nie musi być zawsze zgodne z najnowszą wersją .NET framework.
Problem w tym, że nawet do wybranej wersji, powiedzmy 3.5 nigdy nie dociągnie. A jeżeli tylko spróbuje, to zaraz jakiś idiota zrobi forka i rozproszy środki…
Maćku – pełna zgoda. Zaplusowałem.
Dodam tylko, że w praktyce nie musi to wcale oznaczać, że Mono będzie z założenia czymś gorszym (jeszcze raz podkreślę – >>w praktyce<<) od .NET. Dlaczego? Bo wcale nie tak rzadko klienci mogą żądać oprogramowania pod starszą wersję .NET. Jak ma się już coś, co działa pod .NET 2.0, to wcale nie chce się zmieniać platformy na .NET 3.5 (czy jakie tam są wersje). Z podobnych powodów dziś wciąż używa się np. Cobola.
I wcale nie piszę tego jako zwolennik Mono (którym bynajmniej nie jestem). Po prostu spotkałem się już z takim przypadkiem, a szło o naprawdę duże pieniądze.
Aplikacja napisana w .NET 2.0 może być rozbudowywana o elementy w .NET 4.0; w COBOLU chodzi mnóstwo aplikacji zaczętych 50 lat temu, ale ich fragmenty wykorzystują Nowy COBOL i bynajmniej nie skompilujesz ich kompilatorem COBOL sprzed 50 lat.
Czy na pewno wersja 2.6 jest wydana? Na tej stronie pisze, że BĘDZIE wydana XXXX ("Mono 2.6 is scheduled to be released in XXXX"). Na mapie drogowej też nic nie ma o wydaniu tej wersji (http://mono-project.com/Roadmap).
Na pewno. Ta strona, którą pokazujesz jest niezaktualizowana.
Ogólnie to 2.6 jest wydana, ale chyba jeszcze nie ma pakietów na wszystkie platformy. Są na Windows i oczywiście na SuSE; na Debiana i Ubuntu jeszcze nie.
http://www.mono-project.com/Release_Notes_Mono_2…. tak tam jest XXXX, ale w downloadzie jest już 2.6
"… jest bardziej niezawodny …"
Aha, to wcześniej był niezawodny, a teraz bardzo niezawodny. Jaki będzie w następnej wersji?
'bardziej bardziej niezawodny' ?
zmienione. thx.
sudo apt-get remove –purge mono-common
sudo apt-get remove –purge mono-common libmono0
to jedyne co może czekać mono
No bo po co to komu. Jest java.
No dobra to jakie polecasz odpowiedniki Banshee, F-Spot, Tomboy i Gnome-do napisane w Javie ? Że zacytuje klasyka: 'show me the code'.
jlGui? Więcej nie chce mi się szukać. Wpisz w Google funkcję jaką ma pełnić program + java – pewnie znajdziesz odpowiednik większości programów… A że mniej popularny – cóż – na rzecz F-spota pewnie też coś musiało wylecieć…
Pomijając wygląd tego jlGui to taki Winamp a ja szukam czegoś bardziej w stylu iTunes.
Przez 15 lat istnienia java nie dorobiła się ciekawych oknowych aplikacji open source, bo nie było wygodnych powszechnie dostępnych narzędzi do ich tworzenia (mityczny gui designer). Jeśli chodzi o rozwój składni samego języka to javowcy też jakby zapadli w letarg (gdzie odpowiedniki: LINQ, lambda expressions, słówka kluczowego var ?). Java świetnie sprawdza się w technologiach webowych, ale na desktop się nie nadaje.
"Przez 15 lat istnienia java nie dorobiła się ciekawych oknowych aplikacji open source"
JEdit, SQL-Developer, Eclipse, Netbeans, IDEA, ThinkFree Office?
Pokaż mi odpowiedniki w .NET.
Java jednak faktycznie była bardziej promowana jako technologia na serwer i na razie głównie na tym polu rządzi. Jednak JavaFX ma szanse to zmienić.
@Królik: Podsumowujac, jedyne wartosciowe oprogramowanie Open Source w Javie to oprogramowanie do pisania oprogramowania w Javie. Faktycznie, doskonale swiadczy to o jezyku
ThinkFree Office nie jest "do pisania w Javie"
A JavaFX na własny język 
Prostszy od Prawdziwej Dżawy.
@trash, w sumie zgadzam się. Ale to tylko dlatego, że Sun olewał desktop zbyt długo, a koncentrował się na serwerach i oprogramowaniu, które nie musi być atrakcyjne wizualnie.
W sumie dopiero Java 6 nadaje się realnie do pisania aplikacji okienkowych (działa tak samo zwinnie jak .NET, o ile nie lepiej i wygląda przyzwoicie). Natomiast JavaFX wprowadza wiele innowacji, ale jest to b. nowy produkt i ma dużego konkurenta (Adobe Flex/AIR), który jednak też ma swoje problemy, które z kolei Java rozwiązała wiele lat temu (np. kiepskie GC, okropna pamięciożerność i ślamazarność).
BTW: Jedit też nie jest do pisania w Javie. Ja go używam do robienia:
- artykułów (LaTeX)
- prezentacji (LaTeX + Beamer)
- diagramów (LaTeX + PGF/TikZ)
- wykresów (LaTeX + PGFPlots)
IMHO 1000x lepszego Office'a trudno sobie wyobrazić.
@Królik: Java na desktopie nie ma szans z bardzo prostego powodu – z definicji musi sprowadzac oferowana funkcjonalnosc do najmniejszego wspolnego mianownika. W efekcie napisana w Javie aplikacja desktopowa pod kazdym systemem bedzie wygladala jak cos obcego, nie stosujac sie do przyjetych w danym systemie norm w rodzaju HIG-ow, i nie bedzie calkiem prawidlowo integrowala sie z reszta systemu. Z tego tez wynika brak aplikacji desktopowych w Javie, z wyjatkiem narzedzi do pisania w Javie, biznesowo-bazodanowych wynalazkow (w ktorych ergonomia i tak guzik autorow obchodzi), pewnego klienta torrentow i paru innych nieistotnych statystycznie szczegolow.
Zadziwiające, że gdy ten sam argument przytoczy się w stosunku do projektów OpenSource to zaraz słyszy się politpoprawną mowę-trawę o "różnorodności, wyborze" etc…
Czasem .NET jest duzo lepszy niz JAVA, przynajmniej na razie. Przeczytajcie przyklad z zycia ode mnie z pracy.
Mielismy w jednej instytucji panstwowej do napisania program, ktory by pozwalal walidowac dokumenty XML wzgledem XSD, udostepniany "klientom" instytucji za darmo. Program powinien pokazywac czytelny opis bledow w jezyku polskim i wskazywac mozliwe rozwiazania problemow z dokumentem XML. I tu zaczely sie schody.
Pospiesznie napisany w Java walidator tych plikow XML wszystkie komunikaty o bledach niezgodnosci z XSD wyswietlal w jezyku angielskim i naprawienie tego byloby bardzo karkolomne (wierze, ze pewnie mozliwe). To by pewnie wymagalo sporo czasu i pracy.
Platforma .NET z polskim pakietem jezykowym pozwalala natomiast od reki miec w walidatorze polskie komunikaty, co pozwalalo nam w bardzo krotkim czasie napisac walidator i skupic sie na jego logice biznesowej.
Ze wzgledu na odbiorcow, ktorzy maja czasem bardzo stare komputery, docelowa platforma .NET byla wersja 2.0, ktora to w pelni jest juz implementowana w Mono. Dzieki temu program walidatora moze byc z powodzeniem uzywany przez roznych klientow i na roznych platformach systemowych.
Mozna sie czepiac Mono, jak sie bardzo chce, ale nie mozna nie doceniac tego, ze stwarza olbrzymia szanse interoperacyjnosci i neutralnosci technologicznej. Warunkiem jest oczywiscie brak wojny patentowej, ale to inny temat.
No to gnomy se znowu poszaleją.
Strzelą so jakiś notatniczek w C# i będzie wesoło.
Uprzejmie proszę o nie trolowanie
wini nie troluje, praktykuje trudna sztuke blaznowania.
jak widać po jakości próby sztuka ta jest naprawdę trudna
Gnome podobno nie naśladuje Windows. To chyba stąd mamy nie tylko zamiłowanie do C# w aplikacjach ale i koszmarek w stylu gconf(-editor) do złudzenia przypominający najbardziej odrażającą część Windows, Rejestr.
(aby nie było wątpliwości: to pisałem ja, zadowolony mimo wszystko użytkownik Gnome)
Co jest nie tak z gconf?
dopoki nie sprobuja zamienic /etc w cos takieg
jak rejestr — to chyba nic?
nat: czyli to wspaniale, że pliki konfiguracyjne nie mają żadnego standardu?
Bo gconf to tylko framework do przechowywania konfiguracji programów, których pliki konfiguracyjne to drzewo z plikami xml.
Co w takim razie jest dla ciebie ideałem w tym momencie? Żeby do każdego programu pisać inny parser?
Przecież gconf jest idealnym przykładem filozofii GNOME "Nie rusz, bo zepsujesz". Nie po to developerzy natworzyli dziesiątki opcji, żeby jakiś n00b je sobie ręcznie zmieniał w plikach. Prawdziwy geek poradzi sobie bez żadnych komentarzy w plikach, a XML sparsuje w locie podczas edycji, w dodatku podświetlając składnię oczami
sprae: ja wole pliki tekstowe od xmla
@nat:
…Koniecznie każdy plik w innym formacie najlepiej taki do którego trudno napisać parser…. Na pewno wiesz co mówisz ?
Tradycja plikowej konfiguracji jest przekleństwem linuksa!
To jest jeden ważniejszych czynników 'hamulcowych' dla linuksa na biurku
j23tom:
"…Koniecznie każdy plik w innym formacie najlepiej taki do którego trudno napisać parser…. Na pewno wiesz co mówisz ?"
ja nic takiego nie mowilem. lubie pliki tekstowe i ten krzyzyk
– znaczy sie hasz. i bez konotacji prosze
"To jest jeden ważniejszych czynników ‘hamulcowych’ dla linuksa na biurku"
hm. jak dla kogo — jesli wcisniesz poczatkujacemu Slackware czy
Debiana, to moze i tak, z Mandriva byloby inaczej.
Sparrow1:
$ make menuconfig
$ make: .config: do not edit this file
Pitolicie, Hipolicie;) Po pierwsze, sposób zapisu konfiguracji w gconf jest w pełni konfigurowalny, póki co trzyma dane w plikach XML, ale nie ma nic na przeszkodzie żeby napisać sobie backend zapisujący ustawienia w dotfiles, bazie danych czy serwerze LDAP. Co więcej, żadna zmiana w aplikacjach korzystających z gconf nie jest konieczna.
Po drugie, gconf nie jest po to żeby ukryć przed użytkownikiem, są narzędzia gconftool2 (konsolowe) oraz gconf-editor, złużące do modyfikowania ustawień. Wbrew temu co piszesz, klucze są udokumentowane (uruchomiłeś choć raz gconf-editor? przecież tego nie da się przeoczyć). Nie trzeba się zastanawiać, w jakim formacie są pliki konfiguracyjne, czy to zwykłe INI, czy też plik jest zapisany w termach Erlangu. Już nie wspominając o edycji plików konfiguracyjnych z poziomu np. skryptu.
Ostatnie, zmiany w gconf są propagowane od razu do aplikacji. Czy któryś program korzystający ze zwykłych plików konfiguracyjnych ma tak, że zapisujemy plik konfiguracyjny i hop, zmiany się pojawiają od razu w programie, bez konieczności powótrnego włączenia programu?
Dodatkow w gconf klucze nie tylko są dokumentowane ale także czytelne dla ludzi. Nie ma czegoś w rodzaju /user/aplikacja/{39B228DC-EBB1-11DE-A583-A15756D89593}/{584BD572-EBB1-11DE-9EC1-765856D89593}.
wini: ale z oryginalnym, czarno-bialym kolorowaniem skladni..