Mono krijgt C# 3.0 ondersteuning

Mono, een opensource-implementatie van Microsofts .NET-technologie, zal ondersteuning krijgen voor versie 3.0 van de C#-taalspecificatie. Dit heeft projectleider Miguel de Icaza via zijn weblog laten weten. Een tijdspad heeft hij echter niet bekendgemaakt.

Verschillende Mono-gebruikers hadden De Icaza via irc en e-mail gevraagd of Mono de derde versie van C# zou gaan ondersteunen. Het antwoord daarop is een ondubbelzinnig ja: 'yes, we will be implementing C# 3.0'. Deze versie van C# bouwt voort op eerdere releases en features van de taal, zoals iterators, anonymous methods, variable lifting en generics. Het is dan ook noodzakelijk dat de bestaande compiler stabiel en volledig genoeg is voordat er verder gebouwd wordt aan de C#-compiler in Mono, aldus De Icaza. Nu het overgrote deel van de fouten uit de C# 2.0-compiler is gehaald, zijn de developers begonnen met het werken aan de C# 3.0-features. Bepaalde ontwerpfouten in de C# 2.0-implementatie kwamen overigens pas boven toen men functionaliteit uit de derde versie van de C#-specificatie aan Mono wilde toevoegen. Een klein deel van de Linq-syntax is reeds geïmplementeerd en enkele ontwikkelaars zijn met de Query-functionaliteit aan de slag gegaan. De ontwikkeling van de C# 3.0-features in Mono is te volgen via de Olive-projectpagina. Onduidelijk is nog wanneer versie 3.0 van C# volledig ondersteund zal worden door Mono.

Reacties (28)

[AtleX]

Mono is gaaf, want het bied de mogelijkheid om crossplatform applicaties te ontwikkelen in een goede en mooie IDE (VS2005). Mijn grootste probleem ermee is alleen dat het een drama is om een VS2005 project ermee te compilen. Dat is me nog geen 1 keer gelukt terwijl ik een aantal van mijn programma's ook wil uitbrengen voor Linux. Het kan aan mijn kneuzigheid liggen natuurlijk, maar duidelijke how-to's zijn er ook niet echt te vinden

[berend_engelbrecht]

Dit is iets waar je vrij snel tegen aanloopt met cross platform tools. Je kan er iha van uit gaan dat een softwareproduct dat je op zo'n toolkit gebouwd hebt alleen portable is als je het daadwerkelijk geport hebt. Je maakt al snel onbewust gebruik van platformspecifieke functies(zoek naar het woord DllImport, als dat ergens voorkomt is het al foute boel) of aannames (gebruik je ergens '\\' waar je eigenlijk System.IO.Path.DirectorySeparatorChar zou moeten gebruiken?).

Wij zijn er wel in geslaagd om een bestaand dotnet 1.1 product van enkele jaren oud naar Linux te porten. De linuxversie werkt functioneel, maar ik kan echter nog niet zeggen dat het al marktrijp is omdat er nog dingen aan de look & feel ontbreken, b.v. het system tray icon. Wij ontwikkelen in VS.Net 2003 tenzij een project echt 2005 vereist (b.v. Ajax, SOAP standards compliance), dit om zo breed mogelijk compatible te zijn met client PC's. De uiteindelijke software builds doen we in NaNT, gebruikmakend van de diverse command line compilers op Windows. Zowel op de buildmachine als op Linux gebruiken we mono 1.2.2.1, de .1 patch voegde een voor ons belangrijke bugfix in Process.Start toe.

Een tip om een bestaand project te porten van VS.Net naar mono is om de delen waar de mono compiler op strandt in eerste instantie uit te sluiten met #if ! __MonoCS__ en te beginnen met dat wat je overhoudt. Bij ons viel het wel mee, de bulk van de applicatie was redelijk portable.

[Loesje]

Als je echte cross-platform tools gebruiks, zoals bijvoorbeeld Lazarus dat native code maakt voor diverse platformen, heb je dat probleem niet.
Echte cross-platform talen kennen natuurlijk geen platformspecifieke functies, zoals DLLImport.

Probleem met C# is natuurlijk dat MS het nooit heeft ontwikkeld en bedoeld als platformonafhankelijk. Met Mono kan je platformonafhankelijk programeren, maar daarmee zijn niet alle C#-programma's platform-onafhankelijk. (Waar PHP (script) en Lazarus (compiler) dat wel zijn.

voor het geval dat: Ja, ook in Lazarus en PHP kan je platformafhankelijke code schrijven, maar dan weet je echt wel dat je dat aan het doen bent

[berend_engelbrecht]

Probleem met C# is natuurlijk dat MS het nooit heeft ontwikkeld en bedoeld als platformonafhankelijk.

Dat is niet helemaal waar. Bij de allereerste Microsoft conferentie waar ik kennismaakte met dotnet en C# (DevDays 2001, als ik het me goed herinner) hadden ze nog hun mond vol van operating system platform-onafhankelijkheid, in elk geval voor de CLR. Dingen zoals System.IO.Path.DirectorySeparatorChar wijzen er ook op dat dit bewust in het ontwerp is meegenomen. DotNet met de CLR was immers bedoeld om te concurreren met Sun's Java en de OS independent Java VM. Overigens maakt java ook geen native code en het is weldegelijk cross platform. Executie op een VM en compiled libraries voor elk platform zijn gewoon 2 mogelijke oplossingen voor multiplatform-software, allebei met hun pro's en con's (* berend_engelbrecht heeft jarenlang de multi-platform windowing toolkit XVT in de benelux ondersteund, die van native binaries gebruik maakt. De problemen met onbewuste platform-specifieke aannames waren hetzelfde: portabiliteit viel gewoonlijk erg tegen).
In sommige Microsoft documentatie zie je dit OS independence idee nog terug, bijvoorbeeld hier:

Understanding Managed Code
[...]MSIL is the intermediate language used by the .NET platform. It is a CPU-independent instruction set that looks similar to assembly language but has some important differences. [...] The MSIL is the key to the .NET Framework's platform-independence. All that is required for an assembly to run on a non-Windows platform is for the CLR to be ported to that platform.

Ze hebben dit echter nog voor de .Net 1.0 release deels losgelaten, met name in de Windows Forms library (niet verwonderlijk dat dit 1 van de onderdelen was die het moeilijkst naar Linux te porten was in het mono project). Windows Forms zijn handig, maar op onderdelen is het zelfs een stap terug t.o.v. win32. Probeer er bijvoorbeeld maar eens achter te komen wat de pixel aspect ratio van je display is in dotnet 1.1

De "party line" is tegenwoordig dit:

Unlike J2EE, in which the Application Server is completely independent from the OS, the .NET Application Server is the Microsoft Windows® Operating System (and the services provided by Windows). The .NET Framework was designed to integrate closely with IIS and COM+ to provide reliable application hosting services and native support for Web services standards like XML, SOAP, UDDI and WSDL. This integration provides a significant performance boost to .NET applications, but requires platform monogamy. The level of integration is much tighter than with any J2EE server, and results in more features and faster performance.

Ofwel... we hebben het niet echt afgekregen/komt ons niet uit om OS independent te zijn (kies maar wat je waarschijnlijker vindt) en de marketingafdeling mag het goedpraten . Gelukkig is er nu mono, ik vind C# een hele gave taal en het zou zonde zijn als het aan Windows vastgebakken zou blijven.

[servies]

Microsofts begrip van cross-platform betekent: Windows 2000, XP, 2003 en Vista.
De rest van de wereld ziet het allemaal iets ruimer...

[Apache]

@Loesje, "dllimport" is onder java wel degelijk mogelijk dmv JNI (java native interface) kan je windows dll's of unix so's mee aanspreken in je code.

Met SWT heb je onder java trouwens native interfaces met native widgets waardoor je een zeer mooie cross platform app krijgt, wanneer je dat gebruikt ism Eclipse RCP levert hij nog gewoon een exe of andere binary af, je kiest gewoon een target zodat je snel nieuwe versies kan uitrollen op elk platform.

[PhysicsRules]

@berend_engelbrecht' party line

dat ben ik niet met je eens. .Net is veel meer geïntegreerd met Windows dan Java met welk besturingssysteem dan ook. Dat is echter geen argument tegen cross-platform ontwikkelen van .Net. Je hoeft er geen gebruik van te maken. MS nodigt je er echter wel toe uit.

[Brent]

Tot zover het crossplatform-argument voor .Net?

[Verwijderd]

Cross platform zijn is nooit een argument geweest voor .Net, in ieder geval niet voor Microsoft.

[Verwijderd]

En toch werd het neergezet als concurrent voor Java.

Dat is dus duidelijk niet het geval...

[dtech]

Het is , naar MS standaarden, ook behoorlijk crossplatform: Alle Windows NT afgeleiden en Pocket PC, dat is in vergelijking met veel andere MS producten behoorlijk crossplatform.

[mxcreep]

Ik zie echter weinig redenen om .NET code op linux te willen draaien. Er is genoeg C / C++ spul te krijgen en in de linux wereld zijn er ook zat developers die die talen goed beheersen. Support zal ongetwijfeld voor serieusere pakketten ook een probleem zijn. Denk niet dat Mono dezelfde support biedt als Microsoft zelf op .NET.

[berend_engelbrecht]

Mono wordt ondersteund door Novell en ik moet zeggen dat ze dat tot nu toe heel serieus aanpakken. Op het moment gaat het mono project gestaag vooruit.

[mxcreep]

Met ondersteund bedoel ik dat je support contracten kunt kopen of dat die onderdeel van je licensie zijn. Voor zover ik weet is de ondersteuning van Novell meer ondersteuning aan de development crew.

[GrimaceODespair]

Als ik De Icaza was, dan zou ik het geen optie vinden om C# 3.0 _niet_ te implementeren. Hier zitten zoveel bruikbare features in die werkelijk iets toevoegen, dat niet implementeren gelijk staat aan hopeloos achterlopen. Mono _moet_ mee, of ze verdwijnen weer naar het achterplat.

[Verwijderd]

Helemaal mee eens. Het is alleen met die features dan de run-time ook serieus gebruikt zou kunnen worden door NIET IMPERATIEVE TALEN.

Ik wordt altijd zo moe van het feit dat men net doet alsof je allerlei keus hebt qua programmeertalen support terwijl zowel Java als .NET hartstikke biased zijn richting imperatieve talen.

Iemand die denkt dat C# of VB verschillen op een ander niveau dan syntax heeft waarschijnlijk nooit in een ander paradigma geprogrammeerd.

Natuurlijk heb je wel prolog en ml implementaties voor .net en java, maar die integreren slecht.

Voorbeeld: In een functionele taal kan is een functie een first-class citizen. Net zo iets als een integer. Je kan ze meegeven als argumenten, defineren als constantes, etc.

Maar pas sinds kort zou je ook een .NET library kunnen schrijven waar dit ook mogelijk mee zou zijn. Zonder naar rare run-time trucks te grijpen. (lees: code gaan zitten intepreteren ipv compileren)

Om over de parametrische datatypes die door hun marketing department ten on rechte als 'generic programming' werden geclassifeerd maar te zwijgen. Generic programming is veel meer dan dat: polymorphische functies, reflectieve abstracte datatypes, etc.

Dat krijg je natuurlijk als een run-time om de lowest-common-denominator baseert. (C# en Java). Ze hadden het beter op Haskell kunnen baseren. Binnen hun type-systeem zijn zowel logica-talen, dataflow-talen en imperatieve te typen.

[lzandman]

Inderdaad. Ik vind dit ook niet echt nieuws. Ik had niet anders verwacht. Ik ga er van uit dat ze gewoon Microsoft blijven volgen...

[RetepV]

Ik wil wel eens benchmark vergelijkingen zien tussen Windows Vista met .NET en Linux met mono.

[Verwijderd]

Ik kan geen enkele reden ter wereld bedenken waarom je C# (of eender welke .Net technologie) zou gebruiken ipv Java.
Zeker nu dat Java6 uit is, en alles GPL wordt.
Java is tenminste ECHT platform onafhankelijk!

[OMX2000]

Java platform onafhankelijk... tja... Waarom hoor ik zo vaak dat IBM spul niet op SUN spul draait, of Oracle spul...

Platform onafhankelijkheid is zoieso redelijk overrated. Alsof grotere bedrijven zo maar eventjes van platform veranderen. Vaak als men een overstap maakt is dat ook gekoppeld aan het moderniseren van systemen.

[humbug]

Het probleem is hetzelfde als bij c#. Niet alle functionaliteit is beschikbaar in de "standaard" bibliotheken. Om dan die functionaliteit toch te bieden bouwen IBM, SUN, BEA enz extra APIs voor hun applicatieservers. Als je die zaken gebruikt dan werkt het natuurlijk niet zomaar op een ander platform.

C# heeft op het windows platform meer mogelijkheden dan op het linux platform. Simpelweg omdat de compiler bouwers voor het Linux platform een flinke achterstand hebben en omdat er veel APIs gewoon niet beschikbaar zijn op Linux.

Ook is platform onafhankelijkheid juist van belang omdat grote (en kleine) organisaties niet zomaar overstappen op een ander platform. Als dat wel het geval zou zijn zou er een ratjetoe aan servers in de datacentra staan. Mail op windows (exchange), web natuurlijk op sun (T2000), de database op een Power en natuurlijk voor elke applicatie de server die de ontwikkelaar van de applicatie prettig vindt. Juist doordat bedrijven zich vaak willen beperken tot 1 a 2 OSen is het van belang dat de software ook beschikbaar is op al die platformen die mogelijk bij bedrijven staan. Als je het platform van een bedrijf niet ondersteund, verkoop je namelijk niets aan dat bedrijf.

[Woy]

Dat ben ik niet helemaal met je eens. C# heeft voor linux net zoveel mogenlijkheden als voor windows. De taal ansich wordt namenlijk gehele ondersteund door mono.

Alleen nog niet alle library's zijn compleet geimplementeerd. Dus met het .NET Framework kun je inderdaad wel minder.

Echter zijn er ook dingen die je met Mono meer kunt. Zo hebben wij op ons werk gebruik gemaakt van de Mono.Security library omdat die een uitgebreidere ondersteuning heeft van de SSL standaard.

[humbug]

De taal wordt nog helemaal niet volledig ondersteund. Dat is juist de kern van het hele artikel

Mono, een opensource-implementatie van Microsofts .NET-technologie, zal ondersteuning krijgen voor versie 3.0 van de C#-taalspecificatie.

Dat wil niet zeggen dat de C#-compiler op linux onbruikbaar is, enkel dat er een (vrijwel onvermijdelijke) achterstand is ten opzichte van wat Microsoft uitbrengt.

Ook is het natuurlijk waar dat er verschillende mono libraries zijn die niet voor het windows platform bestaan, maar dat aantal verhoud zich natuurlijk nogal slecht met het aantal libraries die wel op Windows beschikbaar zijn en nog op andere platformen.

[Woy]

Mircrosoft heeft hun C# 3.0 compiler ook nog niet uitgebracht.

[G F0rce 1]

Ik denk dat het toch wel te maken heeft met prestatie gerichtheid. Maar inderdaad, java is een goede benadering van wat platformonafhankelijkheid zou moeten zijn. Echter, het framework bij de .NET programmeertalen is zo compleet dat het voor programmeurs heel verleidelijk wordt om richting die kant uit te wijken. Ik denk dat er wat Java betreft op dat punt nog wel het een en ander te verbeteren valt!

[berend_engelbrecht]

C# is gewoon een heel plezierige taal om in te werken en de IDE/compiler van Microsoft zijn ook behoorlijk goed. Microsoft bashing mag dan in de mode zijn maar het is nog altijd een firma die mag bogen op een ruime ervaring als compilerbouwer en dat zie je er aan af.

[mOrPhie]

Zelf in een project mono gebruikt en ik verbaas me steeds weer over de compatibiliteit. Die is echt beter dan sommige mensen doen vermoeden. Het was 4 jaar geleden inderdaad nog vrij lastig om echt compatibiliteit te vinden, nu is dat probleem echt aangepakt. De applicaties compilen zowel in Windows als Linux gewoon prima.