Expertencheck .NET Core 3.0: Das sind die Highlights!

Die Version 3 von .NET Core ist erschienen. Wir haben uns mit Thomas Claudius Huber, Dr. Holger Schwichtenberg, Jens Lorek und Sebastian Gingter, allesamt .NET-Experten und Sprecher auf der aktuell stattfindenden BASTA!-Konferenz, über die neue Version und die weitere Entwicklung hin zu .NET 5.0 unterhalten.

Im ersten Teil unseres großen Expertenchecks geht es um die Neuerungen in .NET Core 3.0. Außerdem gehen wir der Frage nach, für wen sich ein Update lohnt und welche weiteren Themen die Experten auf der BASTA! beschäftigen.

.NET Core 3.0 – die Highlights

Entwickler: .NET Core 3.0 ist gerade erschienen. Was ist für dich persönlich das Highlight der neuen Version?

Thomas Claudius Huber: Für mich ist das Highlight, dass sich bestehende WPF und Windows-Forms-Anwendungen auf .NET Core 3.0 portieren lassen. Somit stehen auch in diesen weit verbreiteten Desktop-Anwendungen die .NET Core Runtime (und damit C#-8-Sprach-Features) und diverse .NET Core Features wie Self-contained Deployments zur Verfügung. Ich freue mich sehr auf diesen Teil, bin aber auch voller Vorfreude, dass Blazor zumindest Server-side Teil von .NET Core 3.0 ist. Wer gerne Angular-Applikationen baut, aber auch gerne C# programmiert, der sollte Blazor definitiv anschauen.

Die Experten

Thomas Claudius Huber ist Microsoft MVP im Bereich Windows Development und Senior Principal Consultant und Partner der Trivadis AG. Als Trainer, Berater und Entwickler ist er in den Bereichen C#, TypeScript, WPF, UWP, Angular und Azure unterwegs. Seine persönliche Webseite finden Sie unter www.thomasclaudiushuber.com.

Dr. Holger Schwichtenberg (alias „Dotnet-Doktor“) ist Leiter des renommierten .NET-Expertennetzwerks www.IT-Visions.de, das zahlreiche Unternehmen in Europa durch Beratung, Schulung, Coaching und Support unterstützt. Zudem ist er Entwicklungsleiter beim Softwaredienstleister 5Minds IT-Solutions GmbH & Co. KG (http://www.5Minds.de). @DOTNETDOKTOR.

Jens Lorek ist Senior Software Engineer bei der Accso – Accelerated Solutions GmbH. Durch mehr als zehn Jahre Erfahrung im Bereich der .NET-Entwicklung hat er schon einige Trends kommen und gehen sehen. Deswegen ist er ein ziemlicher Fuchs, wenn es in der Projektarbeit darum geht, auf die richtigen Technologien zu setzen.

Sebastian Gingter blickt auf über fünfzehn Jahre Erfahrung als professioneller Softwareentwickler zurück. Im Zuge seiner Arbeit bei der Thinktecture AG liegt sein Fokus auf modernen (Web-)Technologien sowohl auf dem Client mit Type- und JavaScript, als auch auf dem Server mit JavaScript unter Node.js oder C# mit klassischem ASP.NET und .NET Core. Seinen Blog findet man unter https://gingter.org. Twitter: @PhoenixHawk

Dr. Holger Schwichtenberg: Meine Highlights: Desktop-Anwendungen auf .NET Core (WPF und Windows Forms) und mit „Server Side Blazor“ ein erster Schritt in Richtung der Programmierung von Single-Page-Web-Applications mit .NET und C#! Auch die neuen Deployment-Optionen (Single File Publish, IL Linker, Ready to Run Images, Windows Application Packaging mit MSIX) können uns und unseren Kunden in der Praxis gut helfen.

Jens Lorek: Für meine tägliche Arbeit freue ich mich natürlich in erster Linie auf die Unterstützung von C# 8. Im Konkreten auf asynchrone Streams und auch syntaktischer Zucker wie die neuen Using Declarations. Doch es gibt auch kleinere Framework Features, welche aus meiner Sicht durchaus nennenswert sind. Dazu zählen beispielsweise Single File Executables. Dieses ermöglicht die Erzeugung einer einzigen plattformspezifischen, ausführbaren Datei, welche alle benötigten Abhängigkeiten beinhaltet. Klar, das war schon lange Zeit mit Hilfe von anderen Extra Tools möglich. Es ist aber eine durchaus praktische Funktionalität, welche jetzt nativ unterstützt wird.

Parallel mit .NET Core 3.0 soll auch ein Update für ein allseits bekanntes Framework fertig werden, auf das ich mich ebenfalls sehr freue – das Entity Framework 6.3. Dabei handelt es sich um das klassische Entity Framework 6 (nicht das Entity Framework Core), das nun auch unter .NET Core lauffähig ist. Aus meiner Sicht ermöglicht dies einer Vielzahl von Backend-Projekten endlich, den Upgrade-Pfad auf .NET Core einzuschlagen, ohne dabei die komplette Logik für die Persistenz neu implementieren zu müssen.

Sebastian Gingter: Für mich persönlich finde ich den neuen nativen GPIO-Support für Projekte auf dem Raspberry Pi am spannendsten, weil ich in meiner Freizeit gerne damit herumspiele. Das, und dazu die Kombination mit den neuen Build-Features. Diese erlauben es, mein Projekt und alle Abhängigkeiten inklusive der .NET Core Runtime in eine einzelne ausführbare Datei zu kompilieren, und mit dem neuen Feature Ready-To-Run Image kann diese sogar noch für die Zielplattform vorkompiliert werden (Ahead-of-Time), so dass der IL-Code nicht erst auf dem schwächeren Raspberry Pi durch den JIT-Compiler laufen muss. Damit wird es super einfach, wirklich schnelle Hardwaresteuerungen für den Raspberry Pi zu entwickeln, als eine einzige Datei zu kopieren und diese direkt auf dem Gerät auszuführen.

Update auf .NET Core 3.0?

Welche Projekte profitieren deiner Einschätzung nach von .NET Core 3.0? Für wen lohnt sich das Update?

Für neue Projekte sollte .NET Core 3.0 erste Wahl sein.

Thomas Claudius Huber: Für neue Projekte sollte .NET Core 3.0 erste Wahl sein. Doch welche existierenden .NET-Framework-Projekte sollte man auf .NET Core 3.0 aktualisieren? Ich denke, insbesondere für .NET-Framework-Projekte, bei denen auch in der Zukunft neue Features geplant sind, da lohnt sich ein Update. Denn mit .NET Core 3 sind die C#-8-Sprach-Features verfügbar, es lassen sich neueste APIs verwenden, die .NET Core CLI kann bzgl. DevOps sehr hilfreich sein, und das bestehende Projekt nimmt einfach an der ganzen .NET-Core-Innovation Teil. Hat man dagegen ein .NET-Framework-Projekt, bei dem keinerlei neue Features geplant sind, ist es mit dem .NET Framework auch noch ganz gut aufgehoben.

Dr. Holger Schwichtenberg: WPF- und Windows-Forms-Projekte können nun auf .NET Core (auf Windows!) betrieben werden – mit vielen Vorteilen bei Performance und Deployment. Aber Achtung: Da es derzeit keine Migrationstools gibt, ist da einige händische Arbeit notwendig.

Jens Lorek: Die Unterstützung für Windows-Desktop-Projekte ist natürlich ein großer Schritt für die Adaption von .NET Core in der breiten Masse. Zusammen mit dem .NET Core Support für das klassische Entity Framework 6 gibt es jetzt kaum einen Grund, ein Projekt, welches noch ein langes Leben vor sich hat, nicht auf .NET Core zu heben.

Natürlich stellt sich dabei auch immer die Frage nach der Notwendigkeit. So ein größeres Update verläuft natürlich nie reibungslos. Ich habe aber schon oft erlebt, dass ein jahrelanger Update-Stau zu einem Gruselkabinett geworden ist und sich mit jedem Release, das übersprungen wird, immer größere Angst vor einem Update aufbaut. Ich persönlich halte es da ganz wie Martin Fowler es einmal gesagt hat: „If it hurts, do it more often“. Lieber öfters mal einen kleinen Update-Schmerz, als irgendwann die große, aufgezwungene Big-Bang-Migration.

Sebastian Gingter: Ich denke, dass .NET Core neben der Eignung als IoT-Plattform hauptsächlich ein Vehikel für ASP.NET Core ist. Das Web als Plattform bewegt sich unglaublich schnell, und um hier mit den modernen Technologien und Entwicklungen mitzuhalten, benötigt es auch ein Framework, das sich schnell bewegt. HTTP/2 und WebSockets, Asynchrone Streams und der neue TLS/OpenSSL Support für Linux sind ein paar Features, die man sehr einfach mit einem Upgrade von früheren (ASP).NET-Core-Versionen erhalten kann. Für Nutzer die noch das klassische Full Framework und ASP.NET einsetzen, bietet ASP.NET Core und die .NET Core Runtime viele Möglichkeiten, die vorher u.a. durch die Beschränkung auf Windows als Betriebssystem einfach nicht offen standen, wie z.B. seine Anwendung in einem leichtgewichtigen Linux-Docker-Container auszuführen.

Für den klassischen Windows-Desktop-Entwickler mit Windows Forms oder WPF sind die Vorteile nicht ganz so gravierend, da die Plattformbeschränkung bestehen bleibt. Aber auch diese können von den zum Teil gewaltigen Performanceverbesserungen der .NET Core Runtime gegenüber dem Full Framework profitieren und sich hier schon für die Zukunft mit .NET 5 positionieren.

Von .NET Framework zu .NET Core migrieren oder nicht migrieren, das ist hier (nicht die einzige) Frage!

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

C#-8- und .NET-Core-3-Workshop

mit Rainer Stropek (software architects/www.IT-Visions.de)

Azure Automation: The Good Parts

mit Adrienne Tacke (Adrienne Tacke)

Die Themen der Experten

Thomas, auf der BASTA! hältst du die Session „XAML Islands: Windows-10-Features in WPF nutzen“ Worum wird es gehen?

Thomas Claudius Huber: In der Session wird es darum gehen, wie sich WPF-, aber auch Windows-Forms-Anwendungen, modernisieren lassen. Mit XAML Islands lassen sich moderne Windows 10 Controls in die bestehende WPF- oder Windows-Forms-Applikation einbauen. So lässt sich beispielsweise problemlos die Stifteingabe von Windows 10 integrieren, oder auch das moderne MapControl zum Anzeigen einer Karte. Microsoft ist dabei, die Universal Windows Platform (UWP) von Windows zu entkoppeln und als eigenständiges, modernes Desktop Framework unter dem Namen WinUI 3.0 herauszubringen. Dies soll im Jahr 2020 passieren. Alles sieht derzeit danach aus, dass WinUI 3.0 die Zukunft für Windows-Desktop-Anwendungen ist. Mit XAML Islands können auch bestehende Desktop-Applikationen an dieser Zukunft teilzunehmen, ohne dass sie komplett neu geschrieben werden müssen.

BASTA!-Session-Tipp: XAML Islands: Windows-10-Features in WPF nutzen

Mit XAML Islands lassen sich moderne UWP Controls in WPF-, WinForms- und Win32-Applikationen einbinden. So ist es bspw. möglich, in einer WPF-App das moderne InkControl für die Windows-10-Stifteingabe zu nutzen. Oder es lassen sich Migrationsszenarien bauen, um nach und nach von WPF nach UWP zu migrieren. In dieser Session lernen Sie die Grundlagen zu XAML Islands, um Standard-UWP-Controls, aber auch ihre eigenen UWP Controls in einer WPF-Anwendungen zu hosten.

Der Desktop ist doch nicht so tot, wie viele gedacht haben.

Holger, deine Session auf der BASTA! trägt den Titel: „.NET Core 3.x und .NET 5.0: Die Wiedergeburt der Desktops-Frontends und andere Neuigkeiten.“ Kannst du uns einen kleinen Vorgeschmack geben?

Dr. Holger Schwichtenberg: Es geht um die Themen WPF und Windows Forms auf .NET Core inklusive der dazugehörenden Vorteile und des Migrationsaufwandes, die neuen Deploymentoptionen sowie SPAs mit Server Side Blazor. Ich werde auch C# 8.0 und einige neue Klassen ansprechen. Kernbotschaft: Der Desktop ist doch nicht so tot, wie viele gedacht haben. Es gibt sogar neue Features für Windows Forms (sic!), wer hätte das gedacht!

BASTA!-Session-Tipp: .NET Core 3.x und .NET 5.0: Die Wiedergeburt der Desktops-Frontends und andere Neuigkeiten.

Bisher war .NET Core nur für Server-, Web- und Konsolenentwickler interessant. Mit .NET Core 3.0 liefert Microsoft nun auch WPF und sogar Windows Forms für .NET Core, allerdings nur auf Windows. Mit dem App-Bundler von .NET Core 3.0 kann man eine Desktopanwendung zusammen mit .NET Core ausliefern, enorm verkleinern und zu einer EXE zusammenschnüren. Dann folgt .NET Core 3.1 und danach .NET 5.0 als einheitliches .NET für alle Anwendungsarten. DOTNET-DOKTOR Holger Schwichtenberg thematisiert in diesem Vortrag die vier großen Fragen: Was ist auf .NET Core 3.0 möglich? Welche Vorteile bietet .NET Core 3.0 für bestehende und neue Desktopanwendungen? Mit welchem Aufwand kann ich bestehende Anwendung auf .NET Core 3.0 umstellen? Was kommt dann mit .NET 5? Natürlich werden auch andere Neuigkeiten rund um den C# 8.0, .NET-Standard, ASP.NET Core, ASP.NET Blazor und Entity Framework Core nicht fehlen.

Jens, dein Thema auf der BASTA! ist „NuGet – Verpackt, Verteilt, Verfeinert.“ Worum wird es gehen?

Jens Lorek: Ja, die Session ist am Dienstag um 17.30 Uhr. Es wird sich alles darum drehen, wie einfach wir eigene NuGet-Pakete erstellen und anderen Leuten zugänglichen machen können – und vor allen Dingen, wann das sinnvoll ist und wann nicht. An einem konkreten Beispiel zeige ich dazu, dass der Weg zum eigenen Paket auf nuget.org in vielen Fällen nur knapp eine Minute dauert. Dazu gibt es Tipps zu nützlichen Tools, dem Aufsetzen eines eigenen NuGet Repositories und NuGet-Geschichten aus der täglichen Arbeit.

Und da sich aktuell so vieles um .NET Core dreht, zeige ich natürlich auch, welche Besonderheiten in diesem Kontext bei der Erstellung von NuGet-Paketen beachtet werden müssen. Denn ebenso wie neue Features in .NET kommen auch bei NuGet regelmäßig neue Features hinzu – und manche fallen auch wieder raus.

Im Kern soll die Session zum Nachmachen und Ausprobieren ermuntern. Denn das Thema NuGet macht mir viel Spaß und ist (meistens) keine Raketenwissenschaft. Wenn die Besucher des Talks am Ende mit dem Gedanken „Das will ich auch mal machen!“ aus dem Raum gehen, habe ich mein Ziel erreicht.

BASTA!-Session-Tipp: NuGet – Verpackt, Verteilt, Verfeinert.

NuGet-Pakete konsumiert der geübte .NET Entwickler bei seiner Arbeit täglich. Doch wie sieht es mit der Erstellung und Veröffentlichung eigener Pakete aus? Und welche Vorteile ergeben sich daraus? Nicht nur in privaten Projekten, sondern gerade im Unternehmensumfeld kann NuGet dazu beitragen in großen Projekten den Überblick zu wahren. Dazu betrachten wir an einem konkreten Beispiel, wie leicht der Wandel zum eigenen Paket Kosmos vollzogen werden kann, sowie welche Möglichkeiten sich dabei für die Erstellung und Verteilung von Paketen anbieten. Darüber hinaus ist NuGet auch ein lebendiger Teil des .NET Ökosystems, welcher unter anderem durch .NET Core und SemVer 2.0 tiefgreifende Änderungen erfahren hat. Doch was bedeutet das für unsere bisherigen Pakete? Man darf gespannt sein…

Sebastian, auf der BASTA! hältst du die Session „Advanced ASP.NET Core Web APIs: testen und dokumentieren – aber richtig!“ Was ist deine Kernbotschaft, die du vermitteln möchtest?

Sebastian Gingter: In den letzten Jahren habe ich in mehreren Projekten unter anderem auch das Thema automatisierte API-Dokumentation bearbeitet. Aus diesen habe ich die Punkte ausgewählt, die am meisten nachgefragt wurden, sowie die, die am spannendsten waren. Darüberhinaus habe ich noch zwei Themen dazu gepackt, die aufzeigen, was man, nachdem man ein klein wenig Aufwand in die automatische Dokumentation gesteckt hat, noch alles daraus herausholen kann. Also womit man in seinen Projekten wirklich Mehrwert generieren kann. Das sind alles Punkte, die wirklich Praxisbezug haben.

Bisher habe ich immer erstaunte Blicke gesehen, als ich einige dieser Sachen bei unseren Kunden vorgestellt habe: „Was? Das geht? Warum habe ich das bisher immer von Hand gemacht?“. Ich möchte aber nicht zu viel verraten, damit möglichst viele in meine Session kommen.

Meine Botschaft ist daher allgemein gehalten: Investiert ein paar Stunden mehr in die Tools, die ihr verwendet. Lernt etwas mehr darüber, als das, was auf den ersten paar Seiten der Doku steht und was nötig ist, um damit loszulegen. Ihr werdet oftmals überrascht sein, welche Benefits da zusätzlich dabei rausfallen können, und das kann Euch möglicherweise Stunden an manueller Arbeit ersparen. Der Job als Entwickler beinhaltet ja, Aufgaben zu automatisieren. Automatisiert auch mal Eure eigenen langweiligen und potentiell fehleranfälligen Aufgaben weg, und ihr habt mehr Zeit für neue, spannende Themen – und viel mehr Spaß an den mehr herausfordernden Aufgaben.

BASTA!-Session-Tipp: Advanced ASP.NET Core Web APIs: testen und dokumentieren – aber richtig!

Jeder baut Web-APIs, oder? Leider ist es nicht damit getan, ein neues Projekt zu erzeugen, ein paar Controller zu implementieren und dann sein Web-API zu deployen. Zum einen sollte es vernünftig dokumentiert werden, damit die Entwickler, die mit unserem API arbeiten müssen, auch wissen, was es kann und wie es funktioniert. Zum anderen sollten wir selber auch sicherstellen, dass unser API das tut, was es soll. In dieser Session zeigt Ihnen Sebastian Gingter, wie man diese beiden Fliegen mit einer Klappe schlagen kann. Mit Hilfe von Open API/Swagger erzeugen wir erst eine umfassende, ständig aktuelle und lebendige Dokumentation unseres APIs. Im zweiten Schritt generieren wir aus dieser Dokumentation auch gleich Tests für das API-Test-Tool Postman, die wir dann mit etwas JavaScript Testcode anreichern und diese sogar als automatisierte Integrationstests laufen lassen können. Web-APIs jenseits von Hello World, mit viel Projekterfahrung.