M.M.n. hätte man sich eher darum kümmern sollen, mit .NET 5 (oder .NET Core 3.X, oder wie sie das Zuegs schon wieder umbenannt haben) wirklich systemübergreifend mit einer einzigen Codebasis und einer einzigen Entwicklungsumgebung auch GUI-Anwendungen entwickeln zu können. Aber sowas scheint mit Microsoft-"Systemmitteln" nahezu unmöglich zu sein. Erst wenn sie mal soweit sind macht es für mich Sinn, bewusst auf Win32-Aufrufe zu verzichten (was derzeit nahezu immer einen Verzicht bei Performance oder Funktionalität bedeutet).
Gemeinsam mit .NET 6 wird auch .NET MAUI kommen, womit es möglich sein wird, eine UI zu programmieren, die Cross Plattform verfügbar ist und somit auf verschiedenen Endgeräten und Betriebssystemen lauffähig sein wird. Hierzu wird .NET MAUI auch in .NET for Android und .NET for iOS (ehemals Xamarin) integriert werden.
"NET MAUI vereinfacht die Auswahlmöglichkeiten für .NET-Entwickler und bietet einen einzigen Stack, der alle modernen Workloads unterstützt: Android, iOS, MacOS und Windows. Die systemeigenen Funktionen der einzelnen Plattformen und UI-Steuerelemente sind in einer einfachen, plattformübergreifenden API für Sie erreichbar. NET MAUI wird in all diesen Versionen - Visual Studio 2019, Visual Studio for Mac und Visual Studio Code - verfügbar sein und sowohl die vorhandenen MVVM- und XAML-Pattern als auch zukünftige Funktionen wie Model-View-Update (MVU) mit C# oder sogar Blazor unterstützen. Wir werden im Laufe dieses Jahres mit dem Versand von .NET MAUI-Previews beginnen und streben die allgemeine Verfügbarkeit von .NET 6 im November 2021 an. "
Link:
Introducing .NET Multi-platform App UI | .NET Blog
Mal sehen ob ihnen das unmögliche gelingt die komplette Win32-API zu kapseln. Bisher haben sie das mit .NET ja bekanntlich nicht geschafft, selbst ohne die noch viel stärker kastrierte UWP-APIs.
Wenn man heute diese Anforderung hat und auf Grund der >10 Jahre alten Codebasis das nicht mit akzeptabelem Aufwand gelöst bekommt, dann dürfte die Applikation vermutlich auf MFC oder Windows Forms basieren (um im Microsoft-Universum zu bleiben), inkl. fehlender Trennung von Logik- und Benutzerschnittstelle.
Dass MS es niemals schaffen will und wird, Winodws Forms entsprechend zu erweitern (wäre sowieso nicht zu 100% möglich, die SW-Anpassungen wären aber viel einfacher wie der Umstieg auf WPF), ist ja bekannt.
Warum sollte dann jetzt irgendwer mit einer neuen WinUI3 anfangen, seine alte Applikation umzustellen? Das wird unter Garantie Jahrelang (oder gar Jahrzehntelang) auch wieder nicht vollständig sein, womit sie gerade für solche Projekte nutzlos ist. Dazu kommt die Gefahr, dass MS das Projekt in 3-4 Jahren einfach wieder fallen lässt, wie schon so vieles.
Es gibt bis heute genügend Dinge, die sich mit managed .NET schlicht nicht lösen lassen. Warum sollte Reunion es dann schaffen, das innerhalb absehbarer Zeit stabil, vollständig und langfristig zu ermöglichen?
Mit fällt auch kein Grund ein, warum ich mit Webview2 irgendwelche Web-UIs in eine Applikation integrieren sollte. Entweder, ich nutze Webtechnnologie für das Programm, dann kann (bz.w meist will) ich unabhängig vom Client-OS sein und entwickele gleich eine Weboberfläche mit entsrpechendem Server. Oder ich benötige Funktionalitäten, die seit dem Ende des IE abgeschafft wurden, dann bringt mir Webview2 mit Chromium auch nichts.
Nun ja, ich denke, dass es bei Webview 2 darum geht, die Web-UIs einfacher in Win32-Apps integrieren zu können und trotzdem eine Art "Desktop-Programm" zu haben. IE ist in einer der kommenden Microsoft-Edge-Chromium-Versionen integriert. Es kann ja durchaus auch Nutzer bzw. Firmen geben, die zwar bestimmte Infos aus URLs ziehen müssen, aber eben trotzdem ein lokal installierbares, "altes" Win32-Programm bevorzugen. Schließlich wollen viele Softwareentwickler nicht den Aufwand betreiben und z.B. eine extra UWP-App programmieren. Also lieber die alte Win32-App weiter aufbohren, um Zeit und somit Geld zu sparen. Der Nutzung auf anderen Windows-Geräte-Formfaktoren wie z.B. der Xbox-Konsole, findet so gut wie gar nicht statt und Windows-Smartphones gibt es keine mehr. Es gibt also keinen Grund mehr, eine UWP-App zu entwickeln.
Gleichwohl gibt es durchaus verschiedene Eingabemethoden am PC, die mit einer alten Win32-App nur sehr schwerlich zu nutzen sind. So ist oftmals die Skalierung von UI-Elementen ein Problem, wenn man das Programm mittels Touchscreen bedienen will. In diesem Fall müssen sowohl die UI-Elemente größer - und somit "Finger-freundlich" - gestaltet sein, sowie sollte es eine Unterstützung für "Swipe-Gesten" - also Wischgesten - geben, damit man mit einem Fingerwisch etwas bestätigen oder ablehnen kann. All das geht mit einer alten UI einer Win32-App nicht bzw. bedarf einer teuren Eigenentwicklung der Softwareentwickler. Mit "WinUI 3" hingegen kommen solche Funktionen als Teil der nutzbaren Bibliothek für jeden Softwareentwickler, sodass man hier einen gewissen Standard hat.
Klar, es ist ein ambitioniertes Vorhaben von Microsoft mit "Project Reunion". Aber der Konzern aus Redmond hat nun eingesehen, dass der bisher seit dem Jahr 2015 (Marktstart von Windows 10) propagierte "Zwang", Entwickler zur Neuprogrammierung einer UWP-App zu bringen, absolut nichts gebracht hat. Die Softwareentwickler scheuen den zusätzlichen Aufwand und haben - wie gesagt - argumentiert, dass man ja eine auch auf Windows 10 funktionierende Win32-App (früher "Win32-Programm" genannt) anbiete, die eben auf einer vergleichsweise alten Codebasis steht, aber immer noch lauffähig ist. Der Anreiz für eine komplette Neuprogrammierung hat gefehlt.
-> Folge: Mit "Project Reunion" setzt man eben da an und erlaubt es Entwicklern explizit, ihre alte Codebasis zu behalten, egal, ob diese mit Windows Forms, WPF, C++ geschrieben ist. Es geht darum, diese im Kern jahrealten x86-Programme mit neuen Funktionen anreichern zu können, bei vertretbarem Aufwand, also ohne, dass eine komplette Neuprogrammierung notwendig ist.
-> Microsoft will den Softwareentwicklern mehr Freiheiten geben und steckt bewusst zurück, was etwa die Thematik eigenständige UWP-App angeht. Schließlich kann Microsoft auch auf andere Art und Weise Geld verdienen, in dem man etwa Gebühren von Entwicklern verlangt und diesen dafür Softwarelizenzen von Visual Studio überlässt. Oder falls ein Entwickler eine Win32-App kompatibel mit "Windows Virtual Desktop" macht, dann muss er zwingend Microsoft Azure benutzen, also in die Microsoft-Cloud gehen und hier einen individuellen Rahmenvertrag zur Nutzung der Cloud-Dienste mit Microsoft abschließen und bezahlen.
So muss Microsoft also gar nicht mehr unbedingt irgendwelche Verkaufsprovisionen durch den Verkauf von Apps und Spielen im Microsoft Store einkassieren, wie das noch bei UWP-Apps der Fall ist. Dieses Finanzierungskonzept - in Anlehnung an den Apple Appstore - ist nicht mehr notwendig für Microsoft und Windows 10, weil es sich für das Desktop-Betriebssystem nicht am Markt durchgesetzt hat. Weder die App-Entwickler, noch die Windows-Nutzer haben großartig viel Geld im Microsoft Store gelassen und ihn größtenteils ignoriert oder gar komplett am PC blockiert.
Zurück zum Artikel: Microsoft kündigt Project Reunion an und beendet so UWP-Entwicklung für Windows 10
