Voilà que les vacances d'été se sont écoulées, entre les google summer of code et autre, vous vous doutez que le projet mono n'est pas tombé.
Les versions s'espacent de plus en plus à cause de la stabilisation liée à la maturité de l'api de mono, alors que les versions s'enchainaient, ça fait depuis décembre qu'il n'y a pas eu de version majeure.
Pour la version 2.6 de mono, Novell vendait un support commercial, la version 2.8 n'aura pas ce statut de support long terme, la prochaine version majeure de mono (3.0) parcontre devrait en bénéficier.
Donc la nouvelle version est bien sur le point d'arriver, cette version apporte beaucoup de nouveautés, et je vais vous faire un résumé francophone des améliorations en perspective.

Très attachée à Gnome, l'équipe de mono a suivi ce projet dans le choix du gestionnaire de version. L'équipe de mono utilise désormais git pour gérer ses sources. Choix plus étonnant, ils ont laissé à github la tache de les héberger. Github est un site d'hébergement de source (voir sourceforge, google code...) qui est conçut pour git. Là où ce choix étonne les puristes, c'est que github est un prestataire de service qui n'ouvre pas les sources de sa machinerie avec pour business model, faire payer les gens qui utilisent github en voulant garder leurs sources privées.
Ainsi, on peut voir l'activité de l'équipe mono et le set d'outils mono à cette adresse:
http://github.com/mono
Et pour ceux que ça interesserait, l'activité de la personalité emblématique de mono que je ne présente plus par peur de passer pour un fanboy:
http://github.com/migueldeicaza
Git était conçus à la base par Linus Torvalds pour gérer les source du kernel linux. L'utilisation de cet outil change entièrement la manière de travailler par rapport à ce qu'il y avait avant, c'est à dire SVN. L'organisation d'équipe n'est pas du tout pareille, mais je vais éviter de trop m'attarder sur ce sujet.
Comment s'ogranise un workflow git?
Les bases de git sur le site du zero.
Évidement, je n'en parlerai pas si c'était purement anecotique, voici quelques conséquences: Le code est plus testé, il est plus facile pour un contributeur externe de faire des modifications et de le soumettre, il sera plus simple pour les gens qui veulent une version modifiée pour leur besoins de mono de la maintenir à jour, et du coup cela encourage les forks.
Du coup, mono aura à la fois un écosystème plus ouvert et plus de contrôle.
Bon après ce petit aparté sur git qui j'espère vous encourragera à vous renseigner et/ou à contribuer voici les principales amélioration mono 2.8.
Le nouveau ramasse miette (Garbage Collector) semble dépasser les espérances de tout le monde, on peut donc désormais dire que l'écart de performance entre mono et .NET s'est réduit au négligable (du moins sur les benchmarks que j'ai pu voir).
benchmark avec graphdb qui compare les performances entre mono, et mono avec le nouveau garbage collector activé.
benchmark comparable comparant mono avec le nouveau garbage collector avec .NET.
benchmark de sites servis en asp.NET sous mono avec chaque GC.
![]()
Pour tirer parti de cette nouveauté qui est embarqueé mais pas encore utilisée par défaut, il faudra ajouter l'option: --with-gc=sgen
Microsoft offre de plus en plus de ses nouvelles biliothèques en MSPL, et quand c'est le cas, plus besoin de double développement, mono pouvant les intégrer telles quelles:
Implémentées depuis des mois dans la version de dévelopement de mono, beaucoup de fonctionnalités de .NET4 sont là.
C#4 est intégralement implémenté.
ASP.NET 4.0 partiellement implémenté:

Plinq et Parallelfx font désormais parti de la distribution officielle.
Nombreux fixs qui permettent notamment de gagner en performance en multithread.
System.Collection.Concurrent a des objets qui passent lockless, plus rapides, moins gourmands en mémoire...
Le comportement de ThreadPool qui était resté similaire au fonctionnement de son implémentation dans .NET 1.1 a été mis à jour pour que les erreurs non gérées dans des threads ne soient plus silencieuses. Cette modification avait trainé car elle peut casser le comportement de pas mal d'applications mono. pour retrouver l'ancien comportement, il suffit de modifier le .config associé au binaire.

Une version patchée de LLVM permet de gérer 99% des méthodes de mscorlib:
http://github.com/mono/llvm
Néanmoins, une version standard de LLVM suffit pour pouvoir l'utiliser en complement du jit engine de mono.
Léger surcoût de mémoire et de temps de démarage mais net gain de performances.
Désormais l'exécution avec llvm est accessible via la simple option '--llvm' (alors qu'il fallait recompiler mono antérieurement).
Vous retrouverez mon descriptif de llvm dans cet article:
http://blogs.dotnet-france.com/christophen/post/2009/11/13/Mono-26-revet-son-plus-beau-costume-il-sort-ce-mois-ci.aspx
Ajout d'une bibliothèque destinée au calcul scientifique System.Numerics avec BigInteger et nombres complexes.
Linq2SQL arrive en standard.
Amélioration de la gestion du cache dans ASP.NET et implémentation d'une classe qui permet d'utiliser cet outil de cache dans d'autres contextes: System.Runtime.Caching.
Nombreuses améliorations de Xbuild (notamment le support des projets silverlight).
Pour faciliter les ajouts d'options (comme pour utiliser llvm ou sgen), une variable d'environnement propose de gérer ça à votre place exemple:
export MONO_ENV_OPTIONS="--gc=sgen --llvm"
Meilleur support des binaires offusqués.
La compilation complète est désormais disponible aussi pour x86 en plus de PowerPC et ARM.
Avec tout ça, Mono prend un peu d'embonpoint. Néanmoins, il y a un peu de ménage et quelques bibliothèques et commandes passent l'arme à gauche.
.NET 1.1 n'est plus supporté, les applications qui étaient compilées en .NET 1.1 seront éxécutés en 2.0 avec un warning.
Des bibliothèques d'accès à des bases de données non maintenues, non utilisées ou redondantes sont suprimées (ByteFX.Data, Mono.Data, FirebirdSql.Data.Firebird, Mono.Data.TdsClient, Mono.Data.SybaseClient, Mono.Data.SqliteClient)
Le moteur javascript de mono ayant peu de succès, n'étant pas assez complet face à 3 autres moteurs javascript, plus efficients, est aussi retiré. (Mirosoft.JScript, Microsoft.Vsa + la commande mjs)
Mais pour gagner en légèreté il y a d'autres solutions, suprimer des dépendences. Ainsi, mono a son implémentation minimaliste de glib (eglib) qui permet de porter plus facilement les applications sur des architectures de processeurs tierces et d'alléger la bibliothèque pour les systèmes n'ayants pas besoin de glib.
Cet article est très inspiré d'un document anglais plus complet que vous trouvrez à cette adresse:
http://www.mono-project.com/Release_Notes_Mono_2.8
Bref, ce document n'est évidemment pas exhaustif, et montre les raisons de l'enthousiasme autour du prochain mono 2.8. Si vous n'êtes pas patient mais que vous ne voulez pas compiler votre mono, vous trouverez de quoi patienter ici.
http://mono.ximian.com/monobuild/preview/download-preview/
Note: cet article a aussi été publié sur dotnet-france.