Die Wichtigsten Infos und Änderungen zur Universal Windows App-Entwicklung in Windows 10

Über Bord mit dem .NET Framework!
Kommentare

Keine Angst: Natürlich lassen sich Windows 10 Apps immer noch mit Visual Basic und C# entwickeln. Aber das Framework, so wie wir es bislang kennen, verwenden diese Universal Windows Apps nicht mehr – stattdessen gibt’s .NET Core und jede Menge Neues in Sachen NuGet-Paketverwaltung. Das war selbst im 2015er RC noch anders, weswegen sich Windows 10 (UWA) Projekte im RTM auch nicht mehr öffnen lassen.

Die Liste der Neuerungen, die Visual Studio 2015 einführt, ist ellenlang, und auch für uns .NET-Entwickler ändert sich so einiges Grundsätzliches. Langfristig gesehen bedeutet das eine erhebliche Arbeitserleichterung und viel mehr Flexibilität – auf kurze Sicht ist jedoch etwas Hausmeisterarbeit notwendig, um Projekte, die bereits mit dem RC begonnen wurden, wieder auf den Stand zu bringen, bzw. sich an die neuen Gegebenheiten zu gewöhnen.

Herausragendste Änderung: Während Windows 8.1 Apps noch auf ein monolithisches Framework zurückgegriffen haben, das auf dem jeweiligen Client-Device vorhanden sein musste – jedenfalls was die .NET-Kernfunktionalität anbelangt – verwenden Windows 10 Apps nunmehr den .NET Core. Anwendungen, die .NET Core verwenden, benötigen nur noch ein Minimal-Framework, zu dem beispielsweise Komponenten wie die Execution Engine und Garbage Collector gehören – bringen aber ansonsten quasi genau das Framework selbst mit, das sie benötigen. Dadurch sie sind extrem flexibel und laufen teils sogar auf anderen Plattformen wie MacOS und Linux.  Der Grund für diese Paradigmenänderung war schlicht eine zu große Fragmentierung der existierenden .NET Frameworks, die für Windows Desktop, Windows Store, Windows Phone, ASP.NET 4 und ASP.NET 5 alle mit unterschiedlichen Runtimes, Framework-Implementierungen und App Modellen aufwarteten. Solange es nur darum ging auf eine einzige Plattform abzuzielen, war alles gut. In dem Moment allerdings, in dem eine Businesslogik beispielsweise sich auf mehreren verschiedenen Plattformen – am besten noch Xamarin-Cross-Plattform! – verwenden lassen sollte, wurde es „messi“.

Mit der Einführung von Portable Class Libraries war es zwar möglich, den verschiedenen .NET Versionen, basierend auf ihrer API-Ausbaustufe, mit einer Codebase gerecht zu werden. Das löst aber zum einen ein Microsoft-internes Problem nicht: Verschiedene Frameworks werden bei Microsoft natürlich von verschiedenen Teams implementiert. Die Vereinheitlichung der für Portable Class Libraries notwendigen Contract Assemblies (die dazu dienen, quasi den größten gemeinsamen Nenner im Funktionsumfang verschiedener Plattformen festzulegen) wurde dadurch immer zeitaufwändiger und nahezu nicht mehr beherrschbar. Zum anderen: Das Updaten eines kompletten Frameworks birgt immer erhebliche Regressionsgefahren auf Kundencomputern. Schon das Hinzufügen eines Interfaces zu einem Typ kann beispielsweise dessen Serialisierungsverhalten ändern. Und da es sich bei den meisten Framework Updates um Inplace-Updates handelt, hat das zur Folge, dass selbst wenn Ihre Software das .NET Framework 4.5.1 verlangt und mit ihm getestet wurde, diese Software von dem Moment an ebenfalls mit 4.6 läuft, sobald eine andere Software .NET 4.6 verlangt, und dieses auf demselben Rechner installiert wurde. Unabhängig davon, ob Ihre Software nun damit getestet wurde, sie sich damit verträgt oder eben nicht. Und es gibt weitere Gründe.

Vorhang auf für .NET Core und Project.JSon

Windows 10 Apps und ASP.NET-Anwendungen ist eines gemeinsam: Sie benötigen quasi eine lose Sammlung von den Komponenten, aus denen sich bislang ein gesamtes Framework zusammensetze – wenn auch aus unterschiedlichen Gründen. Bei ASP.NET 5.0-Anwendungen gibt es die Anforderung, ganze Websites per XCopy-Deployment (mit all ihren Abhängigkeiten) zu verteilen und dabei auch unterschiedliche „Framework“-Versionen auf einem Rechner möglich zu machen. „Framework“ in Anführungszeichen, weil es sich dabei natürlich nicht um das Framework im herkömmlichen Sinne handeln kann, sondern nur um die einzelnen Komponenten, die dann das Framework ausmachen. Windows 10 Apps haben die gleichen Anforderungen, wenn auch anders bedingt: Hier spielt der .NET Native-Compiler die entscheidende Rolle. Dieser soll möglichst schlanke und effiziente Laufzeit-Binaries mit dem vom Prozessor ausführbaren Maschinencode liefern, die nicht wie herkömmliche .NET Anwendungen erst während der Laufzeit aufwändig geJITtet werden müssen. Daher kompiliert .NET Native die Release-Version Ihres Windows 10 UWA (Universal Windows App) Projektes in nativen, direkt vom Prozessor ausführbaren Maschinencode und linkt die Teile des „Frameworks“, die Ihre Anwendung benötigt (und nur die!) direkt dazu. Diesen Vorgang auf Basis des herkömmlichen Frameworks möglich zu machen, ist schwierig, aber notwendig: Denn das JIT-Verfahren kostet Platz, Prozessor- und damit Akkuleistung und Zeit, und gar nicht wenig. Und gerade die haben wir auf mobilen Geräten nun mal überhaupt nicht übrig.

Nun gibt es bereits ein Verfahren, diese „losen“ Assemblies ideal zu verteilen: NuGet. Für viele von uns .NET-Entwicklern ist der NuGet-Manager ein Tool, das wir neben Editor, Eigenschaftenfenster und Projektmappen-Explorer mit am häufigsten verwenden. Manchmal leider sogar zu häufig, wenn es nicht so wie gedacht funktioniert. Und hier wird ein weitere Vorteil deutlich: Wenn Neuerungen anstehen, kann ein Team bei Microsoft, das für einen bestimmten Teil des Frameworks zuständig ist, diesen direkt als NuGet-Package veröffentlichen und muss nicht erst den ganzen Release-Cycle eines monolithischen Frameworks abwarten. So werden das neue .NET 4.6 Framework und .NET Core Anfangs noch denselben Versionsstand haben. Es wird allerdings so sein, dass .NET Core recht schnell einen deutlichen Versionsvorsprung zum .NET 4.6 haben wird.  Allerdings, und das wissen viele, NuGet wie wir es bislang kannten, hatte auch einige Macken oder zumindest in einigen Bereichen deutliches Optimierungspotential:

  • Die VB- oder CS-Projektdateien werden regelmäßig mit NuGet-Package-„Resten“ verseucht. Das merkt man besonders dann, wenn man Projekte an eine andere Stelle im Filesystem verschiebt …
  • … bzw. wenn zwei Projektmappen an zwei verschiedenen Orten im Filesystem ein Projekt mit NuGet-Paketen referenzierten. Das funktioniert wirklich nur unter ganz bestimmten Umständen.
  • Beim Wechseln der Zielplattform musste man in der Regel die NuGet-Pakete de- und wieder reinstallieren.
  • Der Referenz-Knoten eines Projektes im Projektmappen-Explorer war oft überladen, da die NuGet-Pakete, von denen ein NuGet-Paket wiederum selbst abhängig war, dort auch zu sehen waren. Damit war das Deinstallieren von NuGet-Paketen oftmals ebenfalls recht mühselig.
  • Pakete wurden nicht global (pro Benutzer-pro Maschine) sondern Projektmappen-abhängig und damit sehr redundant vorgehalten.
  • Oft fehlte eine genauere Kontrollmöglichkeit über NuGet-Paket-Updates und Versions-Unstimmigkeiten.

Neue Projekttypen, wie zunächst ASP.NET 5.0 und Universal Windows Apps, die auf.NET Core (es heißt übrigens nicht mehr .NET Core 5!) basieren, führen deswegen ein neues NuGet-Management ein, und das nennt sich Project.JSon. Aber Achtung: Ein Projekt, das seine Projekte mit Project.JSon verwaltet, ist damit nicht zwangsläufig ein Projekt, das auch auf .NET Core basiert. Die ASPler unter Ihnen wissen das schon, falls sie die ersten Gehversuche mit ASP.NET 5.0 bereits gemacht haben. Mit einem Trick können Sie auch ein „herkömmliches“ Projekt auf die NuGet-Verwaltung mit Project.JSon umstellen.

Starten mit der Windows 10-Entwicklung

Wie sieht das nun für Windows 10-Anwendungen, also Universal Windows Apps (UWA) in der Praxis aus?

So sieht ein typisches UWA-Projekt in Visual Studio 2015 RTM aus. Zu sehen ist die project.json-Datei, die die verwendeten NuGet-Pakete beschreibt.

So sieht ein typisches UWA-Projekt in Visual Studio 2015 RTM aus. Zu sehen ist die project.json-Datei, die die verwendeten NuGet-Pakete beschreibt.

Dazu muss man zunächst mal zweierlei Dinge wissen. Zum einen: Wenn Sie Visual Studio 2015 RTM VOR dem 29.7.2015 installiert hatten, dann konnten Sie leider GAR keine UWA-Entwicklung damit machen, denn die so genannten Windows 10 Tools waren zu diesem Zeitpunkt noch nicht fertig, und nicht im Lieferumfang enthalten.

Die Windows 10 Tools waren im Visual-Studio-ISO-Image enthalten – Visual Studio Setup lädt das rund 2.5 GByte große Image der Windows 10 Tools vielmehr während der Installation aus dem InterWeb nach. Aus diesem Grund müssen Sie, um in den Genuss der Windows 10 Tools zu kommen, ab 29.7. irgendwann nach 17.00 Uhr deutscher Zeit, die Visual Studio-Installation abermals starten und eine Modify-Installation durchführen. Erst dann wird die Optionsauswahl durch einen entsprechenden Live Feed geradezu magisch aktualisiert, und die Optionen zur Installation der Windows 10-Tools stehen Ihnen dann zur Verfügung. Wichtig bei zukünftigen Installationen: Sie sollten, auch wenn Sie das Image von Visual Studio selbst zuvor heruntergeladen haben, dennoch eine schnelle Internet-Verbindung zur Verfügung haben, und diese, in Anbetracht der nachzuladenden Datenmengen, möglichst nicht über Ihr Smartphone stattfinden lassen. Erst wenn die Windows 10 Tools auf diese Weise installiert wurden, stehen Ihnen die neuen Projektvorlagen zur Verfügung, auf deren Basis Sie dann mit der UWA-Entwicklung beginnen können.

Sollten Sie bereits begonnen haben, neue UWAs mit dem früheren Release Candidate für Visual Studio 2015 zu entwickeln, dann gibt es nicht so gute Neuigkeiten. In diesem Fall lassen sich nämlich diese Projekte nicht in das neue Projektformat konvertieren. Einzige Möglichkeit: Legen Sie eine Projektmappe an anderer Stelle an, erstellen Sie die UWP-Projekte neu, die zu dieser Projektmappe gehören, und kopieren Sie anschließend die Quellcode-Dateien in die neue Projektmappe. Wichtig: Wenn Sie die Projektmappe zuvor unter Quellcode-Verwaltung gestellt haben, checken Sie die Solution komplett aus, verschieben Sie die alte Projektmappe nach dem Quellcodedateientausch ins Archiv (oder in den Müll) und die umgestellte Projektmappe wieder zurück an die Stelle.

Ebenfalls wichtig: Nachdem Sie Visual Studio um die Windows 10 Tools erweitert haben, führen Sie unbedingt ein Update der Extensions, insbesondere des NuGet-Packet-Managers auf die aktuelle Version durch. Dazu wählen Sie aus dem Menü Tools (Extras) die Option Extension and Updates… aus.

Der neue NuGet-Manager von Visual Studio 2015 kann nunmehr wie ein Dokument auch nicht-modal verwendet werden. Die Auswahl von Befehlen durch die Combo-Box ist jedoch ein wenig gewöhnungsbedürftig.

Der neue NuGet-Manager von Visual Studio 2015 kann nunmehr wie ein Dokument auch nicht-modal verwendet werden. Die Auswahl von Befehlen durch die Combo-Box ist jedoch ein wenig gewöhnungsbedürftig.

Achtung bei der Verwendung bestimmter NuGet-Pakete

Anders als noch bei der Entwicklung unter Windows 8.1, wird unter Windows 10 standardmäßig beim Release-Build sowohl in Visual Basic als auch in C# der .NET Native-Compiler verwendet. Eines, was Ihnen dabei sofort auffallen wird: Der Kompilierungsvorgang dauert DEUTLICH länger, als Sie es gewohnt sind – im Grunde sollten wir hier mit ähnlichen Turnaround-Zeiten wie beim C++-Compiler rechnen.

Was aber noch wichtiger ist: Die Verwendung von .NET Native lässt einige Pakete inkompatibel zum Compiler werden – das betrifft insbesondere die Dinge, die intensiv von Reflection Gebrauch machen. Probleme gibt es bei Portable Class Libraries, die beispielsweise Methoden wie IsAssignableFrom direkt auf Type verwenden. Ein Beispiel dafür ist die beliebte IoC-Container-Library AutoFac in der letzten stabilen Version 3.5.2 (Zeitpunkt des Schreibens dieses Artikels). Wenn Sie diese per NuGet in Ihr UWA-Projekt einbinden, funktioniert Ihre Anwendung, solange Sie sie im Debug-Profil kompilieren und testen ohne Probleme. Beim Kompilieren im Release-Profil zeigt Ihnen .NET-Native jedoch eine Fehlermeldung, etwa wie im Folgenden zu sehen:

1>C:\Program Files (x86)\MSBuild\Microsoft\.NetNative\x86\ilc\IlcInternals.targets(1408,5): warning : Assembly 'Autofac' requests the address of the virtual method 'Type.IsAssignableFrom(Type)' which is not available in the targeted .NET platform. Please ask the author of 'Autofac' to provide an implementation that can be used in the currently targeted .NET platform.

 

Ein Kompilierungsvorgang im Output-Window von Visual Studio. Achten insbesondere beim Release-BUILD auf Warnungen von inkompatiblen NuGet-Paketen, wie hier im Screenshot zu sehen.

Ein Kompilierungsvorgang im Output-Window von Visual Studio. Achten insbesondere beim Release-BUILD auf Warnungen von inkompatiblen NuGet-Paketen, wie hier im Screenshot zu sehen.

In diesem Fall bleibt Ihnen nichts anderes übrig, als auf ein entsprechendes Update zu warten, oder, wie im Fall von AutoFac, sich zunächst mit den entsprechenden Beta-Versionen zu begnügen.

Aufmacherbild: Red buoy on ship via Shutterstock.com / Urheberrecht: Dudarev Mikhail

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -