.NET Native & UWP = Dreamteam

.NET Native und die Bedeutung für Universal-Windows-Platform-Entwickler
Kommentare

Mit .NET Native wird C# zu systemeigenem Computercode kompiliert, der wie C++ funktioniert. Windows-Store-Apps sollen so eine wesentlich bessere Leistung und Performance erzielen. Die Codebasis aller Apps, die für die Universal Windows Platform (UWP) entwickelt werden, muss dank .NET Native nur einmal geschrieben werden, da das Framework auf allen Devices unter Windows 10 läuft. Doch wie beeinflusst .NET Native die Arbeitsweise von UWP-Entwicklern und deren Apps?

Bereits seit Ende Juli ist die aktuelle Version des .NET Native Compilers tiefer in Visual Studio 2015 eingebunden und steht für die Erstellung von UWP-Apps für Windows 10 zur Verfügung. Die .NET Native Toolchain kompiliert managed IL-Binaries zu nativen Binaries, sodass alle Apps in nativen Code umgewandelt werden, bevor sie auf einem Device laufen. Daniel Jacobsen, Programm-Manager bei Windows, erklärt im Windows-Blog, welche Auswirkungen .NET Native auf UWP-Entwickler hat.

Wie beeinflusst .NET Native Entwickler und deren Apps?

Mit .NET Native soll unter anderem eine Ahead-of-time Kompilierung möglich sein, wodurch Universal-Windows-Platform-Anwendungen wesentlich schneller und kompakter werden. Microsoft macht die konkrete Angabe von bis zu 60 Prozent Performance-Verbesserung. Außerdem sollen die Apps 15 bis 20 Prozent weniger Arbeitsspeicher beanspruchen, wenn sie mit .NET Native kompiliert werden. Da alle Apps nun nativ kompiliert werden, profitieren Entwickler neben den Performance-Vorteilen auch von der bestehenden Möglichkeit, C#- oder VB-Programmiersprachen zu nutzen. Auch kann weiterhin das umfassende und robuste .NET-Model mit APIs verwendet werden, um Built-in Memory-Management und Exception-Handling zu nutzen sowie die Business Logik zu schreiben.

Stellen Sie Ihre Fragen zu diesen oder anderen Themen unseren entwickler.de-Lesern oder beantworten Sie Fragen der anderen Leser.

Änderungen für Entwickler durch .NET Native

Da die .NET Native-Kompilierung ein ziemlich komplexer Prozess ist, bedeutet das leider auch, dass dieser Vorgang im Vergleich zur klassischen .NET Kompilierung langsamer ist. Die oben genannten Vorteile ziehen eine schlechtere Compilation Time nach sich. Visual Studio Tooling unterstützt jedoch die Entwickler beim Erstellen: Baut und testet man in der „Debug“-Konfiguration, läuft IL-Code gegen die CoreCLR, die in der App verpackt ist. Die .NET-System-Assemblies liegen im App-Code, sodass die Applikation von der Microsoft.NET.CoreRuntime-Einheit abhängig ist. Auf diese Weise erhält man laut Daniel Jacobsen bei der Entwicklung von UWP-Apps das bestmögliche Erlebnis: schnelle Kompilierung und Entwicklung, vielfältige Debugging- und Diagnose-Tools sowie alle anderen Tools, die die .NET-Development-Umgebung bereithält.

Wechselt man dann in den „Release“-Modus, nutzt die App standardmäßig die .NET Native Toolchain. Da dieses Package zu nativen Binaries kompiliert wurde, muss es nicht die .NET Framework Libraries beinhalten. Es ist abhängig von der aktuell installierten .NET Native Runtime, die immer mit dem App-Package kompatibel bleibt. Die Local Native Kompilierung per „Release“-Konfiguration erlaubt das Testen von Apps in einem realitätsnahen Umfeld. Um mit der Entwicklung von Apps fortzufahren, sollten Developer diesen Schritt immer durchführen – so werden Fehler in der fertigen App und beim Endkunden vermieden. Zudem ist AnyCPU keine gültige Build-Konfiguration mehr, da die native Kompilierung architekturabhängig ist. Aus diesem Grund sollten Entwickler darauf achten, alle drei Architektur-Konfigurationen auszuwählen (x86, x64 und ARM), damit die App auf so vielen Devices wie möglich einsetzbar ist.

Eine weitere wesentliche Änderung betrifft die Erstellung von Packages für den Windows Store. Stellt man in Visual Studio ein Store-Package zusammen, werden zwei Einheiten kreiert: .appxupload und „test“ .appx für Sideloading. .appxupload enthält die MSIL Binaries sowie eine explizite Referenz zur .NET Native Toolchain, die die App verwendet. Dieses Package geht dann in den Store und wird kompiliert, indem genau dieselbe Version des .NET Native Toolchain genutzt wird. Da der Compiler cloud-gehostet ist, können Bugs ohne Recompiling gefixt werden.

Zusammengefasst sind die Hauptänderungen im Workflow die folgenden drei:

  • Test your application using the “Release” configuration regularly
  • Make sure to leave your revision package number as “0” – Visual Studio won’t let you change this, but make sure you don’t change it in a text editor
  • Only upload the .appxupload generated on package creation to the Store – if you upload the UWP .appx, the store will reject it with errors

Weitere Tipps und bekannte Issues mit .NET Native

Falls Probleme beim Debuggen von Release-Konfigurationen auftauchen, kann das an optimiertem Code liegen. Daniel Jacobsen schlägt vor, eine angepasste Konfiguration zu erstellen und für diesen Vorgang die .NET Native Toolchain zu aktivieren. Dabei darf der Code nicht optimiert sein. Ausführliche Informationen gibt das Microsoft Application Lifecycle Management.

Noch besser als aufgetretene Probleme zu debuggen, ist natürlich, sie von Anfang an zu vermeiden. Dabei hilft der Microsoft.NETNative.Analyzer, der eine Warnung ausgibt, falls Code nicht mit dem .NET Native Compiler kompatibel ist.

Nutzt man das Windows Application Certification Kit (WACK), um Apps zu testen, können folgende Schwierigkeiten auftreten:

  • When you run the WACK on a UWP app that did not go through this compilation process, you will get a not-so-trivial failure.
  • .NET Native applications that use reflection may fail the Windows App Cert Kit (WACK) with a false reference to Windows.Networking.Vpn.

Wie man diese Probleme behebt, wird im Blogpost ausführlich beschrieben. Eine weitere Hilfestellung bieten die Packaging Guidelines. Des Weiteren wird F# bis dato nicht von .NET Native unterstützt; das Team arbeitet aber bereits daran.

Fazit

Da .NET Native die Performance aller Universal-Windows-Platform-Apps verbessert – laut Angaben von Microsoft um bis zu 60 Prozent – starten und laufen managed Store-Apps schneller. UWP-Entwicklern bleibt die .NET-Development-Erfahrung erhalten, die sie bereits von Visual Studio gewohnt sind – zusätzlich erhalten sie dazu den Performance-Boost des nativen Codes. Wie man Apps mit .NET Native kompiliert, kann man im Microsoft Developer Network nachlesen. Entwickler können ihr Feedback zu .NET Native über die UserVoice-Site abgeben; Bugs können auf der Connect-Site gemeldet werden.

Aufmacherbild: application development concept: apps and laptop in line style  von Shutterstock / Urheberrecht: totallyPic.com

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -