Einblicke in C# 6.0

Von Rainer Stropek, Oliver Sturm, Thomas Claudius Huber und 2 weiteren

Version 6.0 von C# bringt diverse Neuerungen und Änderungen mit sich, die in diesem shortcut näher beleuchtet werden. Betrachtet wird u.a. die .NET-Compiler-Plattform, vormals unter dem Codenamen „Roslyn" bekannt, die den alten C#-Compiler ersetzt. Ebenfalls gezeigt werden einige der typischen Fälle in einer MVVM-Applikation, in denen C# 6.0 den Entwicklern das Leben leichter macht. Darüber hinaus gibt es Hinweise und Tipps zu den neuen Sprachfeatures. Zuletzt kommt auch der Sicherheitsaspekt von C# 6.0 nicht zu kurz. Dieser shortcut enthält außerdem alles Wichtige zu C# 6.0 auf zwei Seiten in Form eines kompakten Spickzettels.

• Sprache: Deutsch
• Herausgeber: entwickler.press
• Erscheinungsdatum: 1. Apr. 2016
• ISBN: 9783868025842

Buchvorschau

GmbH

1 Wie das Projekt „Roslyn" im Hintergrund C# revolutioniert

Der Compiler für die C#-Entwicklung ist ein unverzichtbares Werkzeug. Quellcode geht rein, ein Assembly kommt heraus. Solange kein Fehler im Compiler steckt – was äußerst selten der Fall ist – ist er eine im Alltag relativ uninteressante Black Box. Was, wenn der Compiler sich plötzlich öffnen würde? Was, wenn der Quellcode Open Source wird und alles als .NET-Klassenbibliothek zur Verfügung steht? Diesen Schritt hat Microsoft mit dem Projekt „Roslyn" gewagt. In Visual Studio 2015 hat Roslyn die Betaphase verlassen, wurde in .NET Compiler Platform umbenannt und hat den alten C#-Compiler ersetzt. Lassen Sie uns gemeinsam über die Konsequenzen nachdenken und einen genaueren Blick auf die Plattform werfen.

Es gibt unzählige Einsatzbereiche von .NET: Full Clients, Apps, Webseiten, Web Services, Kommandozeilentools, Installer, Datenbanklogik etc. In diesen Bereichen gibt es spezifische Frameworks, Bibliotheken oder NuGet-Pakete. Eine Komponente haben aber alle diese C#-Programme gemeinsam: den Compiler. Er ist das Arbeitspferd aller C#-Entwicklerinnen und -Entwickler.

Der C#-Compiler im Wandel

Der C#-Compiler hat sich im Laufe der Zeit gewandelt. In den ersten Versionen war er ziemlich schlank, da die Funktionen von C# ziemlich nahe an den Möglichkeiten waren, die die zugrunde liegende Plattform – die Common Language Runtime (CLR) und die Microsoft Intermediate Language (MSIL) – bot. Viel von der Arbeit, die in anderen Programmiersprachen der Compiler machen musste, erledigt in .NET der nachgeschaltete Just in Time-Compiler (kurz JIT oder „jitter"), der in .NET sprachenunabhängig ist. Im Laufe der Zeit wurden aber mehr und mehr wichtige Funktionen in die Sprache C# integriert, die kein unmittelbares Gegenstück in der CLR haben. Beispiele dafür sind Lambda-Ausdrücke, Linq und Expression Trees oder async/await. Es ist Aufgabe des C#-Compilers, solche Sprachelemente in IL zu übersetzen. Wenn Sie einmal sehen möchten, was der C#-Compiler der aktuellen Version alles zu tun hat, schreiben Sie ein paar Zeilen asynchronen Code mit Lambdas und async/await. Anschließend verwenden Sie ein Tool wie ILDasm.exe oder .NET-Reflector, und sehen Sie sich den generierten IL-Code an. Sie werden überrascht sein, wie stark der entstehende IL-Code von Ihrem C#-Quellcode abweicht.

Ein Compiler reichte nicht

Neben den funktionalen Erweiterungen der Sprache C# gab es eine wichtige Parallelentwicklung. Die Erwartungen von uns Programmiererinnen und Programmierern an die Entwicklungsumgebung Visual Studio stiegen von Version zu Version. Wir wurden verwöhnt mit Funktionen wie

der Anzeige von Compilerfehlern schon während des Tippens

IntelliSense

der intelligenten Umbenennung

den mächtigen Such- und Navigationsfunktionen wie Find all References oder Call Tree

Tooltips, die eine komplexe, semantische Analyse des C#-Codes zur Editierzeit erfordern und vieles mehr

Diese Features erscheinen aus Sicht der Anwenderinnen und Anwender simpel. Ihre Umsetzung erfordert jedoch tiefgreifendes Verständnis des C#-Codes und der zugehörigen Solution- und Projektstruktur. Der ursprünglich in C++ entwickelte C#-Compiler war dafür nie entworfen worden. Er enthält zwar intern alles, um Funktionen wie die oben genannten umzusetzen, dieses Wissen ist jedoch in einer Black Box verborgen und steht außen nicht zur Verfügung. Als Konsequenz musste Microsoft eine zweite Compilerinfrastruktur für die Entwicklungsumgebung nachbauen.

Diese Notwendigkeit war nicht auf Microsoft beschränkt. Wollte man bisher ein Tool schreiben, das C#-Code analysiert und vielleicht sogar automatische Verbesserungen des Quellcodes anbietet, musste man ebenfalls zumindest einen Teil des C#-Compilers nachbauen. Das war ein Unterfangen, das sich nur wenige große, spezialisierte Teams in der Vergangenheit leisten konnten.

Zeit für einen Neustart

Aus eigener Erfahrung weiß jede C#-Entwicklerin und jeder C#-Entwickler, dass Code, dessen Aufgabe sich im Laufe der Zeit stark erweitert und verändert, nicht besser wird. Auch der Code eines Compilers ist nicht immun gegen das Phänomen von historisch gewachsenem Spaghetticode. Vor einigen Jahren entschied das C#-Team bei Microsoft daher, dass es an der Zeit war, aufzuräumen. Das Projekt mit Codenamen „Roslyn" war geboren. Roslyn sollte nicht nur eine kleine Verbesserungsmaßnahme werden. Microsoft hatte für dieses Projekt weitreichende Ziele:

Der neue C#-Compiler sollte nicht mehr in