.NET UI Chaos ... was anwenden?

[KeeperOfCoffee]

Hi,

lange her, dass ich mal einen Thread erstellt habe.

Ich stelle hier nicht konkret eine Frage, sondern bin eher an Meinungen interessiert.

 

Ich werde bald ein neues Projekt beginnen und muss dementsprechende Entscheidungen treffen. Viele unserer alten Projekte sind noch mit WPF umgesetzt, allerdings habe ich auch mit Avalonia mal etwas gespielt. Hier sind allerdings die Skia Libs etwas nervig die mitgeliefert werden müssen und etwas heavy sind.

Die Situation in der .NET UI Landschaft ist etwas chaotisch:

• WPF ist per se am Life-Support. Das GitHub Repo hat die letzten Jahre kaum große Features bekommen, die Roadmap war lange Zeit nicht up-to-date. Das letzte Große Feature  wurde ar ARM64 Support und das open-sourcen des internen WPF Test Repos . Desweiteren wurde ein Großteil des Teams zu anderen Projekten verlegt (WinUI). Sowohl finanzielle Mittel, als auch die Größe des Teams sind bei WPF schwach...es ist in Maintance Mode => on Life Support. Die letzten Commis z.B. waren nur Updates zu WinForms Dependencies. https://github.com/dotnet/wpf/commits/main
• WinForms ist, trotzd des Alters, eine Technologie die wesentlich mehr von MS gestützt wird. Es ist eines der aktivsten Repos von Microsoft. Das Verhältnis von Closed/Open Issues ist wesentlich besser, und in den Commits wird wirklich an Dingen gearbeitet. WinForms wird so schnell nicht verschwinden. https://github.com/dotnet/winforms/commits/main
• MAUI ist ein neues Projekt, wechles Cross Platform fokusiert und Nachfolger von Xamarin.Forms ist. Trotzdem soll es auch aktiv in der Desktop Entwicklung eingesetzt werden. Desweiteren kann man in MAUI natürlich auch Blazor Components hosten bzw. hybride Apps ansteuern. MAUI war für .NET 6 geplant, wurde allerdings delayed und befindet sich jetzt in Preview 10. Es sind noch viele Features geplant, welche aktuell fehlen, weswegen ich sagen würde, dass MAUI für die klassische Desktopentwicklung noch nicht für Production geeignet ist => https://github.com/dotnet/maui/wiki/Roadmap
• Hybride Apps. Diese Projekt ist derzeit noch experimentel. TL;DR ist es eine sog. BlazorWebView Komponente. In dieser könnt ihr eine Blazor Server-Side App hosten (nutzt lokale Ressourcen). Ihr habt also ein Blazor Web Projekt, welches einfach in einem WinForms, WPF, whatever gehostet wird. Desweiteren sind native Features wohl aufrufbar.
• Electron.NET ... ein ASP.NET Core oder Blazor Projekt...oder was auch immer für eine JS Frontend (React, Angular, Vue), welches am Ende electronized wird. Die Frage ist nur ob man das verwenden soll, wenn man auf Blazor setzt.
• UWP ... de facto fallen gelassen imho
  Das WindowsAppSDK wird sich vor allem auf WinUI3 fokusieren. Das SDK wird in 1.0 morgen released => https://portal.productboard.com/winappsdk/1-windows-app-sdk/tabs/2-planned. Wer UWP verwendet, kann dies weiter tun, WinAppSDK unterstützt UWP...langfristig wird aber jeder auf WINUI3 gehen. Das SDK setzt voraus, dass Endkunden mindestens Win10 nutzen.
• WINUI 3 ist Bestandteil des WindowsAppSDK. Ist auf Win10 bzw. Win11 ausgelegt. Bekommt demnächst Unpackaged Support, was bedeutet man ist nicht mehr gezwungen die Anwendung in MSIX zu packen. WINUI3
• UNO Platform => UI Platform für Single Codebase Cross Platform Applications. Kann selbst dazu wenig sagen.

 

Ich bin derzeit unschlüssig. Klar spielt Cross Platform immer eine entscheidende Rolle, aber wir bleiben in der Windows Welt.

Sollte man für neue Desktop Apps auf MAUI warten? WinUI 3?

Arbeite selbst seit Jahren mit WPF, und wenn alles funktioniert ist es super, aber sonst ist es recht mühsam wenn es darum geht etwas schnell zu entwickeln. Desweiteren ist WPF elend langsam.

Ich persönlich denke, dass WPF nur noch da ist, weil MS sich kein Silverlight 2.0 leisten will.

 

Ich bin ziemlich unschlüssig, auf was man im Moment gehen soll, da die Veränderung der UI Landschaft in .NET wohl gerade erst anfängt.

 

[Gast Interrupt]

Hallo,

Zitat

Electron.NET ... ein ASP.NET Core oder Blazor Projekt...oder was auch immer für eine JS Frontend (React, Angular, Vue), welches am Ende electronized wird. Die Frage ist nur ob man das verwenden soll, wenn man auf Blazor setzt.

Wenn du Blazor einsetzt, dann macht der Einsatz eines anderes JS Framework kein Sinn.  Die Idee von Blazor ist ja die Entwicklung eines Frontends in C# ohne dass man eine andere Sprache (z.B. JavaScript) beherrschen muss. 

Ich selbst arbeite derzeit an einer kleinen Blazor Webanwendung die dann später mit Electron dann zur "Desktopanwendung" gemacht wird. Eigentlich eine sehr spannende Technik und hat auch den Vorteil, dass diese Plattformübergreifend ist. Allerdings sollte man mit den Komponenten sehr sparsam sein, da andernfalls die Anwendung sehr langsam wird.

Zu den Rest kann ich leider nicht viel sagen, da ich kein Windows Desktop Entwickler bin.

MfG

Bearbeitet 15. November 2021 von Interrupt

[KeeperOfCoffee]

Hab mich dort unverständlich ausgedrückt. Wollte nur sagen, dass man Blazor auch "electronizen" kann, oder eben jede ASP.NET Core mit JS Framework

[treffnix]

vor einer Stunde schrieb KeeperOfCoffee:

WinForms ist, trotz des Alters, eine Technologie die wesentlich mehr von MS gestützt wird.

Jaa, WinForms! Wuhu! 🎉🎊

Aber um ernst zu bleiben: Ich würde sagen, das hängt davon ab, was das für ein Projekt werden soll? Möchtest du das Risiko eingehen, das die entsprechende UI bald nicht mehr supportet wird? Dann kannst du dich ja getrost "austoben" und eines der neuen Frameworks nutzen, Blazor, WinUI oder MAUI.

Wenn du jetzt schon weißt, das das Projekt ewig laufen wird, würde ich bei WPF oder WinForms bleiben. Ich glaube nicht, das MS WPF sterben lassen wird und WinForms... ist halt WinForms, unsterblich wie Cobol 🤣

[HJST1979]

Ich habe bei meinem letzten "privaten" Projekt auf Angular Frontend mit .NET Core Backend gesetzt. Mittels electron.net habe ich dann eine "normale" Windows-Anwendung. Aber natürlich reagiert diese wie eine Web-Anwendung. Das bedeutet hast du viel mit Dateien zu tun oder die Anzeige dieser ist dies evtl. nicht ganz so einfach wie in einer WinForms-Anwendung.

Ob das im "professionellen" Umfeld sinnvoll ist, kann ich nicht zu 100% beantworten.

[daluqi]

Avalonia finde ich auch spannend, und es scheint sich immer weiter zu professionalisieren. Inzwischen sind wohl auch einige größere Firmen da aufgesprungen, unter anderem Jetbrains - und ich denke die wissen was sie tun. Auch die Homepage sah anfangs aus wie die eines kleinen 08/15 Open-Source-Projektes, gibt sich aber jetzt ganz schön selbstbewusst: https://avaloniaui.net/

Bearbeitet 1. April 2022 von daluqi

[KeeperOfCoffee]

Ja ich habe Avalonia schon genutzt. Denke allerdings, dass es schwierig wird, wenn sie sich gegen MAUI behaupten müssen. Vermutlich wird man darauf hinarbeiten, dass in Avalonia in bestimmten Situationen besser ist und MAUI in anderen. Die Schwerpunkte der beiden Projekte werden sich wohl sicher bald stärker unterscheiden.

Zuminderst läuft man bei Avalonia nicht in die Gefahr, dass es ein Siverlight 2.0 oder UWP wird

[daluqi]

Ein Nachteil von MAUI ist wohl, dass es scheinbar nicht auf Linux läuft: 

[KeeperOfCoffee]

Überrascht mich nicht, MAUI ist aus Xamarin entstanden. Es ist sehr aufwändig Linux zu unterstützen, da man ja viele Desktops unterstützen muss z.B. GTK für den Gnome Desktop etc. Dies ist eine andere Hausnummer, als Android.

[DeveloperX]

Es gibt eine Linux Version die von der Community entwickelt wird. Microsoft selber sieht es scheinbar nicht als rentabel an Linux offiziell zu unterstützen. 

[DevcouchPodcast]

Schwer zu sagen ohne die genauen Anforderungen zu kennen.

Ich würde erstmal alles versuchen, um keine Windows-Desktop Anwendung schreiben zu müssen. Es gibt ja mit modernen Web-Frameworks kaum noch Gründe für reine Desktop-Anwendungen.

Wenn es unbedingt ein Desktop-Client sein muss, würde ich so viel Logik wie möglich in einen Backend-Service packen und den Client möglichst dumm halten.

Ich würde WinForms ausschließen, weil die Testbarkeit nicht gut ist.

Ich würde WPF ausschließen, weil mir persönlich MVVM nicht gefällt und ich den Aufwand, den man für schöne und moderne WPF-Anwendungen betreiben muss, für zu hoch halte. (DataBindingConverters, globalisierung, RTL Support, Storyboards - das ist unter WPF alles eine Frechheit).

Xamarin.Forms für Desktop setzt auf UWP und die WPF Anbindung ist nicht gut., UWP ist raus, Maui noch nicht fertig..tja - ich weiß auch nicht.

 

Bearbeitet 13. April 2022 von DevcouchPodcast

[Gast D-eath]

MAUI hat nun einen RC.

[spix]

Mal schauen ob MAUI nicht wieder so eine  Totgeburt wird wie UWP und MS Mobile etc . Ansonsten würde ich eher auf WinForms setzen.  WPF ist ja ganz putzig, aber der Aufwand einfach nervig.