Interview mit Robin Sedlaczek

Roslyn: Möglichkeiten und Grenzen der neuen .NET Compiler Plattform
Kommentare

Mit der .NET Compiler Platform, auch bekannt unter dem Namen „Roslyn“, öffnet Microsoft seine Compiler für C# und VB.NET. „Öffnen“ bedeutet aber nicht nur, dass der Quellcode als Open Source zur Verfügung gestellt wird. Vielmehr bricht der Softwarehersteller die Blackbox der Sprachübersetzer auf und erlaubt mittels neuer APIs und Objektmodelle den Zugriff auf alle Phasen der Kompilierung von der Syntaxanalyse bis zur Codegenerierung.

Auf dem .NET Summit 2016 in München wird Robin Sedlaczek (Fairmas GmbH) eine Session zum Thema „Roslyn – Ein offener Compiler. Ja, und nun?“ geben.Wir haben schon vorab mit ihm gesprochen und ihn zu seinem Eindruck zur neuen .NET-Compiler-Plattform befragt.

In Visual Studio 2015 hat Roslyn die Betaphase hinter sich gelassen, wurde in .NET-Compiler-Plattform umbenannt und hat den alten C#-Compiler ersetzt. Doch warum brauchte Microsoft eigentlich einen neuen Compiler?

Robin Sedlaczek: Seit über einem Jahr sehen wir, dass Microsoft die von seinem neuen CEO Satya Nadella postulierte Strategie „Mobile first, Cloud first“ konsequent verfolgt und in die Tat umsetzt. Wesentlicher Bestandteil dieser Strategie ist die Plattformunabhängigkeit. Das gilt ebenso für die eigene Entwicklungsplattform:

„Nur Windows“ reicht lange nicht mehr aus. Aus diesem Grund musste man es irgendwie schaffen, Compiler und Laufzeitumgebung auf die anderen Plattformen zu bringen.

Den Code offen zulegen und die Unterstützung der Community für sich zu gewinnen, war die logische Konsequenz. Zudem machen eine vereinheitlichte Laufzeitumgebung und Sprachplattform die Portierung von Anwendungen auf andere Plattformen um ein Vielfaches einfacher. Hersteller Xamarin arbeitet hier sehr eng mit Microsoft zusammen. Beide Unternehmen ergänzen gegenseitig die Codebasis von Mono und .NET Core. Schon anhand dieses Synergieeffektes lassen sich die Vorteile der neuen offenen Compiler-Plattform erkennen.

Mit Azure bietet Microsoft breit aufgestellte Cloud-Dienste an. Die Redmonder Wolke bietet hier einen hohen Grad an Flexibilität; ein weiterer Grund, der einen offenen und plattformunabhängigen Compiler unabkömmlich macht.

Der nach Azure deployte Code wird direkt in der Cloud kompiliert. Und hier geht es um jede tausendstel Sekunde. Code, der bereits kompiliert wurde, muss nicht erneut vollständig durch den Compiler gejagt werden. Somit müssen unveränderte Kompilate auch nicht erneut in die Zielumgebung kopiert werden. Mit der .NET Compiler Plattform ist es möglich, lediglich den neuen oder geänderten Code zu kompilieren und ihn dann zu deployen. Das spart Zeit.

Die Cloud-Story und die Cross-Plattform-Story sind nicht die einzigen Motivationen hinter Roslyn. IDEs und Code-zentrierte Werkzeuge werden immer mächtiger, umfangreicher und bieten immer mehr Funktionen. Voraussetzung ist, dass die Werkzeuge ein tiefes Verständnis des Codes besitzen. Und wer weiß da schon mehr über den Code als ein Compiler!?

Schnell und überall: Datenzugriff mit Entity Framework Core 2.0

Dr. Holger Schwichtenberg (www.IT-Visions.de/5Minds IT-Solutions)

C# 7.0 – Neues im Detail

Christian Nagel (CN innovation)

 

Was unterscheidet Roslyn von anderen Compilern?

Sedlaczek: Das Problem an den klassischen C#- und VB.NET-Compilern ist das sogenannte Blackbox-Prinzip. Code wird vorne reingesteckt, das konservierte Expertenwissen innerhalb der Blackbox verrichtet dann ein wenig Magie und spuckt am Ende die Kompilate aus.

Compiler-as-a-Service macht mich zum Zauberer, indem ich auf die Magie innerhalb des Compilers zugreifen kann.

Die einzelnen Kompilierphasen lassen sich damit steuern und ich kann auf deren Ergebnisse (z.B. den Syntaxbaum und die Symboltabellen) zugreifen. Und genau hier liegen die Stärken. Der Compiler kann vollständig für die eigenen Zwecke instrumentalisiert werden. Und das nicht nur mit selbstgebauten Refactorings, die als Plugins in das Studio gehängt werden können. Mit Analyzern bietet die Compiler-Plattform Erweiterungspunkte direkt im Compiler an.

Man kann also eigene Regeln implementieren und diese direkt in die Compiler-Pipeline einhängen. Mit jedem Kompiliervorgang werden diese Regeln dann auf den Code angewendet. Verstößt der Quelltext gegen eine solche Regel, wird das als Compiler-Warnung oder -Fehler ausgegeben.

Solche Analyzer können ganz bequem zu einem Projekt über die Visual Studio-Oberfläche hinzugefügt werden. Ganz so wie man es von Referenzen kennt. Damit können dann beispielseise Best Practices, firmeneigene Code-Richtlinien oder domänenspezifische Regeln direkt im Code und zur Entwicklungszeit erzwungen werden. Das verlagert so einige Aufwände aus z.B. Review-Meetings und anderen QS-Aktivitäten weiter nach vorne in den Entwicklungsprozess. Das wiederum reduziert Kosten. Mit Code-Fixes können dann sogar Lösungsvorschläge für einen diagnostizierten Regelverstoß direkt in der IDE angeboten werden.

Zusammengefasst: die Erweiterbarkeit der Compilers und die Möglichkeit zur Instrumentalisierung einzelner Compiler-Phasen, über sehr einfache und intuitive APIs, stellen die wesentlichen Vorteile von Roslyn dar.

Welche Vorteile ergeben sich für Entwickler durch den Open-Source-Ansatz?

Sedlaczek: Ganz klar, die Möglichkeit zur Kollaboration mit dem Roslyn-Team und die Einflussnahme auf die Entwicklung der Sprachen. Auch wenn das nicht so unbedingt auf der Hand liegt oder einen direkten Mehrwert für die eigenen Anwendungen und Produkte mit sich bringt, an denen die meisten von uns in ihrem Entwickleralltag arbeiten, kann jeder interessierte Entwickler Einfluss auf die Gestaltung des Sprachumfangs und der Sprachfeatures nehmen. Ideen für neue Sprachmerkmale können als Issues auf GitHub eingereicht werden.

Es geht aber noch einen Schritt weiter. Als Entwickler kann ich selbst tätig werden und bei der Beseitigung von Bugs oder bei der Implementierung von neuen Sprachmerkmalen helfen. Dazu nimmt das Roslyn-Team Pull Requests entgegen und garantiert der Community mindestens den Review eines solches Requests. Über den auf GitHub integrierten Chat Gitter kann zudem direkter Kontakt zum Team aufgenommen werden.

Im Allgemeinen wird durch den Open-Source-Ansatz eine ganz neue Nähe zum Team bei Microsoft ermöglicht. Aber auch wenn ich nicht direkt an der Kollaboration teilhaben möchte, so kann ein interessierter Entwickler immer in den Quellcode schauen und sollte das auch von Zeit zu Zeit einmal tun. Sehr oft kann das inspirierend und lehrreich sein. Ein weiterer Vorteil ist die Plattformunabhängigkeit. Das geht natürlich einher mit .NET Core.

Durch die Partizipation der Community wächst die Unterstützung für andere Plattformen, denn hier wird aktiv und intensiv dabei geholfen, .NET auf andere Hardwarearchitekturen und Plattformen zu bringen.

Als Entwickler habe ich also nunmehr die Freiheit zu wählen, auf welcher und für welche Plattform ich entwickeln möchte.Ohne den Open-Source-Ansatz wäre das mit Sicherheit nicht so einfach möglich gewesen.

Nach über einem Jahr Roslyn: Wo siehst du aktuell die Einschränkungen der Compilerplattform?

Sedlaczek: Die Roslyn-Compiler an sich beeindrucken mit einer recht guten Performance. Probleme gibt es momentan aber noch in dem aufsetzenden Tooling in Visual Studio. So muss man bei der Anwendung von Refactorings oder Code-Fixes auf eine gesamte Projektmappe schon einmal etwas warten. Sicherlich ist das abhängig von der Größe der Projektmappe. Nichtsdestotrotz muss der Compiler direkt bei der Anwendung alle noch nicht betrachteten Codedateien parsen und analysieren. Erst dann kann das Refactoring oder der Code-Fix ausgeführt werden.

Ein wenig kritischer ist das Ganze dann, wenn man die Aktion rückgängig machen möchte. Die Undo-Operation nimmt noch mehr Zeit in Anspruch. Ganz abgesehen von der noch nicht so konsistenten Benutzerführung der IDE. Geschuldet ist das dem momentanen Design. Code wird erst geparst und analysiert, wenn dieser benötigt wird, z.B. wenn er im Editor geöffnet wird. Dieser Ansatz spart Zeit und Arbeitsspeicher beim Laden einer Projektmappe, wirkt sich dann aber auf das Laufzeitverhalten aus.

Stellen Sie Ihre Fragen zu diesen oder anderen Themen unseren entwickler.de-Lesern oder beantworten Sie Fragen der anderen Leser.

Im Roslyn-Projekt auf GitHub sieht man aber Anstrengungen, die Problematik zu beheben. Dort werden Strategien für Performancemessung und -analysen diskutiert und aufgebaut.

Unter anderem sollen im Continuous-Integration-Prozess-Messungen in Beispielprojektmappen verschiedener Größen automatisiert durchgeführt werden.

Die .NET Compiler Platform umfasst lediglich die Sprachen C# und VisualBasic.NET. Andere Sprachen sind nicht Teil des Projektes, obschon es hier eine große Auswahl gibt: A#, Boo, IronPython, IronLisp, IronRuby, F#, L#, P#, R#, Eiffel, Phalanger, Oxygene, Cobra – um nur ein paar zu nennen.

Warum das so ist, liegt auf der Hand. Die meisten der genannten Sprachen kommen nicht aus dem Hause Microsoft, sondern sind CLI-konforme Sprach-Implementierung von Drittherstellern. Technische Aspekte, wie z.B. signifikante Abweichungen zwischen den Grammatiken, könnten zu größeren technischen Herausforderungen führen.

Relativ häufig wird die Frage gestellt, wieso F# nicht Teil des Roslyn-Projektes ist. Die Antwort von Microsoft lautet darauf, dass das F#-Projekt ein etabliertes Open-Source-Projekt, mit seinem eigenen Ökosystem, eigenen Prozessen und einer großen gewachsenen aktiven Community geworden ist. Gute Gründe und signifikante Vorteile sieht man nicht in der Auflösung und Zusammenführung der Projekte. Der Begriff „.NET Compiler Platform“ erscheint daher ein wenig irreführend. Alle Vorteile der Instrumentalisierung des Compilers stehen mir also nur für C# und VisualBasic.NET zur Verfügung.

Ein weiteres Problem sehe ich bei der Dokumentation – diese lässt sehr zu wünschen übrig.

Neben einem Überblick über die API-Schichten, ein paar Walkthroughs und ein paar wenigen Beispielprojekten, lässt die Dokumentation noch zu wünschen übrig. Der eigentlich Dokumentations-Ordner im Repository ist weitestgehend leer und nur bruchstückhaft mit Informationen befüllt. Zwar kann ein Blick in die Roslyn-Projektmappe helfen, ein paar mehr Dokumente im Repo oder im MSDN wären hier sicherlich sehr hilfreich. Insbesondere was die Dokumentation der öffentlichen APIs angeht.

Problematisch finde ich außerdem, dass den meisten Entwicklern nicht bewusst ist, mit welcher Sprachversion sie im Visual Studio arbeiten. Oft ist die Annahme, dass die Sprachversion abhängig von der gewählten .NET Framework-Version ist. Das stimmt nicht wirklich. Denn man kann z.B. C# 6 auch in Projekten benutzen, die auf ältere Versionen des .NET Frameworks abzielen. Ausschlaggebend ist das zugrundeliegende Tooling, also die Visual Studio-Version oder die zum Build verwendete MSBuild-Version.

Spätestens auf dem Build- bzw. dem Continuous Integration Server gibt es Probleme, wenn dieser neuere Sprachversionen nicht unterstützt. Hier muss also noch etwas mehr Transparenz von Microsoft geschaffen werden. Eventuell hilft an dieser Stelle der Plan, die Compiler-Version als NuGet-Package auszuliefern. Damit erhält man die vollständige Kontrolle über die verwendete Sprachversion.

Du selbst gibst bereits Workshops zur Anwendung von Roslyn – bist also schon praxiserprobt. Wie sieht es in deiner Firma (Fairmas GmbH) aus, setzt ihr Roslyn bereits produktiv ein oder ist die Nutzung von Roslyn dort eher noch ein Experiment?

Sedlaczek: Die Frage ist recht einfach zu beantworten: Ja, wir benutzen es produktiv. Wenn man es genau nimmt, dann gilt das aber für alle Entwickler, die Visual Studio 2015 im Einsatz haben. Denn wie bereits erwähnt, wurde das neue Visual Studio generalüberholt. Es baut nun vollständig auf Roslyn auf. Sämtliche Editor-Features der IDE, wie z.B. Refactorings, Find all References, Go to Definition, Outlining, Object Browser usw., instrumentalisieren die neue .NET Compiler Plattform. Und so benutzt jeder Entwickler irgendwie Roslyn.

Bewusst nutzen wir die neuen Funktionen der Plattform aber ebenfalls. Denn sie bietet uns tolle Möglichkeiten, den Code auf für uns definierbare Schwachstellen bzw. Verstöße gegen Business-Regeln zu untersuchen. Dazu haben wir uns einige Analyzer implementiert, die z.B. auf die Verwendung von spezifischen Klassen als Basisklassen von WebAPI-Controllern prüfen. All unsere WebAPI-Controller müssen also von diesen spezifischen Basisklassen erben, direkt oder indirekt, um eben bestimmten Funktionalitäten mitzubringen. Ebendas checkt ein Analyzer, diverse Code Fixes können dann entsprechende Korrekturen vornehmen.

Ein großer Teil der Daten mit denen wir in unseren Finanzplanungstools umgehen, sind sensitive Daten. Hier unterscheiden wir, und unsere Kunden, die Daten in verschiedenen Kategorien, also Sicherheitseinstufungen. Daraus ergeben sich verschiedene Anforderungen, wie mit den Daten umgegangen werden muss. Aus diesem Grund versuchen wir, die Daten bereits über den Code zu klassifizieren. Analyzer helfen uns dabei, die Daten je nach Klassifikation zu visualisieren. Aufsetzende QS-Prozesse können dadurch ebenfalls einfach gestaltet werden. In Code-Reviews kann direkt der Code untersucht werden, der kritisch ist; mit Roslyn kann dieser nämlich hervorgehoben werden.

Auch in unseren ALM hilft uns Roslyn: Stichwort „Semantische Versionierung“

Um die Unterschiede unserer Backend-APIs von Version zu Version festzustellen, benutzen wir einen Analyzer, der die in der WebAPI-Schicht vorkommenden öffentlichen API-Methoden gegen eine Liste checkt. Fügt ein Entwickler neue Methoden zum Backend hinzu, prüft der Analyzer, ob diese Methode in der Liste auftaucht. Tut sie das nicht, so kann diese neue Methode mittels eines Code Fixes direkt im Studio auf Tastendruck zur Liste hinzugefügt werden. Fehlt im Code eine Methode, die bereits in der Liste ist, meldet auch die ein Analyzer. Mit einem Code Fix kann die Methode entweder aus der Liste entfernt, oder dem Code hinzugefügt werden. Am Ende eines Sprints wissen wir also immer, wie sich unser Backend verändert hat. Darauf basierend generieren wir dann die Dokumentation und versionieren das Backend.

Zeigt man Entwicklern den Mehrwert, den man durch zielgerichtete Analyzer und Code Fixes schaffen kann, sehen sie schnell die Vorteile. Mit entsprechender Motivation, finden unsere Leute dann immer wieder neue Anwendungsfälle, bei denen Roslyn die Produktivität steigern kann. Man benötigt da eben nur etwas Freiraum zum brainstormen und zum Umsetzen.

Aufmacherbild: Businessman looking through a magnifying glass von Shutterstock / Urheberrecht: aarisham

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -