Zum programm

Das .NET-Kern-Update

Auch wenn die Core-Produkte bereits in der Version 1.0 schon in vielen Fällen schneller liefen als die Vorgänger aus der .NET-„Full“-Framework-Ära, arbeitet Microsoft weiterhin an der Performance. In .NET Core 1.1 setzt Microsoft nun auch auf die Profile-guided Optimization (PGO). Hierbei wird im Zug des Ablaufs von Musteranwendungen die Reihenfolge der tatsächlichen Nutzung des Programmcodes in der CLR und den Bibliotheken aufgezeichnet. Auf Basis dieser Messdaten optimiert Microsoft dann die Reihenfolge des Programmcodes im Kompilat. In .NET Core 1.1 hat Microsoft laut .NET Blog lediglich eine einfache „Hello World“-Anwendung für die Datenaufzeichnung verwendet, damit dann allerdings schon eine 15-prozentige Leistungssteigerung bei der ASP.NET-Core-Beispielanwendung MusicStore erzielt. Angesichts dieses Resultats kann man die Hoffnung haben, dass Microsoft in Zukunft auf Basis von Messdaten aus echten .NET-Core-Anwendungen noch mehr aus diesem Optimierungsverfahren herausholen wird.

Dass die Leistung von .NET Core in Version 1.1 besser ist als bei Version 1.0, beweist auch der zehnte Platz im Vergleich mit anderen Webframeworks in der dreizehnten Ausgabe des TechEmpower-Webserverframework-Performanztests. Allerdings wurde dieser Platz mit einer Webanwendung erzielt, die kein HTML, sondern „Plain Text“ mit ASP.NET Core ohne das MVC-Framework erzeugt, und auf Linux. Beim Generieren der Ausgabe mit dem MVC-Framework rutscht ASP.NET Core in der Leistung demgegenüber auf den 29. Platz ab. Allerdings rangiert es damit dann zwar hinter Java Servlets, jedoch immer noch vor Node.js und deutlich vor PHP.

Abb. 1: ASP.NET Core 1.1 im Vergleich zu Java Servlets, Node.js, Node.js mit Express und PHP (Quelle: Microsoft Connect(); 2016)

.NET Core für mehr Betriebssysteme

Zu den bisher unterstützten Versionen von Windows, Linux und Mac kommen bei den Betriebssystemen mit Core 1.1 nun hinzu:

• Windows Server 2016
• Linux Mint 18
• OpenSUSE 42.1
• macOS 10.12
• auf Linux basierendes Betriebssystem Tizen

.NET Core für Tizen (Abb. 2) wird dabei von Samsung entwickelt. Die „Visual Studio Tools for Tizen“ nutzen hier Xamarin.Forms für Benutzeroberflächen. Laut Tizen Developers Blog wird in der ersten Preview der Visual Studio Tools für Tizen bereits „99 % von Xamarin.Forms“ unterstützt. Das ist insofern bemerkenswert, als damit der Schritt, Xamarin.Forms auch für Benutzeroberflächen auf Linux anzubieten, sehr nahe liegt. Auch könnte .NET Core bald Mono als Basis für Xamarin.Forms in iOS, Android und Windows 10 ablösen.

Mehr APIs

Nicht viel versprechen sollte man sich allerdings von den „1 380 zusätzlichen APIs“, die Microsoft laut Blogeintrag in .NET Core 1.1 ergänzt hat. Mit APIs sind nicht komplette Bibliotheken gemeint, vielmehr hat Microsoft dabei jede neue Klasse und jedes neue Klassenmitglied einzeln gezählt. Beim Blick in die Liste der API-Neuerungen findet der Entwickler leider auch wenig, was er typischerweise braucht. Die Ergänzungen betreffen fast ausschließlich interne Funktionen von .NET Core bzw. dienen der Unterstützung für die Version 7.0 der Programmiersprache C#. Die .NET Standard Library ändert den Versionsstand daher auch nur leicht von 1.6 auf 1.6.1. Die unter dem Slogan „One library to rule them all“ groß angekündigte Angleichung an die Programmierschnittstellen der Base Class Library des großen .NET Framework 4.6 wird leider erst im Jahr 2017 im Rahmen der .NET Standard Library 2.0 erfolgen.

Core-Werkzeuge bleiben unfertig

Ebenfalls noch nicht am Ziel ist Microsoft bei den .NET-Core-Werkzeugen. Alle Tools, einschließlich der Visual-Studio-Integration, bleiben vorerst weiterhin im Preview-Stadium. Die Version des SDK ändert sich nur leicht im Vergleich mit der bisherigen Version „1.0 Preview 2“ (für .NET Core 1.0) auf „1.0 Preview 2.1“ (für .NET Core 1.1). Die aktuelle Installationsdatei des SDK heißt dotnet-dev-win-x64.1.0.0-preview2-1-003177.exe bzw. dotnet-dev-win-x86.1.0.0-preview2-1-003177.exe. Dabei darf man sich von der „1.0“ im Dateinamen nicht verwirren lassen: Dies ist die Versionsnummer des SDK, nicht von .NET Core. Wenn man sich die Dateieigenschaften ansieht, liest man dort unter dem Punkt Description: „Microsoft .NET Core 1.1.0 – SDK 1.0.0 Preview 2.1-003177 (x64)“ (Abb. 2).

Abb. 2: Der Dateiname der SDK-Version zeigt nicht, auf welche .NET-Core-Version sie sich bezieht; das sieht man erst in den erweiterten Dateieigenschaften

Erschwerend kommt noch hinzu, dass Microsoft die Visual-Studio-2015-Werkzeuge nicht aktualisiert hat. So erzeugt Visual Studio 2015 beim Anlegen neuer Projekte auch nach der Installation des SDK also immer .NET-Core-1.0-Projekte. Hier muss der Entwickler dann stets die global.json (ändern der Versionszeichenkette auf „1.0.0-preview2-1-003177“) sowie die project.json (ändern der Version von Microsoft.NETCore.App auf „1.1.0“) manuell anpassen. Auch beim Anlegen neuer .NET-Core-1.1-Projekte mit dem Kommandozeilentool dotnet-new gibt es Probleme. Dazu sei auf [9] verwiesen.

Im Rahmen von Visual Studio 2017 Release Candidate, das bisher Visual Studio “15” hieß, kommt hingegen bereits die Preview-3-Version des SDK zum Einsatz, die – wie von Microsoft angekündigt – nicht mehr auf .xproj– und project.json-Dateien basiert, sondern eine neue Version der XML-basierten MSBuild-Dateien (.csproj) verwendet. Bestehende .xproj– und project.json-Dateien konvertiert Visual Studio 2017 beim Öffnen des Projekts in .csproj-Dateien. Der Entwickler muss jedoch bedenken, dass es keine Option zur Rückkonvertierung gibt, falls er später dann doch mit dem JSON-Format oder Visual Studio 2015 weiterarbeiten möchte. Microsoft spricht in diesem Zusammenhang von der „Alphaversion“ der MSBuild-based .NET-Core-Tools, die Teil des .NET Core SDK 1.0 Preview 3 sind und auf .NET Core 1.1 RTM basieren. Auch im neuen Visual Studio for Mac, das als Preview erschienen ist und eine erweiterte Version des bisherigen Xamarin Studio darstellt, kann der Entwickler mit .NET Core 1.1 und dem Preview 3 des SDK arbeiten.

Entity Framework Core 1.1

Bei Entity Framework Core 1.1 hat Microsoft einige Funktionen nachgerüstet, die es im Vorgänger ADO.NET Entity Framework zum Teil schon lange gibt, die jedoch zur 1.0-Version von Core noch nicht fertig waren:

• Die Methode Find() in der Klasse DbSet<T> lädt ein Objekt anhand der Primärschlüsselwerte. Find() hat die besondere Verhaltensweise, dass es nach einem Objekt zuerst im First-Level-Cache des Entity-Framework-Core-Kontexts sucht und nur dann eine Datenbankabfrage startet, wenn das Objekt dort nicht enthalten ist.
• Neben dem Eager Loading und dem Pre-Loading verbundener Datensätze bietet Entity Framework Core 1.1 nun auch wieder ein explizites Laden über die Klasse EntityEntry<T> an, z. B. ctx.Entry(flug).Reference(x => x.Flugzeugtyp).Load() bzw. ctx.Entry(flug).Collection(x => x.Buchungen).Load().
• Zur vereinfachten Implementierung von Undo-Funktionen und Konfliktlösung gibt es nun wieder die Methoden Reload() und GetDatabaseValues().
• Die Wiederaufnahme abgebrochener Datenbankverbindungen (Connection Resiliency) zum Microsoft SQL Server oder SQL Azure ist ebenfalls wieder möglich.

Darüber hinaus gibt es neue Features zum Mapping von Fields auf Tabellenspalten mit HasField(“name”) sowie dem Mapping auf speicheroptimierten Tabellen von Microsoft SQL Server (ab Version 2014) mit ForSqlServerIsMemoryOptimized() – jeweils anzuwenden im Fluent-API bei OnModelCreating().

ASP.NET Core 1.1

Auch in ASP.NET Core hat Microsoft fehlende Funktionen nachgerüstet. Im Gegensatz zu den Nachrüstarbeiten bei Entity Framework Core hat Microsoft jedoch bei ASP.NET Core in dem aus Version 1.0 bekannten Stil die APIs radikal geändert:

• Für das URL Rewriting – wahlweise mit serverseitigem Umlenken oder clientseitigen Redirect – gibt es die neue Komponente AspNetCore.Rewrite mit der Klasse RewriteOptions mit den Methoden AddRedirect(), AddRewrite(), AddRedirectToHttps(), AddRedirectToHttpsPermanent(), AddIISUrlRewrite() und AddApacheModRewrite().
• Zur Geschwindigkeitsoptimierung kann man HTTP-Antworten nun wieder komprimieren (Paket AspNetCore.ResponseCompression) oder zwischenspeichern (Paket Microsoft.AspNetCore.ResponseCaching).
• Mit dem WebListener-Server (Paket Net.Http.Server) für das Hosting bietet Microsoft jetzt eine Alternative zu Kestrel an. Der WebListener ist ein eigenständiger Webserver, der sich nicht in den IIS oder IISExpress integriert. Er basiert auf dem Windows-HTTP-Server-API und dem Http.Sys-Kernel-Mode-Treiber und bietet Windows-spezifische Verfahren zur Windows-Authentifizierung, zum Port Sharing sowie Caching. Mit dem WebListener-Server läuft die ASP.NET-Core-Anwendung jedoch nicht mehr auf Linux und macOS, sondern allein noch auf Windows 7/Windows Server 2008 R2 und höher.
• In ASP.NET Core 1.0 hatte Microsoft View Components und Tag Helper zur Wiederverwendung von Markup und Logik eingeführt. In Version 1.1 gibt es nun eine Integration beider Konzepte: Während eine View Component bisher immer per InvokeAsync(“viewcomponentname”) in eine View einzubinden war, kann der Entwickler dies nun über einen Tag Helper (<viewcomponentname>…</viewcomponentname>) auch eleganter vornehmen.
• Die Kernfunktionen von ASP.NET Core bildet der Entwickler in der Startup-Klasse durch eine Aneinanderreihung von Middleware-Komponenten. Die in ASP.NET Core 1.1 eingeführte neue Annotation [MiddlewareFilter] erlaubt nun, auch Middleware-Komponenten auf einzelne Controller oder Actions zu beschränken, z. B. die HtmlMinificationMiddleware mit [MiddlewareFilter(typeof(HtmlMinificationPipeline))].
• Die neue Komponente AspNetCore.AzureAppServicesIntegration speichert alle von den Logger-Objekten erzeugten Nachrichten in Microsofts Cloud.
• Mit den drei Paketen AspNetCore.DataProtection.Redis, Microsoft.AspNetCore.DataProtection.AzureStorage und Microsoft.Extensions.Configuration.AzureKeyVaultkann der Entwickler sensible Informationen, wie kryptografische Schlüssel in Redis oder Microsoft Azure, verwalten.
• Der CookieTempDataProvider (Paket AspNetCore.Mvc.ViewFeatures) ermöglicht es, in dem TempData-Objekt gespeicherte Daten nun auch per Cookie auf dem Client zu speichern.

Zu beachten ist, dass einige der ergänzten Komponenten (z. B. Microsoft.AspNetCore.Rewrite, Microsoft.AspNetCore.ResponseCompression) die Versionszählung bei 1.0 beginnen, auch wenn Sie im Rahmen von .NET Core 1.1 erstmals erschienen sind, während andere wie Microsoft.AspNetCore.ResponseCaching mit 1.1.0 starten. Vom Paket Microsoft.Net.Http.Server gibt es die Versionen 1.0 und 1.1.

Fazit

Für das erste Release hinter dem Komma hat die Core-Familie in der Version 1.1 einiges zu bieten. Besonders spannend finde ich persönlich aber .NET Core für Tizen mit Xamarin.Forms. Diese Entwicklung gibt Hoffnung, dass Microsoft oder ein anderes Mitglied der .NET Foundation Xamarin.Forms zum vollwertigen UI-Framework für .NET Core ausbaut. In Visual Studio 2017 gibt es immerhin schon einmal eine grafische Preview-Funktion für Xamarin.Forms (jedoch noch keinen Drag-and-Drop-Designer).