Spätestens seit der Build 2014 ist “Roslyn” wieder in aller Munde. Was ist das aber eigentlich? Man könnte die Frage einfach beantworten und sagen: Ein Compiler. Damit hätte man zwar Recht, würde aber die wesentliche Information weglassen. Einen einfachen Compiler hatten wir ja früher auch schon. Wahrscheinlich ist es sinnvoller, Roslyn als Compilerplattform zu bezeichnen.

Um hier ein bisschen mehr Licht ins Dunkel zu bringen, halten wir uns noch einmal vor Augen, was ein Compiler eigentlich so tut. Generell macht ein Compiler aus Quellcode Assemblies – aus menschenlesbaren Zeichen entsteht also irgendetwas binäres, was dann wieder auf einer Maschine ausgeführt werden kann. Im Falle von .Net Quellcode sorgt der Compiler dafür, dass eben eine .Net Assembly entsteht. Eigentlich kann uns Entwicklern absolut egal sein, wie der Compiler das macht. Für uns ist auf den ersten Blick nur wichtig, dass er es macht – und zwar bitte möglichst schnell.

image

Nun ist so ein Compiler ein ziemlich kompliziertes Ding. Vermutlich hat jeder Informatik-Student irgendwann mal einen kleinen Compiler (oder zumindest einen Teil davon) schreiben dürfen. Im Prinzip muss der Compiler den Quellcode verstehen können – und dazu unter anderem Zeichen für Zeichen parsen und einen sogenannten Syntaxtree aufbauen – also die Struktur des Quellcodes in eine sinnvolle Form gießen und so weiter und so weiter. Wenn man nicht gerade selbst einen Compiler baut, wird man sich kaum dafür interessieren, was hier unter der Haube passiert.

image

Dadurch, dass der Compiler weiß, wie der Code aufgebaut ist und zusammenhängt, ist er in der Lage erstaunliche Dinge zu ermöglichen. Das farbliche Hervorheben von Klassennamen, das Formattieren von Quellcode, das Überprüfen von Code auf Korrektheit, Intellitrace und so weiter – all das ist mit dem Wissen des Compilers über den Quellcode relativ einfach. Schließlich kennt er den eben geschriebenen Code in- und auswendig und kann uns die ganzen Komfortfeatures, die wir Entwickler im Visual Studio so schätzen, ermöglichen.

Der Witz ist, dass ja mit jeder Version von Visual Studio dieser Compiler ohnehin mitkommt. Wenn man jetzt als Entwickler die Möglichkeit hätte, die gesamte Intelligenz des Compilers anzuzapfen, um eigene Mechanismen, Prüf-, Komfort- oder Refactoringfunktionen einzubauen, wäre das doch großartig?!

Genau! Und genau das wird mit Roslyn ermöglicht.

image

Man kann sich Roslyn also als eine Art “Compiler mit APIs” vorstellen. Als Entwickler habe ich die Möglichkeit Roslyn zu nutzen, um eigene Validierungen und Codegeneratoren, Analysen etc. zu erstellen – ohne, dass ich mich um lästiges Syntaxparsing u.ä. kümmern muss. Hierfür gibt es unterschiedliche APIs, z.B. die Syntax Api oder die Warnings API. Damit lädt Microsoft ein, genau das auch zu tun. Und damit es allen besonders leicht gemacht wird und jeder genau weiß, was da eigentlich vor sich geht, hat Anders Heilsberg Roslyn während der Build Keynote als OpenSource(!) Projekt auf Codeplex freigegeben. (Im Screenshot unten ist genau dieser Moment zu sehen.) Das alleine ist noch einmal mindestens so spektakulär, wie die Tatsache, dass Roslyn inzwischen endlich als End User Preview verfügbar ist. Im Prinzip hat jetzt jeder Mensch auf der Welt die Möglichkeit nachzusehen, wie der Code für den C#/.Net Compiler aussieht. Erneut ein schöner Beweis dafür, wie offen Microsoft inzwischen ist.

image

Wenn Ihr Roslyn in der Preview installiert, werdet Ihr in Visual Studio neue Projektvorlagen finden auf Basis derer ihr anfangen könnt mit Roslyn zu experimentieren. Unter den unten genannten Links findet Ihr hier jede Menge weiterführende Information und auch Tutorials. Falls Ihr bereits Visual Studio Extensions entwickelt habt, werdet Ihr Euch sicher schnell wohl fühlen. In diesem Fall empfehle ich Euch auch meinen Visual Studio Tipp Nr. 33, um beim Entwickeln mit Roslyn Verwirrung zu vermeiden.

Die wichtigsten Links zu diesem Thema findet Ihr hier: