[.NET] Framework voor Linux

[AquilaDus]

Beste mensen, ik ben van plan om een software product dat uit een desktop applicatie en webscripten bestaat te gaan maken.
Nu werk ik zelf volledig onder Windows, maar nu kwam ik ook een IDE en Framework tegen voor Linux. Hierbij zit zelfs een apache module voor ASP.NEt scripten.

Dit product heet Mono en er is meer info te vinden onder : http://www.go-mono.com/

Nu is mijn vraag, zijn er hier mensen met ervaring wat Mono betreft en zijn deze positief of is Mono echt niet aan te raden om te gebruiken?

[GrimaceODespair]

Ik ben mezelf al enkele maanden aan het voornemen om Mono te installeren, maar het is er nog niet van gekomen. Ik denk echter wel dat je kunt stellen dat het een serieus product is.

Dat kan je bijvoorbeeld al zien aan het feit dat Microsoft in hun laatste .NET magazine er een uitgebreid artikel aan gewijd heeft. De conclusie was (uit het blote hoofd): Mono zal waarschijnlijk altijd wel 1 à 2 jaar achterstand hebben in de ontwikkeling. Tegen de tijd dat ontwikkelaars hun producten op de laatste MS.NET klaar hebben, kunnen ze het echter meestal wel al deployen op Mono.

Eentje om in het oog te houden, is in ieder geval de class status. Daar zie je bijvoorbeeld dat je op stabiele ASP.NET controls voorlopig niet hoeft te rekenen:

quote: http://www.go-mono.com/asp-net.html

A lot of work has been put in the various classes that implement the controls (UI.HtmlControls and UI.WebControls). They have been coded mostly in the dark, and without being able to test them in real life.

Hoewel ik denk dat het nog niet rijp is voor commerciële toepassingen, weet ik wel dat ik het voorlopig in de gaten blijf houden.

[_Thanatos_]

Het is idd erg jammer dat MS geen .NET framework voor linux (en de Mac?) maakt... ze roepen zelf dat het allemaal X-platform is. Maargoed, ik wilde er ff aan toevoegen dat als je je ASP.NET applicatie (nee, het is geen script, het is gecompileerd) op Mono wilt deployen dat je geen IDE voor Linux hoeft te gebruiken. Je kunt prima VS.NET of Webmatrix of een andere editor voor windows gebruiken. Immers net als bij Java maakt het geen kont uit waarop je het compileert, het draait toch overal.

Helaas zal X-platform denk ik wel betekenen dat je altijd wel ergens rekening mee moet houden. Een simpel voorbeeld is een X-platform applicatie die aanneemt dat een bepaalde file die bij em hoort, in /usr/dev/appnaam (of whatever) staat en dat werkt op Windows en Mac natuurlijk niet

[lvmeijer]

Mono is een goed initiatief en werkt al redelijk voor console applicaties. GUI's met Windows Forms vormen een groot probleem; het schijnt wel te kunnen met WINE.

Enkele demoprogramma's die ik had gemaakt (o.a. met sockets) werkte prima, maar programma's met serialization werkten weer niet.

I.p.v. Windows Forms kan je ook Gtk#, nadeel daarvan is dat het niet compatible is met Windows.

[LordLarry]

_Thanatos_ schreef op 17 januari 2004 @ 21:31:
Het is idd erg jammer dat MS geen .NET framework voor linux (en de Mac?) maakt...

...en dat doen ze ook. En zelfs opensource!

Microsoft Shared Source CLI or SSCLI, codenamed Rotor
This is an implementation of the CLI (along with other parts of the Microsoft .NET Framework) that can run on multiple platforms. The supported platforms are Windows XP, FreeBSD 4.7 and Mac OS X 10.2, but it should also work fine on Windows 2000 and earlier versions of FreeBSD. You can freely download the entire source for SSCLI (over 3,000,000 lines of code) for non-commercial purposes. Zie ook de Shared Source CLI Community Web site

En je hebt er nog meer, naast Mono. Bijvoorbeeld:

Portable.NET from the DotGNU project
While the initial target platform was GNU/Linux, it is also known to run under Windows, Solaris, NetBSD, FreeBSD, and MacOS X. The runtime engine has been tested on the x86, PowerPC, ARM, Sparc, PARISC, s309, Alpha, and IA-64 processors. At the time of writing Portable.NET 0.5.6 was the current version.

[GrimaceODespair]

offtopic:
f*ck zeg... zit ik net een prachtige en uitgebreide post te typen over SSCLI, crasht m'n IE. Gaat tot overmaat van ramp LordLarry er ook nog eens overheen

Anyway:

Programmeur bij MS

Als ze de code hebben, kunnen ze het toch gewoon op Linux compileren?

[AquilaDus]

Ik heb zelf ook al van mensen die veel contacten hebben binnen MS gehorod dat er Frameworks klaar liggen voor Unix/Linux, MacOS en Solaris. Maar ik vraag me dan zelf af wanneer deze in de wereld worden gezet.
Maar ik ben zelf al aan de slag gegaan om mensen binnen MS eens aan de tand te voelen over de stand van zaken. Ik ben dan ook heel benieuwd naar hun uitspraken hierover.

[GrimaceODespair]

AquilaDus schreef op 18 januari 2004 @ 12:45:
Ik heb zelf ook al van mensen die veel contacten hebben binnen MS gehoord dat er Frameworks klaar liggen voor Unix/Linux, MacOS en Solaris.

Als dat waar is, dan staat MS dus eigenlijk klaar om Mono een mes in de rug te steken. Commercieel gezien is het natuurlijk interessant om het framework gratis beschikbaar te hebben op zoveel mogelijk platformen en de IDE betalend te houden (voorlopig (?) op nog slechts 1 platform). Maar als MS zelf met een linux-variant van het Framework komt, zullen ze ten opzichte van Mono toch altijd het voordeel hebben dat ze in de eigen keuken kunnen kijken.

[LordLarry]

Er is weldegelijk markt voor meerdere frameworks die van .Net geruiken maken IMHO. De JIT compiler is het enige wat volgens de MS specificaties gemaakt hoeft te worden. Je bent niet verplicht system.weetikveel allemaal te poorten. Mono doet dit voor een groot deel wel om het zo mogelijk te maken Windows .Net programma's direct ook op Linux draaibaar te maken, maar dat hoeft dus niet. Ze maken bijvoorbeeld naast WinForms hun eigen GNome of KDE specifieke forms. Borland heeft ook een eigen .Net framework gemaakt gebaseerd op hun win32 VCL. En zo zijn er in dit topic al meerdere .Net frameworks genoemd. Het kan dus best zo zijn dat Microsoft's Framework Class Library (FCL) helemaal niet zo beroemd wordt onder Linux, maar dat het DotGNU wordt.

MS heeft geen voordeel onder Linux dat ze de makers zijn van .Net. Linux makers hebben juist een veel grotere kennis over Linux en weten het dus waarschijnlijk veel beter en sneller te maken dan MS kan. Borland's VCL for .Net is nu bijvoorbeeld sneller met het tekenen als MS FCL, aangezien deze GDI gebruikt ipv GDI+ en dat is nu nog gewoon sneller.

Waarschijnlijk kies je het beste framework for the job. Wil je meerdere platformen bestrijken? Dan kies je mono of dotgnu of SSCLI. Wil je veel Windows specifieke dingen doen? Dan kies je MS FCL. Port je een product van win32 VCL? Dan pak je VCL for .Net.

[ Voor 10% gewijzigd door LordLarry op 18-01-2004 14:47 ]

[_Thanatos_]

Je bent niet verplicht system.weetikveel allemaal te poorten.

Volgens mij valt daar ook niets aan te porten. Die namespaces zijn toch allemaal al .NET code? Alleen de onderliggende calls naar het OS moeten anders zijn, of denk ik dan weer te simplistisch?

[LordLarry]

Ik heb niet de implementatie van al die assemblies bekeken en een deel ervan zal idd pure .Net code zijn, maar een deel zal unmanaged code aanroepen. Dat geldt zeker voor System.Windows.

[AquilaDus]

Een eigen framework dat binnen de Linux community wordt gemaakt is natuurlijk best aardig. Ik maak me dan wel een beetje zorgen of ze zich exact aan de standaarden van microsoft houden.
Ik kan me voorstellen dat er toch kleine verschillen in de JIT's gaan opduiken en voordat je het weet kun je een applicatie of webpage dit je onder Windows ontwikeld hebt niet zomaar op een Linux machine draaien zonder het opnieuw te compileren of iets in de source te veranderen.

Dus ik hoop dat het echt platform onafhankelijk blijft, want anders schiet de wereld er nog weinig mee op.

[Freak_NL]

Als je cross-platform een applicatie bouwt moet je rekening houden met bepaalde zaken. Dat is met Java zo en dat is met .NET nog steeds zo.

Mono is een degelijk product. Voor een pre 1.0 release laten de mannen van Novell Ximian zien dat een open source .NET omgeving gewoon mogelijk is. Mono ontwikkeld zich met een rotgang, binnen een paar weken kunnen we MonoDevelop verwachten, een open source port van SharpDevelop met GTK#.

Mono is een "moving target". Als je software ontwikkeld die op Mono moet gaan draaien moet je er rekening mee houden dat veel delen van de API nog aan verandering onderhevig zijn.

Als je cross-platform wil ontwikkelen met .NET kun je er ook voor kiezen om ook onder Windows met Mono en widget toolkit GTK# te draaien.

[tijn]

Freak_NL schreef op 18 januari 2004 @ 18:55:
Mono is een "moving target". Als je software ontwikkeld die op Mono moet gaan draaien moet je er rekening mee houden dat veel delen van de API nog aan verandering onderhevig zijn.

Let wel dat de implementatie van de API aan veranderingen onderhevig is. De interface zelf ligt rotsvast. Momenteel zitten er nog wel wat verschillen tussen Mono en MS .NET, maar bij Mono hebben ze als doel om het gedrag van de MS API exact na te bootsen, ook waar het punten betreft die voor verbetering vatbaar zijn.

[Verwijderd]

LordLarry schreef op 18 januari 2004 @ 14:45:
Er is weldegelijk markt voor meerdere frameworks die van .Net geruiken maken IMHO. De JIT compiler is het enige wat volgens de MS specificaties gemaakt hoeft te worden. Je bent niet verplicht system.weetikveel allemaal te poorten.

Volgens mij zit er een groot deel van de API's wel in de standaard. Zo'n beetje alles behalve ASP.NET, ADO.NET en Winforms.

Borland heeft ook een eigen .Net framework gemaakt gebaseerd op hun win32 VCL.

Dat lijkt me sterk en zonde van de moeite, wat ik me wel voor kan stellen is dat ze hun eigen GUI API geport/gewrapped hebben in ee .NET API.

[Verwijderd]

AquilaDus schreef op 18 januari 2004 @ 17:20:
Een eigen framework dat binnen de Linux community wordt gemaakt is natuurlijk best aardig. Ik maak me dan wel een beetje zorgen of ze zich exact aan de standaarden van microsoft houden.

Het zijn nu dus gewoon ECMA standaarden en ze zouden wel gek wezen om zich niet aan die standaarden te houden. Een van de doelen is om het mogelijk te maken software die ontwikkeld is voor Windows in .NET te kunnen draaien onder andere platforms.

Ik kan me voorstellen dat er toch kleine verschillen in de JIT's gaan opduiken en voordat je het weet kun je een applicatie of webpage dit je onder Windows ontwikeld hebt niet zomaar op een Linux machine draaien zonder het opnieuw te compileren of iets in de source te veranderen.

Dat lijkt me weinig met JIT (Just In Time compilation) te maken hebben. Een verschil in API's ok, maar een verschil in JIT

[whoami]

AquilaDus schreef op 18 januari 2004 @ 17:20:
Ik kan me voorstellen dat er toch kleine verschillen in de JIT's gaan opduiken en voordat je het weet kun je een applicatie of webpage dit je onder Windows ontwikeld hebt niet zomaar op een Linux machine draaien zonder het opnieuw te compileren of iets in de source te veranderen.

De JIT is een onderdeel van de CLR (Common Language Runtime) en compileert IL (Intermediate Language) gewoon naar native code.

[LordLarry]

Verwijderd schreef op 19 januari 2004 @ 09:47:
Dat lijkt me sterk en zonde van de moeite, wat ik me wel voor kan stellen is dat ze hun eigen GUI API geport/gewrapped hebben in ee .NET API.

Ze hebben hetzelfde gedaan als MS, namelijk de bestaande win32 VCL compilbaar gemaakt onder .Net. Alhoewel het unmanaged code aanroept is het zelf weldegelijk managed. MicroSoft's FCL werkt op dezelfde manier.

Waarom zou het zonde zijn? Deze methode was waarschijnlijk sneller en completer dan alles herschrijven bovenop de FCL en geeft de mogelijkheid vrij simpel win32 VCL programma's te porten.

En waarom zou er maar 1 .Net framework mogen zijn? Zoals je al in deze post kan lezen zijn er al veel meer met ieder hun eigen voor en nadelen. Het VCL for .Net framework is bijvoorbeeld sneller als er veel met GDI getekend wordt dan de FCL.

VCL for .Net wordt in goede Borland traditie met volledige source bijgeleverd dus je kan gewoon met je eigen ogen aanschouwen dat dit zeker geen sterk verhaal is. Ik wou dat MS mans genoeg was om de source van grote delen van hun FCL mee te leveren. Dan hoeven we ook niet de boel te decompilen en zouden we, als we willen, assemblies direct in de EXE kunnen compileren.

[Verwijderd]

LordLarry schreef op 19 januari 2004 @ 10:21:
[...]
Ze hebben hetzelfde gedaan als MS, namelijk de bestaande win32 VCL compilbaar gemaakt onder .Net. Alhoewel het unmanaged code aanroept is het zelf weldegelijk managed. MicroSoft's FCL werkt op dezelfde manier.

Waarom zou het zonde zijn? Deze methode was waarschijnlijk sneller en completer dan alles herschrijven bovenop de FCL en geeft de mogelijkheid vrij simpel win32 VCL programma's te porten.

En waarom zou er maar 1 .Net framework mogen zijn? Zoals je al in deze post kan lezen zijn er al veel meer met ieder hun eigen voor en nadelen. Het VCL for .Net framework is bijvoorbeeld sneller als er veel met GDI getekend wordt dan de FCL.

VCL for .Net wordt in goede Borland traditie met volledige source bijgeleverd dus je kan gewoon met je eigen ogen aanschouwen dat dit zeker geen sterk verhaal is. Ik wou dat MS mans genoeg was om de source van grote delen van hun FCL mee te leveren. Dan hoeven we ook niet de boel te decompilen en zouden we, als we willen, assemblies direct in de EXE kunnen compileren.

Eerst even wat men (ik in ieder geval, edit: en MSDN ook: http://msdn.microsoft.com...nfo/overview/default.aspx) versta onder het .NET framework:
1. CLR
2. API
(3. Compilers)

Bij mijn weten heeft Borland alleen extra API's toegevoegd (en compilers wellicht) aan de al bestaande set API's. En dat is niet wat ik versta onder een nieuwe implementatie maken van het .NET framework. Mono is een implementatie van het .NET framework en dotGNU ook, daar zit alles in (of wordt iig een poging gedaan tot).

[ Voor 4% gewijzigd door Verwijderd op 19-01-2004 10:42 ]

[LordLarry]

Ik bedoelde in die post alleen de .Net class libraries, ook wel FCL genoemd. Borland heeft een eigen .Net compiler gemaakt en ondersteund naast de FCL ook hun eigen class library VCL for .Net. De termen zijn idd wat verwarrend. Had Microsoft het ook maar niet allemaal .Net moeten nemen