.NET in Windows 8: AppContract, Marketplace und WPF/C# aus der Sicht eines Entwicklers

Question

Ich bin ziemlich aufgeregt über all die neuen Sachen, die in Windows 8 kommen, aber gleichzeitig ein wenig besorgt darüber, wie und ob ich den Code und die benutzerdefinierten Komponenten, die ich bereits mit .NET und C# als Windows-Entwickler aufgebaut habe, weiterhin nutzen kann. Ich habe einige allgemeine gemischte Fragen dazu. Hoffentlich macht es dir nichts aus, dass ich sie alle in einem Post zusammenfasse:

• Wird der Windows 8 Store sowohl für Metro-Apps als auch für reguläre WPF-Desktop-Apps sein? Einschließlich der Möglichkeit von Updates und der Bereitstellung von Apps für Unternehmensmitarbeiter?

• Wird das neue App-Vertrags-Dings auch für WPF-Apps verfügbar sein? Und basiert der App-Vertrag auf WCF-Services mit vielleicht UDP-Discovery im Netzwerk? Kann ich eigene Verträge zwischen meinen eigenen Apps mithilfe des App-Vertrags-Frameworks erstellen?

• Ich mache mir nicht besonders Sorgen darüber, ob WPF aufgegeben wird oder nicht. Ich kann ohne leben. Was mich beunruhigt, ist, ob ich weiterhin Präsentations- und Geschäftslogik in C# schreiben und als Backend für meine Apps verwenden kann, unabhängig davon, welches UI-Framework ich verwende, HTML, Silverlight, WPF oder was auch immer. Wenn ich immer noch in der Lage bin, Logik in C# zu schreiben und sie mit einem beliebigen UI-Framework darzustellen, bin ich ein glücklicher Entwickler. Ich habe gehört, dass ich auf das .NET-Framework von JavaScript aus zugreifen kann. Aber was ist mit benutzerdefinierten Assemblys?

Answer 1

Es wurde angekündigt, dass Nicht-Metro-Apps im Shop erscheinen können, aber der Shop wird nur auf die Website des Herausgebers verlinken - nicht tatsächlich den Verkauf/ die Installation/ DRM/ etc. verwalten.

Bisher wurde angekündigt, dass die Verträge nur für Metro-Apps gelten, aber ich wäre schockiert, wenn sich das nicht ändern würde. Es wäre verrückt für Microsoft, keine Desktop-Apps zum Beispiel Befehle zum Einstellungscharm hinzuzufügen, PlayTo oder Drucken durch den Geräte-Charms zu unterstützen oder als Freigabequellen zu fungieren. Wir werden abwarten müssen, wo sie die Grenze ziehen, was Desktop-Apps können/nicht können.

Der Codeaustausch zwischen Metro- und Nicht-Metro-Apps wird sehr schwierig sein. Viele der grundlegenden Konzepte und Konventionen sind die gleichen, aber selbst grundlegende Dinge wie Datei-I/O basieren auf einer völlig neuen API. Es gibt nicht viele interessante Dinge, die im Code gemacht werden können, die auf beiden Seiten des Zauns funktionieren. Die beste Option wäre, Schnittstellen für Ihre Geschäftsschicht zu definieren und dann Abhängigkeiten einzuspeisen, um dynamisch Desktop- vs. WinRT-Implementierungen zur Laufzeit auszuwählen.

Answer 2

• Geschäft: Es gibt keine endgültige Information, aber so weit ich weiß, ist es nur für Metro-Style-Anwendungen.

• Die App-Verträge sind eine Metro-Sache. Ich kenne einen Code-Schnipsel, der die Verwendung in Desktop-Apps dokumentiert (z.B. http://www.heise.de/developer/artikel/WinRT-in-klassischen-NET-Anwendungen-nutzen-1366039.html (sorry, German)), aber ich weiß nicht, ob er von Microsoft unterstützt wird.

• WinRT übersetzt Bibliotheken in WinRT-Komponenten. Du könntest in der Lage sein, Code wiederzuverwenden und sie zu einer Komponente zu kompilieren, solange du keinen Namespace verwendest, der für WinRT nicht verfügbar ist.

Diese Frage basiert stark auf Vermutungen, da es keine offizielle Beta-Version gibt. Und selbst dann können wir uns nicht absolut sicher sein...