Erklärung des Begriffs: .NET Native

".NET Native" ist ein neuer Compiler für C#, der keine Intermediate Language, sondern direkt Maschinencode erzeugt. Microsoft rückt damit noch einen Schritt weiter von seiner Zwischensprache und der Just-in-Time-Kompilierung ab. Seit dem 12.11.2014 gehört .NET Native offiziell zu .NET Core 5.0 und damit zu .NET 2015.

Codename: "Project N"
Erstankündigung: 2.4.2014 (BUILD Konferenz 2014)
Version 1.0: erschienen mit Windows 10 am 29.7.2015

UWP Apps in Windows 10 sind auch die erste .NET-Anwendungsart, bei 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 Machinencode (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 Machinencode. Der Kompilierungsvorgang dauert hier sehr viel länger, was nicht nur daran liegt, dass doch erst dem Microsoft Intermediate Language (MSIL) und dann daraus Machinencode erzeugt wird, sondern vor allem daran, dass der neue Compiler mit Namen mit Namen ilc.exe alle benötigte Teile der .NET Framework-Klassenbibliotheken statisch in die zu erstellende App linkt, sodass am Ende aller benötigter Programmcode in einer einzigen ausführbaren Datei liegt. In dieser Datei gibt es dann auch die tatsächlichen benötigten Routinen aus der .NET-Klassenbibliothek, sodass zur Laufzeit kein DLLs mehr nachgeladen werden müssen. Außerdem erfolgt eine Nachbehandlung des erzeugten Machinencodes mit dem Microsoft C++-Optimizer ("NUTC"), siehe Abbildung 5. In Summe gibt es also ein einziges Executable, indem 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 Übersetzungsvorgang 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 Machinencode 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
https://msdn.microsoft.com/en-us/library/dn600634(v=vs.110).aspx#Unsupported

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

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

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





Hintergründe

---

In der Preview-Phase war ".NET Native" ist ein Add-on [http://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 Unievrsal 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 dem 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 [http://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 [
http://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 die 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 Teil von .NET auf der Auswertung von Metadatenbasieren 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 [http://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 Aufgabe aktuell 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 [http://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 durchgehend Native Code-Strategie von dem eigenen Programmcode, über das .NET Framework bis hin zum Betriebssystem-API "WinRT.