 epuis
l'annonce du projet Mono, on avait vu pareil engouement et
gesticulations autour d'un projet Open Source. Il y a maintenant un
an, DotNetGuru testait ce qui était alors, une préversion de Mono,
dépourvue il faut bien l'avouer, des fonctionnalités les plus
élémentaires qu'on attend d'un outil de ce type. A l'époque nous
n'avions pu tester l'accès aux données, les interfaces graphiques
ou les pages ASP.NET. Le compilateur venait tout juste de voir le
jour et la machine virtuelle péchait dans la finition. Pour preuve,
même un hello world basique provoquait systématiquement un "core
dumped" .
Nous pouvons d'ores et déjà vous dire que cette
époque est révolu. Les progrès de cette version nous ont
totalement bluffé. Et si Mono 0.1 a évolué en quelques mois vers
Mono 0.3, c'est bien des années lumière qui séparent aujourd'hui
ces deux implémentations. Nous nous attentions à des progrès
majeurs du fait de l'augmentation croissant du nombre de
participants au projet, mais il faut avouer que là le résultat
dépasse largement nos espérances. Mono 0.3 permet aujourd'hui de
déployer sous Linux un site développé sous WebMatrix, Vous n'y
croyez pas ? Lisez la suite...
Installation
et configuration
L'installation de Mono est aujourd'hui à la portée
n'importe quel geek (petit clin d'oeil sur copinedegeek.com).
Nul besoin d'être un hacker fou ou un quelconque bidouilleur
ténébreux pour arriver à installer l'outil. Un rapide
téléchargement du package sur le site : http://www.go-mono.com/download.html
et le tour est joué. Les versions 0.20 et 0.21 sont les dernières
en date et ont constitué la base de nos tests. Si
votre plateforme est Linux, la démarche sera très simple du fait
de la présence de nombreux fichiers RPM sur le site de Mono. Si en
revanche vous êtes sous Windows, nous vous conseillons fortement
d'installer l'outil cygwin permettant d'émuler l'ensemble des
outils du Libre (gcc, make, ...) et de compiler efficacement le
moteur XSP que vous verrons plus loin. Une
fois le package installé, vous disposez après décompression du
package d'un répertoire du type d:\mono-0.20.
Il vous faudra ensuite veiller à positionner différentes variables
d'environnement. Notamment le PATH qui doit pointer sur
<mono>/bin et la variable LD_LIBRARY_PATH qui elle, doit
pointer sur <mono>/lib. Pour vérifier que
l'installation et la configuration sont corrects, placez vous
n'importe où dans l'arborescence de votre disque et tapez
">mcs" ou ">mono", vous devriez voir
apparaître les messages d'aide des différents outils. Voici
ce que le répertoire /bin contient après
l'installation. 
L'an
dernier, seuls trois ou quatre outils avaient été implémentés.
Aujourd'hui, plus de 30 outils différents constituent ce
répertoire /bin. Inutile de vous dire que nous sommes déjà
agréablement surpris .... Les
nouveautés
Les nouveautés de cette version sont nombreuses. Premièrement, des
langages tels que VB.NET font leur apparition avec le compilateur
mbas (cf ci-dessous)
Ensuite, l'état de la migration des classes est
sans aucune mesure avec Mono 0.1. Le Namespace System a été
porté à 50%, avec System.Xml est à 70%, System.IO
à 100%, System.Net à 90%, les Threads à 100%, les Web
Services à 90% ... Quant aux API plus compliquées à migrer du
fait de leur dépendances fortes avec Windows, elles ont également
bénéficié des évolutions avec un Namespace System.Data porté à
90% (!). Sans même avoir testé une seule fonctionnalité, nous
sommes déjà impressionné par l'ampleur des progrès réalisés
dans la migration.
Concernant les autres améliorations, nous
pouvons citer pèle Melle le développement d'un débuggeur, la
création d'un Framework graphique basé sur GTK#, l'intégration
d'une dizaine de bases de données différentes à travers le
Namespace System.Data, la prise en compte de MacOSX, etc.
Voyons dans le détail chaque partie.
Windows
Form
Gtk#
Les WinForms ont constitué le point le plus
délicat du projet Mono du fait de l'intégration forte entre GDI+
et Windows. Le projet a donc dû prendre une décision pour trouver
un remplaçant aux WinForms de Microsoft. L'équipe de Ximian ayant
déjà travaillé avec GTK, un rapide portage a été réalisé pour
migrer les API GTK en C# avec pour nom GTK#.
A l'heure actuelle, l'état d'avancement du
projet ne permet pas réellement de disposer d'éléments tangibles
concernant l'ergonomie finale et les composants graphiques
implémentés. Malgré tout, les copies d'écran suivantes
sont prometteuses pour l'avenir.
Nul doute que la partie Windows Forms est la
moins aboutie aujourd'hui.
ADO.NET
De nouveaux fournisseurs ou providers
ADO.NET fait partie des évolutions les plus importantes. Pas moins
de 10 nouveaux drivers
ou providers ont fait leur apparition. De MySQL à Postgres en
passant par Sql Server, DB2 et Oracle. Le plus gros du travail
s'étant concentré sur le moteur TDS d'accès à SQL
Server.
La Provider Factory : ADO.NET enfin
générique !
S'il y a bien un reproche qui est revient souvent à l'encontre
du Framework ADO.NET, c'est bien l'approche propriétaire de ses
API. Aujourd'hui, chaque provider dispose d'une implémentation
spécifique qui entraîne une dépendance forte entre le code
ADO.NET et la base de données sous-jacente. Sous avons déjà eu
sur DotNetGuru l'occasion d'évoquer ce sujet en proposant une
approche basée sur le Design Pattern Factory. Et bien c'est la
démarche adoptée par Mono. Dorénavant, nul besoin d'importer les
Namespace Data.SqlClient ou Data.Oracle, les API IdbConnection et
IdbCommand se chargent de masquer les implémentations au client sur
le modèle de JDBC en Java. Pour spécifier le provider utilisé,
une simple entrée dans un fichier de configuration suffit.
ASP.NET
XSP
Il faut bien avouer que jamais nous n'aurions imaginé qu'un
jour Mono réussirait à porter les API WebForms d'ASP.NET. Pour
ceux qui connaissent un peu ce modèle de composant, il faut
reconnaître que migrer de telles API relève du défi. Ce fût
notre premier test, nous étions impatient de voir un résultat
aussi minime soit-il concernant les WebForms de Mono.
Tout d'abord, il nous a été nécessaire de
télécharger un package supplémentaire : http://www.go-mono.com/archive/xsp-0.3.tar.gz.
XSP est le nom de code de l'implémentation ASP.NET de Mono. Une
fois le package décompressé, il vous suffit de compiler les
sources à l'aide du makefile fourni par défaut :
Après avoir avec succès compilé le serveur XSP,
la première tentative pour afficher une page s'est avérée
infructueuse. En réalité, il convient de prendre plusieurs
précautions avant de lancer le serveur. Tout d'abord, la présence
du fichier machine.config est obligatoire. Malheureusement sa
référence étant codé en dur dans un répertoire inexistant, il
nous a fallu faire pointer la variable MONO_CFG_DIR vers un fichier
préalablement créé ou copié à partir du Framework de Microsoft.
Ensuite, le serveur a donné des signes de faiblesse lors de son
lancement. Après quelques recherches sur les listes de diffusion,
il s'est avéré que l'option GC_DONT_GC=1 était indispensable.
Après plusieurs essais, nous sommes enfin parvenu à faire
fonctionner le serveur XSP, voici le résultat :
Le serveur s'exécute par défaut sur le port
8080 et attend des requêtes clientes. A noter qu'une version en
module Apache est également disponible à l'adresse suivante. Les
développeurs du projet Mono ont pris soin de nous fournir plusieurs
pages ASPX d'exemples dans le but de démontrer aux utilisateurs
l'état d'avancement du projet. Voici le résultat de l'appel à http://localhost:8080/index.aspx
Bluffés ? on le serait à moins. Mais la suite
à été encore plus emballant, tous les contrôles standards du
Framework ASP.NET ont été migrés. Cela comprend les contrôles
html mais également les contrôles web et les contrôles
personnalisés. Surpris, nous n'en croyons pas nos yeux ébahis.
Comment est-il possible de migrer un Framework aussi complexe
contenant des composants tels que des DataGrid,
des DataRepeater ou Validateurs
en aussi peu de temps ? 10 mois se sont écoulés et des pas de
géant ont été accomplis par les développeurs de génie du projet
Mono.
Convaincus, nous décidons d'aller plus loin.
Pourquoi ne pas mettre en place un atelier de développement basé
sur WebMatrix comme IDE et Mono comme environnement de déploiement
? Le premier générant des pages ASPX dans le répertoire racine du
second. Aussitôt dit aussitôt fait, après quelques tests, le
succès de cette implémentation est incontestable. Toutes les pages
conçues en mode WYSIWYG sous WebMatrix ont été affichées avec
succès par le moteur XSP de Mono. Plus encore, la session HTTP est
gérée, les différents modes d'authentification, les cookies !
in-croy-able ...
Seuls quelques bugs subsistent encore, le code
behind à la Visual Studio n'est pas pris en compte, les custom
contrôles pêchent dans leur finition et impossible de mettre à
jour un composant lorsque le serveur est lancé, des violations de
partages apparaissant de temps à autres.
Concernant l'accès aux données dans les pages
ASPX, rien de plus simple. nous vous juste ajouté une ligne dans le
fichier web.config pour spécifier le type de provider utilisé, en
l'occurrence MySQL et notre fameux DataGrid était aussitôt rempli
de données.
Bref, Mono a changé, Mono a grandi et le bout du
tunnel semble de plus en plus proche ...
Un
serveur d'application à la J2EE
Nous pensions avoir atteint des sommets en terme de richesse dans
cette implémentation supposée "immature" et pourtant....
Brian Ritchie a entamé les développements d'un serveur
d'application absolument bluffant en terme de fonctionnalité et
d'ergonomie. L'outil permet de monter et de déployer à chaud des
applications Remoting ou Web Services par l'intermédiaire d'une
console d'administration en HTML. Mieux encore, dans le cas
d'application non interactives le déploiement peut s'effectuer
directement en FTP. A faire pallir les plus grands aficionados de
composants EJB. jugez-en par vous même :
Conclusion
Que dire de plus sinon que les tests de Mono 0.20 ont été pour
nous une vraie partie de plaisir. Si les progrès continuent dans ce
sens, dans quelques mois vous serez surpris de découvrir le
premières applications Linux basées sur Mono. Et qui sait, un jour
viendra peut-être où certains développerons sous Visual Studio
(ou Borland d'ailleurs) pour déployer sur des serveurs
Linux....
|
