Dreieinhalb Monate nach der ersten Release-Version hat Microsoft nun eine erste funktionale Erweiterung für seine aus .NET Core, ASP.NET Core und Entity Framework Core bestehende neue .NET-Generation veröffentlicht.

Auf der Entwicklerkonferenz connect(); hat Microsoft .NET Core 1.1 vorgestellt und holt dabei neue Plattformen an Bord: Mit dem Release kommen Linux Mint 18, OpenSUSE 42.1, macOS 10.12 und Windows Server 2016 hinzu. Samsung liefert künftig auch .NET Core für Tizen.

Die neue Version 1380 bietet zusätzliche APIs, erläutert Microsoft. Damit sind aber nicht komplette Bibliotheken gemeint, sondern die Redmonder haben jede neue Klasse und jedes neue Klassenmitglied einzeln gezählt. Beim Blick in die Liste der API-Neuerungen finden Entwickler dann auch wenig, was sie typischerweise brauchen. Die meisten Ergänzungen betreffen interne Funktionen von .NET Core oder dienen der Unterstützung für die Version 7.0 der Programmiersprache C#. Die .NET Standard Library ändert den Versionsstand daher auch nur von 1.6 auf 1.6.1. Die von Microsoft 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 soll erst im Jahr 2017 im Rahmen der .NET Standard Library 2.0 erfolgen.

Performancesteigerung in ASP.NET Core

Eine Performancesteigerung von Webanwendungen von rund 15 Prozent wollen die Macher durch Verwendung der Profile Guided Optimization (PGO) erreicht haben, die auch beim großen .NET Framework zum Einsatz kommt. Durch Aufzeichnung der tatsächlichen Nutzung des Programmcodes wird dessen Reihenfolge im Kompilat optimiert.

In der dreizehnten Ausgabe des TechEmpower-Webserverframework-Performanztest ist ASP.NET 1.1 bereits berücksichtigt und belegt dort den zehnten Platz in der „Plain Text“-Auswertung. Allerdings wird dabei ASP.NET Core auf Linux und ohne das MVC-Framework eingesetzt. Mit dem MVC-Framework rutscht ASP.NET Core in der Leistung auf den 29. Platz ab.

Quelle: Techempower

Nachgerüstete Funktionen

In ASP.NET Core hat Microsoft bisher fehlende Funktionen zum Umlenken von HTTP-Anfragen (URL Rewriting) ergänzt. Entwickler können nun in der Startup-Klasse mit regulären Ausdrücken, der XML-Syntax der Internet Information Services (IIS) oder der Mod_Rewrite-Syntax des Apache-Webservers Umlenkungen definieren. Auch eine Funktion zum Umlenken aller HTTP-Anfragen auf HTTPS ist realisiert.

Das frühere ASP.NET hatte einen Output Cache, der gerenderte Webseiten für eine definierbare Zeit zwischengespeichert hat. In ASP.NET Core 1.1 füllt diese in der Juli-Version noch bestehende Lücke das Paket Microsoft.AspNetCore.ResponseCaching in Verbindung mit dem Memory Cache (Microsoft.Extensions.Caching.Memory). Das Paket Microsoft.AspNetCore.ResponseCompression ermöglicht eine ZIP-Komprimierung der HTTP-Datenströme. Die Views, die in ASP.NET Core 1.0 immer zur Laufzeit kompiliert wurden, lassen sich nun zur Entwicklungszeit vorkompilieren.

Mehr Auswahl

ASP.NET-Core-Webanwendungen laufen immer in einem eigenständigen Prozess. Als Prozess-Host bietet Microsoft dafür in Version 1.1 neben Krestrel mit dem WebListener-Server eine Alternative an, die auf Basis des Windows-eigenen HTTP Server API auch Windows-spezifische Verfahren zur Authentifizierung, zum Port Sharing und Caching an Bord hat. Die Verwendung des Pakets Microsoft.AspNetCore.Server.WebListener zerstört jedoch die Plattformunabhängigkeit einer ASP.NET-Core-Anwendung.

Mit ASP.NET Core hat 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 über den Befehl Component.InvokeAsync(„viewcomponentname“) in eine View einzubinden war, erledigt den Job nun eleganter ein Tag Helper (<viewcomponentname>…</viewcomponentname>).

Die Kernfunktionen von ASP.NET Core bilden Entwickler in der Startup-Klasse durch eine Aneinanderreihung von Middleware-Komponenten. Mit der Annotation [MiddlewareFilter]lassen sich nun auch Middleware-Komponenten auf einzelne Controller oder Actions beschränken. Die neue Komponente Microsoft.AspNetCore.AzureAppServicesIntegrationspeichert alle von den Logger-Objekten erzeugten Nachrichten in Microsofts Cloud. Mit den Paketen Microsoft.AspNetCore.DataProtection.Redis, Microsoft.AspNetCore.DataProtection.AzureStorage und Microsoft.Extensions.Configuration.AzureKeyVault können Entwickler sensible Informationen wie kryptografische Schlüssel in Redis oder Microsoft Azure nutzen. Im TempData-Objekt gespeicherte Daten lassen sich nun auch per Cookie auf dem Client speichern.

Entity Framework Core 1.1

Auch für den Objekt-Relationalen Mapper Entity Framework ist eine erweiterte Version 1.1 erschienen. Hier bringt Microsoft einige Programmierfunktionen aus dem Vorgänger Entity Framework 6.1 zurück, die in Entity Framework Core 1.0 fehlten. Dazu gehört die Suche nach Objekten im Cache mit Find(), das explizite Nachladen verbundener Objekte mit Load(), das erneute Laden bereits geladener Objekte mit Reload() sowie die einfache Abfrage des alter und neuer Objektinhalte mit GetDatabaseValues() und GetModifiedProperties().

Auch das Mapping auf einfache Fields anstelle von Properties und die Wiederaufnahme abgebrochener Datenbankverbindungen (Connection Resiliency) zum Microsoft SQL Server oder SQL Azure ist wieder möglich. Ganz neu ist die Möglichkeit, Objekte auch auf die speicheroptimierten Tabellen von Microsoft SQL Server 2016 abzubilden. Außerdem haben die Macher die API vereinfacht, mit der sich Standardfunktionen von Entity Framework Core durch eigene Implementierungen ersetzen lassen.

Core-Werkzeuge bleiben unfertig

Auch mit der Version 1.1 der Core-Produkte bleiben alle Werkzeuge einschließlich der Visual Studio-Integration weiterhin im Preview-Stadium. Microsoft hatte angekündigt, von den JSON-basierten Konfigurationsdateien zu MSBuild zurückzukehren – allerdings mit einem vereinfachtem XML-Format.

Für das entsprechende Projektformat existiert nun eine erste Alpha-Version in Verbindung mit Visual Studio 2017, Visual Studio Code und dem neuen Visual Studio for Mac. Bestehende project.json-Dateien können Entwickler in .csproj-Dateien konvertieren, müssen jedoch bedenken, dass es keine Option zur Rückkonvertierung gibt, falls sie später doch mit dem JSON-Format oder Visual Studio 2015 weiterarbeiten möchten.