Roslyn ou comment voir le compilateur comme un service
Microsoft a sorti il y a quelques jours la CTP de Roslyn, le nom de code qui cache une version « As a Service » du compilateur de Visual Studio.
Nous utilisons tous des compilateurs qui permettre de créer des binaires à partir de notre code permettant à ces derniers d’être exécutable sur une machine hôte, mais combien parmi vous savent le processus exact d’une compilation ?
Tout ce mécanisme est caché aux yeux du développeur par les IDE modernes tels que Visual Studio mais si on retourne un peu aux bases, par exemple un petit morceau de C et un joli Makefile on peut redécouvrir les choix de la compilation ou je devrais dire…de l’analyse syntaxique du code, de la création des symboles, de la phase de linkage et pourquoi pas même l’écriture sur le disque dur.
Et Roslyn dans tout cela ? Et bien juste une batterie d’API permettant de « jouer » avec l’ensemble de ces phases, mais de façon dynamique au sein de notre code. Il était déjà possible de faire de la compilation à la volée en .Net mais avec cette première version de Roslyn on passe à la vitesse au-dessus !
Ce que l’on voit en bas est le pipeline de compilation classique de Visual Studio, ce qu’offre Roslyn se trouve sur la première ligne, un ensemble d’API permettant de refaire pareil, mais étape par étape tout en gardant l’ensemble du contrôle sur le déroulement des opérations, mais surtout en permettant d’intervenir à chaque étape.
Envie de découvrir un peu plus les possibilités de cette CTP ? Première étape installez celle-ci après l’avoir téléchargé sur : http://www.microsoft.com/download/en/details.aspx?id=27746
Il y a deux grandes parties dans la CTP, l’API et le mode interactif pour C#/VB.net, pour ceux ayant déjà fait du F# vous comprendrez vite l’intérêt de cet élément-là. Pour les autres nous y reviendrons dans un futur article.
Une fois la CTP installée, vous pouvez utiliser les nouveaux templates de projet au sein de Visual Studio pour faire vos premiers pas avec Roslyn.
Essayons déjà de voir comment exécuter un petit morceau de code :
Et en sortie on obtient ? Tout simplement du code compilé à la volée et exécuté directement :
Rien de bien sorcier, mais je vous laisse imaginer les multiples possibilités du système maintenant…je laisserais de côté les possibles failles de sécurité pour garder la place au rêve de programmes intelligents qui se construisent tout seul au fil de leur vie.
Et bien justement ? Ne pourrions pas imaginer un programme qui s’ajoute une fonctionnalité lui-même ? Une sorte de système de plugin mais « intelligent » qui pourrait s’adapter à la machine hôte par exemple. Nous utilisons maintenant tous ou presque MEF dans nos programmes pour les rendre plus extensibles, mais cela reste quelque chose que nous devons fournir, des plugins qui sont fournis avec le programme ou bien par la suite, mais au final ? Ce n’est qu’un assemblage de binaire prédéfini à l’avance.
Essayons de poser les bases d’un programme capable de se construire par lui-même en utilisant Roslyn et de petit morceau de MEF tout de même (cela serait possible sans, mais moins sexy, non ?)
Posons les bases d’une solution composée de deux projets :
· Un Common qui contient une interface IPlugin
· Un Starter qui contient le main et un petit moteur que l’on va détailler ensuite
Notre interface sera pour le moment simple :
Passons maintenant à notre Starter, son rôle sera double :
· Créer une armée de petit module
· Les charger par le biais de MEF pour s’en servir…et conquérir la planète
Regardons donc de plus près comment nous pouvons créer un module de façon dynamique, car Roslyn nous a permis d’exécuter quelques lignes de code, mais c’est loin d’être suffisant pour écrire un Assembly complet et encore moins avec de quoi être importé par MEF.
Tout d’abord, préparons le code de notre module, on va rester sur quelque chose d’assez simple pour le moment, je vous laisse y ajouter une pointe de Skynet par la suite.
Pas besoin d’expliquer le code, rien de bien sorcier dedans. On notera seulement que notre classe exporte bien l’interface IPlugin, tout est en règle.
Et maintenant un petit tour de magie avec Roslyn pour compiler ce code et produire un binaire tout à fait propre et comme si nous étions passés par nouveau projet > library> code…code…F5 :
Les commentaires parlent d’eux-mêmes, au final faire une compilation « à la main » se révèle assez simple. Il ne reste plus qu’à écrire notre code compilé sur le disque dur, voyons comment faire cela en quelques lignes également :
On retrouve bien le terme Emit que certains ont sans doute déjà croisé dès que l’on descend un peu dans les couches « basses » du Framework .Net. On reste bien sur les mêmes principes, le code une fois compilé doit être écrit sous forme MSIL puis injecter dans un fichier, dans notre cas on va le nommer test.dll pour rester simple.
Et puis ? Et bien c’est tout. Notre programme à bien compilé du code lui-même, écrit cela dans un nouvel Assembly un petit morceau de code et potentiellement maintenant capable de le charger de manière dynamique et s’en servir, et tout cela au runtime sans repasser par Visual Studio.
Survolons le code nécessaire pour charger le nouveau module avec MEF :
Le binaire est donc capable dans le même lancement de se construire un ou plusieurs plugins puis de les charger directement et en tirer parti. L’exemple a beau être le plus simpliste possible, j’espère que vous avez pu en saisir le principe et surtout le champ des possibilités que cela ouvre pour la suite. Bien sûr les programmes qui se construisent eux-mêmes ne sont pas nouveaux en soi, qui n’a jamais « rencontré un malin virus capable de le faire ? Mais cela restait dans des domaines spécifiques pour de nombreuses raisons, dont la difficulté de mise en place. Maintenant Roslyn nous permet de passer cette étape en quelques lignes à peine
.