Die wichtigsten Neuerungen von .NET 4.5.1, Visual Studio 2013 und TFS 2013

Microsoft forciert die kürzeren Produktzyklen: .NET Framework 4.5 und Visual Studio 2012 sind noch kein Jahr alt, da lieferte der Konzern zur diesjährigen BUILD-Konferenz schon Previews für neue Releases von .NET, Visual Studio und Team Foundation Server. Die fertigen Produkte sollen noch dieses Jahr erscheinen.

In Pocket speichern vorlesen Druckansicht 5 Kommentare lesen
Lesezeit: 22 Min.
Von
  • Dr. Holger Schwichtenberg
Inhaltsverzeichnis

Microsoft forciert die kürzeren Produktzyklen: .NET Framework 4.5 und Visual Studio 2012 sind noch kein Jahr alt, da lieferte der Konzern zur diesjährigen BUILD-Konferenz schon Previews für neue Releases von .NET, Visual Studio und Team Foundation Server. Die fertigen Produkte sollen noch dieses Jahr erscheinen.

Wie das .NET Framework 4.5 ist .NET 4.5.1 ein "in-place update". Das soll heißen: Das Installationspaket ergänzt ein vorhandenes .NET 4.0 oder 4.5 und ändert einige Interna. Die Versionsnummer aller Assemblies bleibt aber an den ersten drei Stellen weiterhin gleich (4.0.30319). Lediglich an der vierten Stelle kann man .NET 4.5.1 vom Vorgänger unterscheiden (siehe Tabelle 1). .NET 4.5.1 wird mit Windows 8.1 mitgeliefert und ist für die gleichen Plattformen (also ab Windows Vista bzw. Windows Server 2008) verfügbar. Die letzte Hoffnung einiger Windows-XP-Veteranen, auch in den Genuss von .NET 4.5 zu kommen, ist damit wohl gestorben. Denn die Preview gibt es als eigenständigen Download oder als automatisch installierten Teil der Previews von Windows 8.1, Windows Server 2012 und Visual Studio 2013. Auch Language Packs bietet Microsoft wieder an.

.NET-Version 4.5 4.5.1
Status RTM-Version August 2012 Preview Juni 2013
DLL-Versionen 4.0.30319.17929 4.0.30319.32559
Anzahl der Dateien im .NET-Framework-Verzeichnis 574 575

Bei Betrachtung des .NET-Installationsverzeichnisses stellt man fest, dass alle bisher in .NET 4.5 vorhandenen Dateien in .NET 4.5.1 zu finden sind. Lediglich eine ist hinzugekommen: System.Threading.Timer.dll. Diese ist aber keine neue Bibliothek, sondern soll wohl dazu dienen, zwei bisher in mscorlib.dll beheimatete Klassen auszulagern: Timer und TimerCallback. Ein Blick in die DLL mit ILSpy offenbart aber, dass dort derzeit nur ein Type Forward hinterlegt ist.

Eine weitere forensische Analyse von .NET 4.5.1 zeigt: Es gibt im Kern keine neuen Klassen. Alle Änderungen betreffen Interna der Implementierung von Laufzeitumgebung und Bibliotheken. Neue Klassen gibt es nur in Zusatzbibliotheken wie Entity Framework 6.0 und ASP.NET Identity 1.0.

In der derzeitigen Version der .NET-Dokumentation im Microsoft Developer Network ist die Darstellung etwas unglücklich, weil die Webseite nicht zwischen .NET 4.5 und .NET 4.5.1 differenziert. So erscheint die Property LargeObjectHeapCompactionMode in der Klasse System.Runtime.GCSettings unter ".NET Framework 4.5" (s. Abb. 1), obwohl sie neu in .NET 4.5.1 ist. Ein Hinweis auf das dazu notwendige Update fehlt auf der Seite. Immerhin wird im Dokument "What's New in the .NET Framework 4.5" auf einige neue Features der Version 4.5.1 hingewiesen.

In der MSDN-Dokumentation unterscheidet Microsoft leider nicht zwischen .NET 4.5 und .NET 4.5.1 (Abb. 1)

Ein wesentliches neues Feature ist die Wiederaufnahme abgebrochener Datenbankverbindungen in ADO.NET. Bisher mussten sich Entwickler selbst darum kümmern, dass eine wegen fehlender Netzwerkverbindung, Load Balancing oder Failover auf Serverseite unterbrochene Verbindung wieder neu aufgebaut wird. In .NET 4.5.1 hat Microsoft dazu ein Feature namens "ADO.NET Connection Resiliency" integriert, das dafür sorgt, dass im Fall des Abbruchs einer momentan ungenutzten Verbindung diese bei der nächsten Anforderung wieder aufgebaut wird, ohne dass im Programmcode dazu etwas zu tun ist. Von diesem Feature profitieren automatisch alle auf ADO.NET aufbauenden Datenzugriffs-Frameworks und objektrelationalen Mapper wie das Entity Framework. Weiterhin kommt es aber zum Laufzeitfehler in der Anwendung, wenn während einer Datenbankoperation ein Verbindungsabbruch geschieht. Das ist auch sinnvoll, da hier mannigfaltige Möglichkeiten existieren, je nachdem wie weit die Operation fortgeschritten ist und an welcher Stelle weiterzuarbeiten ist.

Auch im Bereich ASP.NET geht es um die Wiederaufnahme, hier allerdings gibt es in .NET 4.5.1 in Verbindung mit Windows Server 2012 Release 2 nun einen gewollten "Schlummermodus" (ASP.NET Application Suspension) für Websites, die keine HTTP-Anfragen erhalten. Die Version 8.5 der Internet Information Services (IIS) in Windows Server 2012 Release 2 erlaubt unter dem Begriff "Idle Worker Process Page-out" das Einstellen eines Zeitraums ohne Anfragen, nach dessen Ablauf sich alle ASP.NET-Websites in einem Application Pool in das Windows Page File auslagern lassen. Microsoft hat dieses Verfahren für das Hosting von Websites in Windows Azure entwickelt und es nun in den Windows Server portiert. Nach Microsofts Messungen kann ein Webserver damit bis zu sieben Mal mehr Websites hosten, und die Startzeit von Websites reduziert sich um bis zu 90 Prozent. Die Messdaten basieren auf einem Server mit 20 GByte RAM und SDD-Platten für die Auslagerungsdatei.

Microsoft hat in .NET 4.5.1 die Zusammenarbeit mit der in Windows 8 eingeführten, COM-basierten Windows Runtime Library (WinRT) zur Entwicklung von Apps verbessert. In Windows 8.1 sieht der Entwickler in Laufzeitfehlerobjekten wieder häufiger eine sprechende Fehlermeldung statt der kryptischen HResult-Hexadezimalzahlen. Auch XML-Kommentartexte sind bei WinRT-Projekten nun sprachübergreifend in der Entwicklungsumgebung als Tooltip sichtbar. Die Programmierung im Bereich Netzwerk und Dateisystem hat der Konzern vereinfacht: Die neue Erweiterungsmethode AsRandomAccessStream() konvertiert einen .NET-Stream in das WinRT-Pendant, den Random Access Stream. Last, but not least können WinRT-Softwarekomponenten nun auch wertelose Wertetypen (Nullable Value Types) in structs haben.

Der Konzern hat in diesem Update abermals einige Überarbeitungen am Kern des .NET Framework, der Common Language Runtime (CLR), vorgenommen, um Leistung und Debugging zu verbessern. Ein von einigen Entwicklern nachgefragtes Thema war mehr Kontrolle über die Garbage Collection. Entwickler können nun dem Garbage Collector befehlen, entweder unverzüglich oder beim nächsten automatischen Lauf, den sogenannten Large Objects Heap (LOH) für Objekte mit einer Größe von mehr als 85.000 Bytes (vgl. hier) zu defragmentieren:

GCSettings.LOHCompactionMode = GCLOHCompationMode.CompactOnce;
GC.Collect();

Bisher entschied der Garbage Collector allein über Maßnahmen im LOH. Auch der Just-in-Time-Compiler hat abermals Verbesserungen erfahren. Die in .NET 4.5 eingeführte Multicore-JIT-Technik gilt jetzt in .NET 4.5.1 auch für ASP.NET-Websites sowie für dynamisch geladene Assemblies.

Ebenfalls verbessert hat Microsoft die Ausführungsdauer der nach einem Patch von .NET-Kern-DLLs notwendigen "Native Image Generation". Bisher konnte ein per Windows-Update eingespielter Fix die Startzeit von .NET-Anwendungen für eine Weile verlangsamen. Dieser Seiteneffekt soll nun auf Windows 8.1 nicht mehr so gravierend sein. Es bleibt zu wünschen, dass es diese Optimierung auch für andere Betriebssysteme geben wird.