Discussion :

[Hinault Romaric]

ScriptCS fait de C# un langage de Script
le projet open source repose sur le compilateur en tant que service Roslyn et NuGet

Glenn Block, directeur de projet de l’équipe Windows Azure SDK, a présenté récemment ScriptCS, un projet qui tente de faire de C#, un langage de script.

ScriptCS permet aux développeurs d’écrire des applications C# en utilisant un simple éditeur, puis de compiler et d'exécuter celles-ci.

Avec ce projet, plus besoin de référencer des espaces de noms, de définir des classes, etc. Le développeur n’a besoin d'aucun fichier de projet (.obj) ou encore d’exécutable. ScriptCS offre quasiment les mêmes avantages que Node.js.

En effet, ScriptCS repose sur Roslyn (compilateur en tant que service développé par Microsoft) et le gestionnaire de packages .NET NuGet. ScriptCS utilise NuGet pour retrouver et télécharger les dépendances qui sont nécessaires pour exécuter un script, ensuite passe la main à Roselyn qui se charge de la compilation.

Pour un simple fichier hello.csx contenant la ligne de code suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Console.WriteLine("Hello World!");

Son exécution avec ScriptCS en utilisant la commande « scriptcs hello.csx » produit le résultat « Hello World! ». Pas besoin donc de références et autres choses nécessaires pour exécuter un code C#.

Des travaux sont en cours pour introduire le support de ScriptCS à Mono. L’EDI Sublime Text a déjà créé un plug-in pour ScriptCS, permettant la coloration syntaxique dans un éditeur simple.

ScriptCS est disponible sous les termes de la licence open source Apache 2. Le projet, pour l’instant, ne bénéficie pas du support de Microsoft.

Son code sur NuGet

Source : Le site du projet


Et vous ?

Que pensez-vous de ce projet ? Le trouvez-vous intéressant ?

[alex_vino]

L'initiative a l'air intéresante, meme si a premiere vue ses cas d'utilisation restent assez rare et plutot spécifique. Peut-etre sur Windows Azure il aura un réel intéret et avantage.

un projet qui tente de faire de C#, un langage de script.

Plutot il essaie de l'associer comme langage de script en plus de son utilisation actuelle, je ne pense pas que Microsoft veuille se débarasser du C# et de lui laisser comme unique role le scripting.

[nquenault]

C'est marrant, j'ai un projet un peu similaire du nom de DNSI (.Net Script Interpretor).

Il permet d’exécuter en mémoire ou de compiler en .exe du code source .Net (C# et/ou VB.Net en même temps) qui peut se trouver à plusieurs endroits différents (une partie du code en local sur le disque, une autre partie sur le réseau local ou même sur le web, fichier texte, script php qui génère du code .net ou même du code sur pastebin).

On peut même lancer l'exécution/compilation de sources .Net via une simple url en utilise un URI scheme name particulier.

[neilbgr]

Que dire de CS-Script qui existe depuis un bon moment !

[tomlev]

Ca a pas l'air mal...

J'aime bien utiliser C# pour faire des choses qui seraient typiquement faites par des scripts, parce que la plupart des langages de script n'ont pas la richesse de C#. Ca fait des années que j'utilise LinqPad pour faire des "scripts" en C#, et c'est un outil excellent, mais ça ne permet pas d'exécuter un script depuis la ligne de commande, ni de faire du REPL... Donc ScriptCS pourrait bien rejoindre ma boite à outils

[Thorna]

C'est bien beau, mais ça me rappelle une question que je me suis déjà posée il y a 5 ou 10 ans à ce sujet, lorsqu'on commençait à voir sortir des émulateurs de jeux écrits en C#. Je crois bien d'ailleurs n'avoir jamais vu de réponse satisfaisante...
Lorsqu'on utilise csc ou un équivalent pour compiler un bout de script à la demande d'un premier programme et pendant l'exécution de celui-ci, où va le code produit ? Dans la même "boite" mémoire que le code principal du programme ? Ou ailleurs dans une zone protégée et dédiée?
Parce que si on compile un script pour l'exécuter, qu'on le modifie et le recompile ensuite, que devient le code précédent ? En général, le Garbage Collector ne fouille pas dans la zone du programme...

[ctxnop]

Quand tu fais de la compilation à la volée via les CodeProvider, tu obtiens un assembly "normal", chargé normalement, avec les mêmes contraintes qu'une compilation normale" : impossible à décharger, si tu charges 2 fois le même assembly le comportement devient indéfini car certaines instances proviendront d'un assembly et d'autres viendront du second assembly.

La compilation à la volée n'est donc pas réellement faite pour faire du scripting.

Par contre, depuis le framework 4 (je crois, pas vérifié en fait), il y a des "expressions". C'est du code collectable par le garbage et qu'on peut donc changer à chaud.
Avec ça on peut faire du scripting.

Et globalement c'est présent dans roselyn (le "futur" compilo .net), ainsi que dans Mono (je me sert de ce dernier personnellement, roselyn étant en CTP).