Basta 2017 - Tag 01 - C# Workshop

Dieses Jahr war ich auf der Basta in Frankfurt (basta.net ). Sie ging vom 20. – 24. Februar und war meine erste Basta-Konferenz überhaupt. Ich habe mich wohl gefragt, wie die Vorträge so werden und die Organisation in der Praxis aussieht.

Das Check-In ging schnell. Die Warteschlange war sehr kurz. Es waren auch 3 – 4 Damen gleichzeitig mit dem Einchecken und Aushändigen der Besucherausweise beschäftigt. Direkt neben der Rezeption lagen Basta-Rücksäcke. Diese beinhalteten eine Ausgabe der aktuellen Windows Developer und weitere nützliche Gegenstände.

Die Basta ist so aufgeteilt, dass am ersten und letzten Tag jeweils ein Workshop stattfindet. An den anderen Tagen gibt es einzelne Sessions bzw. Vorträge. Ich habe am Montag den C#-Workshop von Herrn Rainer Stropek besucht.

Er hat vor allem .NET Core vorgestellt und wie mittels Kommandozeile neue Projekte angelegt und ausgeführt werden können. Fast alles kann per Kommandozeile erledigt werden. Eine IDE wie Visual Studio wird jedoch weiterhin File -> New Project bereitstellen. Entwickler müssen sich jedoch wieder an die Kommandozeile gewöhnen. .NET Core unterstützt den .NET Standard (MSDN Blog Introducing .NET Standard ) . Dieser Standard definiert einen Funktionsumfang. .NET Core stellt die Implementierung für Windows, Mac und Linux dar. Das .NET Framework beinhaltet die Implementierung nur für Windows.

Er betonte, dass die Zukunft von Microsoft in Richtung Cloud gehen wird. Daher werden die ganzen DLLs und Teile aus dem Framework in kleine Micro-Frameworks unterteilt. Hierdurch ist eine sehr granulare Zusammenstellung möglich. Vorher wurde eine (wie Herr Stropek sagte) Salamipizza ausgeliefert und man musste die Salami liegen lassen. Jetzt können wir eine Pizza Salami ohne Salami bestellen. Vor allem im Bereich Rechenzentren kann die Salami (wenn mehrere hundert oder tausend Kunden diese nicht haben wollen) unnötige Kosten verursachen. Es kommt ja auch keiner auf die Idee, auf einem Server WPF zu installieren, wenn nur Webanwendungen gehostet werden.

Das project.json wird in Zukunft entfallen. Das neue csproject besitzt jedoch eine sehr viel einfachere Struktur als bisherige Projekte mit VS 2015. Des Weiteren gibt es jetzt eine neue Webseite zur Dokumentation von Microsoft. Früher wurde MSDN genutzt. Jetzt gibt es dafür https://docs.microsoft.com/ . Ein Vorteil von docs.microsoft.com ist es, dass ein gesamtes Kapitel als PDF heruntergeladen werden kann. Zudem ist auch die Dokumentation durch Github erreichbar, sodass jeder einen Teil (Kommentar, Issue oder PullRequest) beitragen kann. Auch Sandcastle ist veraltet und Dokumentation sollte zukünftig in Markdown-Dateien angelegt werden. Durch static-pages-generators wie Jekyll lassen sich aus diesen Dateien schnell eine Produkt oder Projekt-Homepage bereitstellen.

In einer kleinen Kaffeepause konnten die bisherigen Informationen ersteinmal verarbeitet werden.

Anschließend wurden Neuerungen im aktuellen ReleaseCandidate von VS 2017 vorgestellt. In der Projektdatei wird über das SDK und TargetFramework implizit definiert, welche Abhängigkeiten bestehen. Durch dotnet restore werden diese Pakete geladen und bereitgestellt. Zudem kann eine Projektdatei nun ohne „unload“ im Visual Studio bearbeitet werden.

Um .NET-Core besser zu verstehen, haben wir uns gemeinsam eine Methode von System.IO.File per ILDASM angeschaut. Dort wurden viele Methoden als „extern forwarder“ definiert. Dies bedeutet, dass je nach Framework entweder eine Implementierung aus .NET Core oder .NET Framework aufgerufen wird. Für den Programmierer, welcher eine .NET Core App entwickelt ändert sich bezüglich der Aufrufe wenig.

Herr Stropek empfahl für neue Projekte bereits den .NET Standard 1.6 (oder je nach Anwendungsfall 1.4) einzusetzen. Ansonsten solle man auf Version 2.0 warten, welche innerhalb dieses Jahres veröffentlicht wird. Zurzeit gibt es sehr viele verschiedene Versionen. Mit der neuen Version 2.0 soll eine stabile Plattform geschaffen werden, welche für den produktiven Einsatz geeignet ist. Anschließend wurde das Veröffentlichen einer Anwendung vorgestellt. Es gibt zwei Arten von Veröffentlichungen. Mit einer wird eine Anwendung inklusive aller DLLs zum self-hosting bereitgestellt. Wenn das System bereits eine Hosting-Umgebung beinhaltet, reduziert sich die Menge der veröffentlichen DLLs erheblich. Hier konnte man als Entwickler direkt die Änderungen von Microsoft sehen. Eine relativ kleine Anwendung hatte (als self-hosting application) mehr als 50 DLLs. Ich bin aus einem „normalen“ Umfeld erheblich weniger gewohnt, da DLLs wie System meist bereits installiert sind.

Zur Mittagspause gab es ein sehr reichliches Angebot an Speisen und Getränken. Die Pause war notwendig, um etwas Luft zu bekommen. Vor allem konnte die Zeit dadurch genutzt werden, mit anderen Besuchern die bisherigen Erfahrungen und Eindrücke auszutauschen.

Nach der Mittagspause wurde vor allem auf Änderungen in ASP und Sprachfeatures von C# eingegangen. Mit dotnet run kann eine Anwendung (auch Web) direkt gestartet werden. Es empfiehlt sich jedoch, einen IIS oder Nginx als Server um die produktive Anwendung zu betreiben. Kestrel ist nicht für einen produktiven Betrieb ausgelegt (v.a. sicherheitstechnisch) . In .NET Core gibt es prinzipiell nur noch Konsolenanwendungen. Auch eine Webanwendung beinhaltet eine public static void main(), welche intern den Web-Host und die Webseite startet.

Die web.config, fällt weg. Die Konfiguration kann über ConfigurationBuilder (MSDN Magazin ConfigurationBuilder ) organisiert werden. Mir gefällt der neue Ansatz sehr gut. Er erlaubt eine Basiskonfiguration, die je nach Laufzeit durch eine spezifische release- oder debug-Konfiguration anpassen lässt ohne den Code zu ändern. Es gibt (neben einer JSON-Konfiguration) auch die Unterstützung einer INI-Konfiguration.

Neben dem ConfigurationBuilder gibt es nun auch eine native Unterstützung für Dependency Injection. Vorher musste mit Ninject, MEF, Unity und vielen mehr Dependency Injection nachträglich implementiert werden. In der Startup-Datei können nun alle Services hinzugefügt und ein Mapping durchgeführt werden. Falls die verwendeten Frameworks eine Funktion beinhalten, welche unbedingt notwendig ist, kann selbstverständlich ein eigenes DI-Framework verwendet werden. Das DI-Framework von Microsoft unterstützt nur Constructor-Injection.

Auch das Aufrufen und erstellen von Tests (entweder XUnit oder MSTest) wurde kurz vorgestellt. Durch dotnet test kann ein Test direkt auf der Konsole ausgeführt werden.

Nach einer kurzen Kaffeepause ging es vor allem um neue Sprachfeatures innerhalb von C#. Viele davon lassen sich auf den offiziellen Microsoft-Webweites nachlesen. Daher halte ich deren Beschreibung relativ kurz. Es wurden u.a. folgende Funktionen vorgestellt:

• Lokale Funktionen vs. Delegates
• Scoping von lokalen Funktionen
• Type pattern (obj is string s)
• Pattern matching (case int factor when factor > 5)
• Ausweitung von ref auf Rückgabetypen
• Tupel
• Deconstruct-Methoden, um eine Klasse in ein Tupel umzuwandeln
• Unterstrich als Trennzeichen für Zahlen. 1_024, 0b1000_0000, 0x10_00

ALs Highlights wurden vor allem die Features „Pattern Matching“ und „Local Functions“ hervorgehoben. Um die weitere Entwicklung von Roslyn und C# zu beobachten empfehlen sich die Roadmaps, welche öffentlich auf Github sichtbar sind. Generell hat sich Microsoft stark gewandelt. Viele Open-Source Projekte von Microsoft wären früher so nicht denkbar gewesen.

Die Beispiele von Herrn Stropek findet ihr auf Github: https://github.com/rstropek/Samples

Insgesamt war es ein sehr erfolgreicher Tag, auch wenn sehr sehr viele Informationen vermittelt wurden. Aus meiner bisherigen Erfahrung mit anderen Seminaren oder Weiterbildungen gefällt es mir besser, wenn ich mit zu vielen Informationen nach Hause gehe. Das ermöglicht einen Blick über den Tellerrand und die Möglichkeit der eigenen Recherche nach Informationen. Ich bin gespannt, wie die nächsten Tage mit den kürzeren Vorträgen werden.

Anmerkung: Einige Stellen habe ich bewusst kürzer gehalten, da an diesem Tag sehr viele Informationen vermittelt wurden. Ich wollte den Artikel nicht zu lang werden lassen.