Sie sind hier:
Startseite
|
Wissen
Top-Know-how seit 25 Jahren!
Telefon (Mo-Fr 10 bis 16 Uhr): +49 (0) 201/649590-0 |
Kontaktformular
Webinare 100% virusfrei!
MENU
Medien
Übersicht
Lexikon/Glossar
Weblog
Konferenzvorträge
Fachbücher
Fachartikel
Leserportal
Autoren gesucht!
Literaturtipps
Downloads
Newsletter
.NET
Startseite
.NET 5.0
.NET Core
.NET 4.0/4.5.x/4.6.x
.NET 3.0/3.5
.NET 2.0
.NET-Lexikon
Programmiersprachen
Entwicklerwerkzeuge
Klassenreferenz
Softwarekomponenten
Windows Runtime
World Wide Wings-Demo
Versionsgeschichte
Codebeispiele
ASP.NET
Artikel
Bücher
Schulung & Beratung
ASP.NET
Startseite
Lexikon
Sicherheit
Konfiguration
Global.asax
Tracing
Technische Beiträge
Klassenreferenz
Programmiersprachen
Entwicklerwerkzeuge
Softwarekomponenten
Forum
Schulung & Beratung
PowerShell
Startseite
Commandlet-Referenz
Codebeispiele
Commandlet Extensions
Versionsgeschichte
Schulungen+Beratung
Windows
Startseite
Windows Runtime (WinRT)
Windows PowerShell
Windows Scripting
Windows-Schulungen
Windows-Lexikon
Windows-Forum
Scripting
Startseite
Lexikon
FAQ
Buecher
Architektur
Skriptsprachen
Scripting-Hosts
Scripting-Komponenten
COM/DCOM/COM+
ADSI
WMI
WMI-Klassenreferenz
Scripting-Tools
WSH-Editoren
Codebeispiele
.NET-Scripting
Forum
Schulung & Beratung
Nutzer
Anmeldung/Login
Buchleser-Registrierung
Gast-Registrierung
Hilfe
Website-FAQ
Technischer Support
Site Map
Tag Cloud
Suche
Kontakt
Erklärung des Begriffs: .NET Native
Zur Stichwortliste unseres Lexikons
Was ist
.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
(
MSI
L) 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
DLL
s mehr nachgeladen werden müssen. Außerdem erfolgt eine Nachbehandlung des erzeugten Machinencodes mit dem Microsoft C++-Optimizer ("N
UTC
"), 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
API
s 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
(
MSI
L)-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
SOA
P-
Webservice
-Kommunikation über die
Windows Communication Foundation
(System.ServiceModel) sowie die Klassen im Namensraum
System.ComponentModel
.Data
Annotation
s. 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 App
s".
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
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 [
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
(
MDI
L), 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 App
s 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 App
s anbietet, wurde bisher die deutliche Mehrheit der
Windows App
s im Microsoft App Store mit den
.NET-Sprache
n 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
.
Querverweise zu anderen Begriffen im Lexikon
Machine Dependent Intermediate Language
MDIL
API
Windows Communication Foundation
Microsoft Intermediate Language
MSIL
UWP App
SOA
.NET for Windows Store Apps
UTC
MDI
Universal Windows Platform
UWP
XML
BUILD
AOT
Common Language Runtime
CLR
System.ComponentModel
Just-in-Time-Compiler
DLL
MSI
Language Projection
.NET Core
Visual Studio 2013
Visual Studio 2015
Garbage Collector
Windows Store App
Deserialisierung
Windows Runtime
WinRT
Serialisierung
.NET-Sprache
Managed Code
Native Code
ctor
Windows App
Reflection
Annotation
Webservice
Windows 10
JavaScript
Projection
Executable
.NET 2015
C++
Metadaten
Debugging
.NET Core
Windows 8
Compiler
CoreRT
Liste
Java
Beratung & Support:
Anfrage für Beratung/Consulting zu Thema .NET Native;
Gesamter Beratungsthemenkatalog
Technischer Support zum Thema .NET Native;
Schulungen zu diesem Thema:
Universal Windows Platform (UWP) Apps entwickeln (Windows 10 Apps erstellen)
Umstieg auf .NET 5.0: Komplettes Wissen inkl. ASP.NET Core und Entity Framework Core (Umstellung/Migration von .NET Framework zu .NET 5.0)
Anfrage für eine individuelle Schulung zum Thema .NET Native;
Gesamter Schulungsthemenkatalog
Bücher zu diesem Thema:
Alle unsere aktuellen Fachbücher