Erklärung des Begriffs: .NET Native

Zur Stichwortliste unseres Lexikons

Was ist .NET Native ?

".NET Native" ist ein Compiler für C#, der keine Intermediate Language, sondern direkt Maschinencode erzeugt. .NET Native kann nur bei Universal Windows Platform Apps (UWP Apps) verwendet werden.

Codename: "Project N"

Termine

Erstankündigung: 2.4.2014 (BUILD-Konferenz 2014)
Version 1.0: erschienen mit Windows 10 am 29.7.2015

Eigenschaften von .NET Native

Details zu .NET Native

UWP Apps in Windows 10 sind die erste .NET-Anwendungsart, bei der Microsoft von dem Intermediate-Language-Prinzip mit Just-in-Time-Compiler (JIT) abweicht. UWP Apps werden von dem Microsoft App Store im Sinne der Ahead-of-Time-Kompilierung (AOT) direkt in Maschinencode (Native Code) an Windows 10-Geräte ausgeliefert.

Beim Debugging in Visual Studio arbeitet der Entwickler noch mit JIT. Die "Release"-Übersetzung erzeugt dann aber bereits Maschinencode. Der Kompilierungsvorgang dauert hier sehr viel länger, was nicht nur daran liegt, dass doch erst die Microsoft Intermediate Language (MSIL) und dann daraus Maschinencode erzeugt wird, sondern vor allem daran, dass der neue Compiler mit Namen ilc.exe alle benötigten Teile der .NET Framework-Klassenbibliotheken statisch in die zu erstellende App linkt, sodass am Ende aller benötigte Programmcode in einer einzigen ausführbaren Datei liegt. In dieser Datei gibt es dann auch die tatsächlich benötigten Routinen aus der .NET-Klassenbibliothek, sodass zur Laufzeit keine DLLs mehr nachgeladen werden müssen. Außerdem erfolgt eine Nachbehandlung des erzeugten Maschinencodes mit dem Microsoft C++-Optimizer ("NUTC"). In Summe gibt es also ein einziges Executable, in dem der eigene Programmcode des Entwicklers mit dem benötigten Klassenbibliothekscode in optimierter Form vermengt ist.

Zur Laufzeit wird nicht mehr die vollständige .NET-Common Language Runtime (CLR) benötigt, sondern nur noch eine minimale Laufzeitumgebung (CoreRT, siehe [15]), die u.a. den Garbage Collector bereitstellt. Der Vorteil dieses aufwändigen Übersetzungsvorgangs sind dann zur Laufzeit der App stark reduzierte Startzeiten (Microsoft spricht von 50-60% Zeiteinsparung, je nach Quelle, vgl. [12] und [13]) sowie weniger RAM-Bedarf (14-25% je siehe vorgenannte Quellen). .NET Native ist schneller als die bisher bestehende Möglichkeit, .NET-Code nachträglich mit ngen.exe in Maschinencode zu verwandeln.

Zu beachten ist aber, dass es in .NET Native einige funktionale Einschränkungen gegenüber dem Managed Code .NET Framework gibt. Einige APIs werden bei .NET Native nicht unterstützt (siehe Liste auf [10]). Arrays dürfen nicht mehr als drei Dimensionen besitzen. Da Reflection nicht auf gewohnte Weise zur Laufzeit funktionieren kann, müssen alle Reflection-Daten vorher statisch eingebunden werden. Zur Konfiguration der Reflection-Nutzung dient die Datei Default.rd.xml. Der Entwickler kann durch die Aktivierung von "Enable static analysis for .NET Native" in den Build-Optionen des Projekts vorab Warnungen erhalten bei der Verwendung von Sprachkonstrukten und Klassen, die in .NET Native nicht verfügbar sind.

Die .NET Native-Kompilierung gibt es bislang für UWP-Apps. Microsoft arbeitet aber an einer Übertragung dieses Prinzips auf andere .NET-Anwendungsarten und hat bereits Teile von .NET Native als Open Source veröffentlicht [15].

[10] Migrating Your Windows Store App to .NET Native
msdn.microsoft.com/en-us/library/dn600634(v=vs.110).aspx#Unsupported

[12] .NET Native Website
msdn.microsoft.com/en-us/vstudio/dotnetnative.aspx

[13] Michael Samarin: Windows 10 Universal Windows Platform
spb2015.dotnext.ru/presentations/samarin.pdf

[15] CoreRT für .NET Native
github.com/dotnet/corert

Hintergründe

In der Preview-Phase war ".NET Native" ein Add-on [msdn.microsoft.com/en-US/vstudio/dotnetnative] zu Visual Studio 2013 Update 2 bzw. enthalten in Visual Studio 2015 Preview.

Nun ist .NET Native in Visual Studio 2015 enthalten und arbeitet nur für Windows 10 Universal Platform Apps.

Seit der ersten Vorstellung von .NET im Juli 2000 erzeugte der C#-Compiler immer Microsoft Intermediate Language (MSIL)-Code, der erst zur Laufzeit von einem Just-in-Time-Compiler (JIT) in Maschinencode für das jeweilige Zielsystem übersetzt wurde. Vorteil dieser "Managed Code"-Vorgehensweise ist nicht nur, dass nur ein Binärpaket für beliebige Prozessorarchitekturen verwendet werden kann, sondern auch, dass der Maschinencode für den Befehlssatz des jeweiligen Mikroprozessors optimiert werden kann. Nachteil ist aber ein Leistungsverlust, der sich insbesondere beim Anwendungsstart oft deutlich bemerkbar macht.

Microsoft hatte in den letzten Jahren immer wieder den Just-In-Time-Compiler optimiert und das Kaltstartverhalten durch verschiedene Tricks verbessert. Zu den Strategien gehört auch die "Native Code Generation" (Ngen), die den Maschinencode in einem zweiten Übersetzungsvorgang schon zur Entwicklungszeit aus der Zwischensprache gewinnt. Das betraf aber immer nur den eigenen Programmcode.

Im neuen .NET Native-Ansatz liegt aber auch das .NET Framework als optimierter nativer Code (".NET Native Framework") mit minimaler Common Language Runtime (CLR) vor; benötigte Teile des .NET Frameworks werden von einem neuen Compiler mit Namen ilc.exe statisch in die zu erstellende App gelinkt. Im Rahmen von ilc.exe kommt auch der Microsoft C++-Compiler mit den gleichen Optimierungen zum Einsatz, die auch bei C++-Programmcode angewendet werden.

Richtungswechsel

Dieser gravierende Richtungswechsel nach 14 Jahren kommt nicht überraschend; schon im Jahr 2012 hatte Microsoft im Zuge von Windows 8 mit der Einführung wieder der auf Native Code basierenden neuen Windows-Programmierschnittstelle "Windows Runtime" (WinRT) klargestellt, dass man den Leistungsverlust von Zwischensprachen nicht mehr in Kauf nehmen will. WinRT ist in C++ geschrieben, aber auch C#-Programmcode kann WinRT über eine "Language Projection" nutzen. Dabei lief auch in der Windows 8-Welt der C#-Code bisher über den Just-in-Time-Compiler. Bei .NET Native ist dieser Just-in-Time-Compiler aber nun überflüssig und es entsteht Maschinencode, der der Ausgabe des Microsoft C++-Compilers ähnelt. Das Entwicklungsteam verspricht [msdn.microsoft.com/en-US/vstudio/dotnetnative] vollmundig – im Vergleich zum Einsatz von Ngen – um 60% verringerte Startzeiten sowie einen um 15-20% verringerten Speicherbedarf. Und dabei soll auch der Verbreitungsaufwand noch gering und der Produktivitätsvorteil von C# erhalten bleiben.

Der letztere Punkt ist jedoch noch schwer zu glauben, wenn man die dokumentierten Herausforderungen der neuen .NET Native-Technik sieht. Zum einen sind zahlreiche Funktionen des .NET Frameworks nicht unterstützt [
msdn.microsoft.com/en-us/library/dn600634(v=vs.110).aspx], z.B. die SOAP-Webservice-Kommunikation über die Windows Communication Foundation (System.ServiceModel) sowie die Klassen im Namensraum System.ComponentModel.DataAnnotations. Dabei ist noch zu berücksichtigen, dass sich die Liste nicht auf das vollständige .NET Framework mit über 13.000 Klassen bezieht, sondern nur auf das sowieso schon auf wenige Tausend Klassen abgespeckte Profil ".NET for Windows Store Apps".

Funktionelle Unterschiede

Zum anderen gibt es auch funktionelle Unterschiede zwischen .NET Native und dem bisherigen .NET, da einige Teile von .NET auf der Auswertung von Metadaten basieren und Laufzeitkompilierung (z.B. die Serialisierung/Deserialisierung). Das ist in .NET Native aber nicht vorgesehen, sodass diese Informationen alle zur Entwicklungszeit erstellt werden müssen. Dabei kann laut Microsoft [msdn.microsoft.com/en-us/library/dn600640(v=vs.110).aspx] der .NET Native-Compiler nicht alle Situationen erkennen, in denen er Metadaten vorab hineinkompilieren muss. Daher ist es aktuell Aufgabe des Softwareentwicklers, dem .NET Native-Compiler über eine XML-basierte sogenannte Runtime Directives Configuration-Datei (rd.xml) Hinweise zu geben. Einige aus .NET bekannte Funktionen stehen aber gar nicht zur Verfügung. Dazu gehört insbesondere der Aufruf von privaten Klassenmitgliedern via .NET Reflection. In anderen Fällen ist durch eine Umstellung des Programmcodes eine Kompilierung in .NET Native möglich. So kann man zum Beispiel typeof(Name) statt Type.GetType("Name") verwenden.

.NET Native ist eine Weiterentwicklung der bei Windows Phone seit Version 8 eingesetzten Machine Dependent Intermediate Language (MDIL), die in der Microsoft Cloud entsteht [www.zdnet.com/microsoft-details-ist-strategy-for-compiling-windows-phone-apps-in-the-cloud-7000007185/]. Aktuell ist .NET Native auf C# beschränkt. Unterstützung für Visual Basic soll aber folgen. Native Code entsteht nicht beim Debugging, sodass dies wie bei Managed Code funktioniert. Auch die Speicherverwaltung (Garbage Collection) zur Laufzeit ist wie bei Managed Code.

Perspektive

Dass Microsoft mit Windows Apps den Umstieg auf Native Code begonnen hat, macht Sinn, weil die Arbeiten hier überschaubarer waren als beim vollständigen .NET Framework. Zudem war bei den Apps der Bedarf größer, da die Benutzer schnelle Startzeiten erwarten. Auch wenn Microsoft mit C++ und JavaScript noch zwei andere Sprachen zur Erstellung von Windows Apps anbietet, wurde bisher die deutliche Mehrheit der Windows Apps im Microsoft App Store mit den .NET-Sprachen C# oder Visual Basic erstellt.

Noch nicht konkret angekündigt oder durchaus naheliegend ist, dass .NET Native in nicht allzu ferner Zukunft auch für klassische Windows-Anwendungen mit vollständigem .NET Framework verfügbar sein wird. Dann gäbe es für alle .NET-basierten Anwendungen eine durchgehende Native Code-Strategie von dem eigenen Programmcode, über das .NET Framework bis hin zum Betriebssystem-API "WinRT".

Beratung & Support

Schulungen

Anfrage für eine individuelle Schulung zum Thema .NET NATIVE Gesamter Schulungsthemenkatalog

Fachbücher

Alle unsere aktuellen Fachbücher E-Book-Abo für ab 99 Euro im Jahr