Allgemein Für Administratoren Für Architekten Für Entwickler Für Projektleiter Für Tester News Produkte Publikationen
X
Felix Mokross

Felix Mokross

Neu in .NET 4.5: Das Profil .NET for Windows Store apps

Montag, 01. Oktober 2012

Seit .NET 3.5 SP1 bot Microsoft mit dem Client Profile eine abgespeckte Variante des vollen .NET Frameworks an, mit welcher nur die für Client-Systeme relevanten Komponenten ausgeliefert wurden. Mit .NET 4.5 wird dieses Profil nicht mehr weitergeführt, da dafür keine Notwendigkeit mehr gesehen wird. Gleichwohl hat auch die neue .NET-Version einen kleinen Bruder: Die Variante .NET for Windows Store apps, welche zur Entwicklung der neuen Windows Store Apps auf Basis der .NET-Plattform bestimmt ist. In diesem Artikel stelle ich das neue Profil des Frameworks vor und zeige die Unterschiede zur Standardvariante auf. Nach einer kurzen Einführung zur Windows Store Plattform wird ein Überblick über die verfügbaren APIs gegeben. Anschließend wird beschrieben, welche Technologien des .NET-Frameworks von der Windows Runtime ersetzt werden und welche Funktionalitäten in Windows Store Apps nicht eingesetzt werden können.

Windows Runtime

Mit der Windows Runtime (kurz WinRT) führt Microsoft ab Windows 8 eine neue API ein, die dem Entwickler Zugriff auf die zentralen Funktionen des Betriebssystems gibt. Für die Entwicklung der neuen Windows Store Apps ist diese API essentiell, da Win32 dafür nicht zur Verfügung steht. In Desktop-Anwendungen kann die Programmierschnittstelle in etwas engeren Grenzen parallel zu Win32 eingesetzt werden.

.NET-Entwickler wird freuen, dass die WinRT-Programmbibliotheken zwar nativ (und damit “unmanaged”) und COM-basiert sind, ihre Metadaten aber auch im CLI-Format zur Verfügung gestellt werden. Dazu werden mit der Windows Runtime separate .winmd-Dateien ausgeliefert, da die Metadaten nicht direkt in den nativen DLLs untergebracht werden können. Die WinRT-Schnittstelle ist objekt-orientiert und benutzt das CLI-Typsystem. Aus Managed Code heraus kann die Windows Runtime daher grundsätzlich genauso einfach verwendet werden, wie andere .NET-Assemblies. Das normalerweise zur Kommunikation mit Unmanaged Code notwendige P/Invoke wird dabei nicht mehr benötigt.

Entwicklung von Windows Store Apps

Für die Entwicklung von Windows Store Apps stehen drei verschiedene Stacks zur Verfügung. Eine vielleicht etwas überraschende, neue Möglichkeit ist es, Apps auf Basis von JavaScript und HTML 5 zu entwickeln. Das Ergebnis wird ähnlich wie Webseiten von Microsofts Browser-Engines Trident (Layout) und Chakra (JScript) ausgeführt. Des Weiteren ist es möglich, die Anwendungen nativ in C++ zu programmieren, wobei Microsoft die Verwendung der neuen Sprachvariante C++/CX (Component Extensions) empfiehlt. C++/CX ähnelt syntaktisch C++/CLI, der Quelltext wird allerdings zu Unmanaged Code kompiliert. Für die Gestaltung der grafischen Oberfläche kann in diesem Stack u. a. XAML verwendet werden. Hierbei kommt ein neues, erstmals natives XAML-Framework zum Einsatz, welches Teil der Windows Runtime ist.

Als dritte Option wird die Entwicklung mittels .NET-Framework in den Sprachen C# und Visual Basic unterstützt. Der Managed Code wird von der gleichen CLR ausgeführt, wie .NET-Anwendungen in der Desktop-Welt. Mit dem neuen Profil .NET for Windows Store apps wird der App eine Untermenge des vollen .NET-Frameworks zur Verfügung gestellt. Für die Benutzeroberfläche steht dabei ausschließlich die XAML-API der Windows Runtime  zur Verfügung.

Die folgende Abbildung zeigt die verschiedenen Entwicklungs-Technologien der Windows-8-Plattform. Der für diesen Artikel relevante Stack zur Entwicklung von Windows Store Apps in C# und Visual Basic ist hervorgehoben.

image_20

© Magenic | mit freundlicher Genehmigung aus Rockford Lothka; Windows 8 Development Platform Clarified (2011)

Unterstützte APIs

Viele APIs der .NET-Standardvariante sind im Profil für Windows Store Apps aus verschiedenen Gründen nicht enthalten. So wurden APIs weggelassen, die in den typischen Szenarien für diese Apps nicht benötigt werden, wie z. B. ASP.NET oder die Console-API. Da die Windows Runtime dazu bestimmt ist, parallel zu .NET eingesetzt zu werden und ihre Verwendung im Gegensatz zur Win32-API aus dem .NET-Code heraus sehr einfach ist, konnten auch alle APIs des .NET-Frameworks entfallen, deren Funktionalität bereits von der Windows Runtime unterstützt wird und die im .NET-Framework oft als Win32-Wrapper implementiert sind (z. B. Sockets). Für die UI-Frameworks Windows Forms und WPF besteht in Windows Store Apps ebenso kein Verwendungszweck, da für die Erstellung der Benutzeroberfläche im .NET-Stack lediglich das XAML-Framework der Windows Runtime vorgesehen ist. APIs, deren Funktionalität bereits innerhalb des vollen .NET-Framework mehrfach abgedeckt wurde, wurden ebenso auf eine API reduziert (so wurden bspw. die nicht-generischen Collections entfernt). Außerdem wurden verschiedene APIs fallen gelassen, welche als überholt angesehen werden.

Grundsätzlich sind in der Windows-Store-Variante des .NET Frameworks jeweils nur die für Clients relevanten und Teile der restlichen APIs enthalten, sämtliche Server-Funktionalitäten (z. B. System.Web) entfallen. Der Namespace System.Net.WebClient ist nicht verfügbar. Um auf HTTP-Client-Funktionalität zugreifen zu können, sollte in diesem Profil die neue HTTP-API im Namespace System.Net.Http verwendet werden. Außerdem können Windows Store Apps den vollständigen WCF Client Stack nutzen.

Innerhalb des System.Xml-Namespaces wird hauptsächlich LINQ to XML unterstützt. Mit XmlReader und XmlWriter kann der XML-Stream bei Bedarf auf niederer Ebene gesteuert werden.

Im Bereich Serialisierung wird auf Data Contracts als Haupttechnologie gesetzt. Die herkömmliche XML-Serialisierung aus dem Namespace System.Xml.Serialisation steht für sehr spezielle Szenarien weiterhin zur Verfügung.

Das folgende Block-Diagramm gibt einen Überblick über diese APIs:

Picture1

Das Managed Extensibility Framework (MEF) wird nicht direkt mit dem Windows-Store-Profil ausgeliefert, kann aber mit dem NuGet-Paket Microsoft.Composition in das Projekt nachinstalliert werden. Anschließend ist es im neuen Namespace System.Composition (anstelle von System.ComponentModel.Composition) verfügbar. Dabei sollte angemerkt werden, dass MEF in Windows Store Apps nur als interne Composition Engine genutzt werden kann, da das Sandbox-Prinzip der Apps keine Erweiterung durch Bibliotheken von Dritt-Anbietern zulässt.

Ersatz durch die Windows Runtime

Viele der Funktionalitäten, welche das volle .NET Framework bietet, werden auf der Windows-Store-Plattform durch die native Windows Runtime ersetzt. Die WinRT-Namespaces beginnen zur Unterscheidung von den Namespaces des .NET-Profils jeweils mit Windows.*. Die folgende Auflistung beschreibt kurz, welche .NET-Technologien bei der Entwicklung von Windows Store Apps von WinRT ersetzt werden:

  • Benutzeroberfläche
    Für die UI von Windows Store Apps auf .NET-Basis wird, wie bereits erwähnt, die XAML-API der Windows Runtime verwendet. Diese neue XAML-Variante, die dabei zum Einsatz kommt, ähnelt am ehesten der Silverlight-Variante. Selbstverständlich lässt sich eine vorhandene WPF- oder Silverlight-Oberfläche nicht ohne weiteres in eine Windows Store App übernehmen. Es ist anzuraten, die Benutzeroberfläche anhand der Design-Richtlinien von Microsoft neu zu entwerfen, um die App an die neuen Bedienkonzepte der Modern UI anzupassen.
  • Isolated Storage
    Die Isolated-Storage-Technologie wird abseits des Desktops von der entsprechenden API der Windows Runtime im Namespace Windows.Storage.ApplicationData ersetzt. Diese Technologie erlaubt u. a. die Synchronisation der Anwendungsdaten zwischen den Geräten des Benutzers über die Cloud.
  • Ressourcen
    Der ResourceManager des .NET-Frameworks steht im Windows-Store-Profil zwar weiterhin zur Verfügung, die MSDN-Dokumentation rät aber zur Benutzung des WinRT-Gegenstücks, dem Windows.ApplicationModel.Runtime.ResourceLoader. Die herkömmliche .NET-API sollte lediglich bei der Entwicklung von Portable Class Libraries verwendet werden, welche mit dem kleinsten gemeinsamen Nenner der Zielplattformen auskommen müssen.
  • Sockets
    Die Socket-API des .NET-Frameworks ist lediglich ein sehr dünner Wrapper der entsprechenden Systemfunktionen. Daher ergibt es Sinn, dass diese Funktionalität im “Metro”-Profil durch die native API der Windows Runtime im Namespace Windows.Networking.Sockets ersetzt wird.
  • HTTP für große Datenmengen
    Aufgrund des Lifecycle Managements von Windows Store Apps, bei welchem Apps im Hintergrund suspendiert werden, ist die neue HTTP-API des .NET-Frameworks nicht für das Herunterladen größerer Dateien geeignet. Bei der Benutzung von HttpClient würden Downloads unterbrochen, sobald sich die App nicht mehr im Vordergrund befindet. Daher bietet die Windows Runtime als Ergänzung eine API für Hintergrundtransfers an (Namespace Windows.Networking.BackgroundTransfer), welche in diesem Szenario einzusetzen ist.

Was fehlt?

ASP.NET war bereits im Client Profile des .NET-Frameworks nicht enthalten. Daher ist es nur konsequent, dass diese Technologie, wie bereits erwähnt, auch aus dem Windows-Store-Profil ausgeschlossen wurde, da dieses ebenfalls exklusiv für Client-Szenarien ausgelegt ist.

Die mächtigen Reflection-Möglichkeiten des vollen .NET-Frameworks wurden bei der Erstellung des neuen Profils weitgehend entfernt. So können private Member nicht mehr per Reflection erfasst werden und es ist nicht mehr möglich, zur Laufzeit generierte Assemblies abzuspeichern oder zu laden. Ersteres ist zumindest laut Microsoft eine häufige Quelle von Kompatibilitätsproblemen. Außerdem würden diese Fähigkeiten in den typischen App-Szenarien nicht benötigt.

Des Weiteren entfällt bei Windows Store Apps die Möglichkeit, mit mehreren Application Domains zu arbeiten. In diesem Zusammenhang sah Microsoft in der .NET-Remoting-Technologie nicht mehr genug Mehrwert, so dass diese ebenfalls aus dem Profil entfernt wurde.

Die vermutlich unbeliebteste Streichung bei der Entwicklung des Windows-Store-Profils betrifft den Namespace System.Data. Mit diesem entfallen sämtliche Technologien zur direkten Anbindung von Datenbanken (klassisches ADO.NET, Entity Framework, LINQ to SQL) und damit auch zur potenziellen lokalen Datenspeicherung beispielsweise mit SQL Server Compact. Die Vision Microsofts ist es, dass Apps Daten vorrangig via OData in der Cloud speichern, um sie so Geräte-unabhängig verfügbar zu halten. Nur über das Dateisystem ist es weiterhin möglich, strukturierte Daten lokal zu speichern.

Weitere Unterschiede

Im folgenden noch ein paar weitere, kleinere Unterschiede zwischen dem Desktop-Profil und der Windows-Store-Variante:

  • Um die Abhängigkeiten der zentralen Assemblies zu reduzieren, wurde u. a. die meiste Reflection-Funktionalität von System.Type in die neue Klasse System.Reflection.TypeInfo verfrachtet. System.Type dient in diesem Profil lediglich zur Typidentifikation. Mittels der Methode GetTypeInfo() kann das zugehörige TypeInfo-Objekt abgerufen werden, um Zugang zu den weiteren Features zu erhalten.
  • Das Metro-Profil enthält nur noch die generischen Collections.
  • Das .NET-Profil für Windows-Store-Apps enthält zur Thread-Kontrolle lediglich die Task API. Es kann dafür aber zusätzlich die Threading API der Windows Runtime verwendet werden (Windows.System.Threading).
  • Mit .NET 4.5 wird ein neues Pattern zur asynchronen Programmierung eingeführt. Während in der Standardvariante des Frameworks die herkömmlichen Methoden weiterhin zur Verfügung stehen, setzt das Windows-Store-Profil ausschließlich auf dieses neue Model. So wird bspw. statt Stream.BeginRead die neue Methode Stream.ReadAsync verwendet.

Fazit

Das Profil .NET for Windows Store apps ist eine stark beschnittene Variante des .NET Frameworks. Viele der fehlenden APIs werden durch die Windows Runtime nativ ersetzt, was in vielen Fällen durchaus positiv ist. Die Beschränkung auf Technologien, die für Client-Szenarien relevant sind, ist nachvollziehbar und scheint konsequent umgesetzt zu sein. Wer die umfangreichen Fähigkeiten des .NET-Frameworks gewohnt ist, wird sich natürlich zunächst an diese Beschränkungen und an die neuen APIs der Windows Runtime gewöhnen müssen. Darüber hinaus bietet die WinRT aber auch viele neue Möglichkeiten, die dank der CLI-Metadaten auf einfachem Wege in .NET zugänglich sind.

Der Verzicht auf Technologien zur lokalen strukturierten Datenspeicherung wird vermutlich für viele App-Entwickler eine Hürde darstellen (siehe z. B. MSDN Forum). In vielen Fällen ist das Speichern der Daten in der Cloud sicherlich sinnvoll, da es auch einen Mehrwert bieten kann. Sollte dies für den Kunden nicht möglich sein – sei es aus rechtlichen Gründen oder prinzipiellen Bedenken – bleibt derzeit nichts anderes übrig, als auf eine Drittanbieter-Lösung oder Eigenentwicklung zu setzen.

Link-Tipps

 

    Verwandte Artikel:

    Benötigen Sie Unterstützung bei der Software-Entwicklung und Architektur von .NET basierten Lösungen oder bei Einführung und Anpassung von Visual Studio / Microsoft Test Manager / Team Foundation Server?

    Wir stehen Ihnen unter info(at)aitgmbh.de gerne zur Verfügung.

    Tags: , ,

    Hinterlasse eine Antwort