Die letzte Zeit habe ich mich damit beschäftigt, den SampleContainer von Seeing# als App für den neuen Windows Store in Windows 10 zu veröffentlichen. Interessanterweise müssen alle Windows 10 Universal Apps mit .Net Native kompiliert sein, damit man diese hochladen kann [1]. Für kleinere Apps habe ich das vorher schon mal ausprobiert, es gab keine nennenswerten Probleme. Bei Seeing# allerdings musste ich einige Zeit rumspielen, bis es schließlich erfolgreich mit .Net Native kompiliert wurde und als Paket durch die Prüfungen des Windows Store ging. Hier in diesem Artikel habe ich ein paar Punkte zusammengestellt, die ich speziell dafür anpassen musste.
.Net Native muss im Release-Build aktiviert sein
Standardmäßig aktiviert Visual Studio bei Windows Universal App Projekten .Net Native im Release-Build und im Debug-Build entsprechend nicht. Der Grund liegt kurz gesagt darin, dass das Compilieren ohne .Net Native gewohnt schnell läuft und mit aktiviertem .Net Native um ein vielfaches länger braucht. Im Debug-Build können Quellcode-Änderungen somit schnell getestet werden, bevor man den Release-Build ausführt. Der Release-Build muss aber unabhängig davon auch getestet werden, da nicht ausgeschlossen ist, dass die App mit aktivierten .Net Native teilweise anderes reagiert (z. B. bei Reflection). Details dazu sind hier zu finden [2]. Wichtig zu wissen ist, dass der Windows Store nur noch Apps akzeptiert, die mit .Net Native compiliert wurden.
AnyCPU nicht unterstützt
Bei Windows 8.1 und Phone 8.1 habe ich jeweils gerne die AnyCPU Buildkonfiguration verwendet, und zwar aus Gründen der übersichtlicheren Build-Einstellungen. In der Vergangenheit ist es mir nicht selten passiert, irgendeines der Häkchen z. B. nur im x86 Build einzustellen, nicht aber in den anderen. Chaos breitet sich da schnell aus. Bei .Net Native dagegen wird nativ für einen bestimmten Prozessor kompiliert, es gibt also vom Grundsatz her schon kein AnyCPU und somit ist man wieder zurück bei verschiedenen Buildkonfigurationen für X86, X64 und ARM. Für die Desktop-Builds bleibe ich aber nach wie vor bei AnyCPU. Wichtig: Die Buildkonfiguration muss nur im Haupt-Projekt (die tatsächliche App) wie beschrieben angepasst werden. Die verwiesenen Projekte können nach wie vor AnyCPU als Zielprozessor haben. Bei Seeing# habe ich das entsprechend so gemacht.
Das Thema Reflection
Bei Reflection kann sich .Net Native unter Umständen etwas anders verhalten [3]. Überraschenderweise hatte ich an der Stelle keine Probleme, obwohl ich innerhalb von Seeing# schon einige Sachen mit Reflection mache. So ist z. B. der TypeQueryHandler [4] eine Klasse, die sich per Reflection verschiedene Komponenten der aktuellen App zusammensucht. Also eine sehr einfache eigene Variante von MEF.
Verweise
- https://channel9.msdn.com/Events/Build/2015/2-790
- https://blogs.windows.com/buildingapps/2015/08/20/net-native-what-it-means-for-universal-windows-platform-uwp-developers/
- https://msdn.microsoft.com/en-us/library/dn600640(v=vs.110).aspx
- https://github.com/RolandKoenig/SeeingSharp/blob/master/SeeingSharp/Infrastructure/_TypeQuery/TypeQueryHandler.cs