Anzeige

Am Puls von Microsoft

Anzeige

UWP: Microsoft schiebt die Universal Apps offiziell aufs Abstellgleis

DrWindows

Redaktion
UWP: Microsoft schiebt die Universal Apps offiziell aufs Abstellgleis
von Kevin Kozuszek
Universal Windows Plattform UWP


Dass Microsoft mit Project Reunion eine zentrale Basis für alle künftigen Windows-Apps am Desktop umsetzt und die Fähigkeiten der Universal Windows Platform hier einfließen werden, ist schon seit längerer Zeit bekannt. Mit dem Windows App SDK und WinUI 3.0 stehen im Zusammenspiel mit anderen Technologien wie WebView 2 schon länger die entsprechenden Mittel für klassische Desktop-Anwendungen zur Verfügung. Unklar war bisher aber noch, wie es mit den klassischen UWP-Apps, die mit Windows 10 eingeführt wurden, weitergehen wird.

Mit einem neuen Dokument auf GitHub schafft Microsoft hier nun Klarheit. Während es zuletzt mit WinUI 2.6 und 2.7 zwei Updates des älteren Toolkits gab, welche entsprechende Elemente aus Windows 11 wie den Mica-Effekt integrieren, wurde auch WebView 2 für UWP-Apps kürzlich in die Preview geschickt. Im weiteren Verlauf wechselt das alte Toolkit aber im Wesentlichen in den Wartungsmodus. WinUI 2.x und das Windows SDK werden zwar weiter unterstützt, aber das vor allem noch mit Bugfixes sowie Stabilitäts- und Sicherheitsupdates.

Wichtig ist aber, dass eine Unterstützung für .NET 5 und neuere Versionen nicht mehr kommen wird, ebenso werden klassische Universal Apps das moderne Windows App SDK nicht nutzen können. Brauchen Entwickler Funktionen aus den moderneren .NET-Versionen, müssen sie ihre Universal Apps in ein WinUI 3.0 Desktop Project umwandeln. Eine kleine Anleitung zur Migration stellt Microsoft im entsprechenden Dokument bereit. Sollte es noch Blocker für eine eigene Migration geben, bittet Microsoft an dieser Stelle um entsprechende Rückmeldungen.

Damit wird jetzt noch eine andere Frage in den kommenden Monaten sehr spannend. Die Unterstützung für .NET Core 3.1 läuft nach derzeitigem Stand im Dezember 2022 aus. Microsoft wird also entweder die Unterstützung ähnlich wie beim .NET Framework auf unbestimmte Zeit verlängern müssen oder sie setzen auf sanften Druck und hoffen, dass möglichst viele der verbliebenen UWP-Entwickler den Sprung zum klassischen Desktop-Projekt und WinUI 3.0 bis Ende kommenden Jahres vollziehen.


Hinweis: Der Artikel wird möglicherweise nicht vollständig angezeigt, eingebettete Medien sind in dieser Vorschau beispielsweise nicht zu sehen.

Artikel im Blog lesen
 
Anzeige
Das leidige Thema Windows und Apps.
Ich verstehe es nicht.
Mittlerweile nutze ich Windows nur noch für ein paar Programme, der Rest ist mir zu mühselig geworden.
 
Musst du ja auch nicht, wenn du kein Entwickler bist und gleichzeitig mit der Migration Probleme hättest. Selbst meine Uralt-Programm laufen noch unter Windows 11 ohne Anpassung, und lassen sich auch mit dem modernsten Visual Studio compilieren. Probiere das mal mit PHP oder anderen Script-Kiddy-Plattformen...
 
Das erwartet und muss keiner. Aber seit HTML5 entwickelt man Oberflächen eh lieber mit Web-Technologien, und immer mehr Client Server. Auch dazu ist .NET perfekt geeignet.
 
Musst du ja auch nicht, wenn du kein Entwickler bist und gleichzeitig mit der Migration Probleme hättest. Selbst meine Uralt-Programm laufen noch unter Windows 11 ohne Anpassung, und lassen sich auch mit dem modernsten Visual Studio compilieren. Probiere das mal mit PHP oder anderen Script-Kiddy-Plattformen...
Man steht halt auf der Stelle.
 
Wie das? Eben genau nicht, wenn man mit der Zeit geht. Vor 10 Jahren z. B. war SOAP state of the art, heute ganz andere Technologien wie REST. Deswegen haben meine Großprojekte eben ältere immer noch bestens funktionierende Schnittstellen mit SOAP, die jüngeren Schnittstellen in denselben Systemen nutzen REST mit Swagger. Aber dazu müsste man Entwickler sein, um diese Vorzüge schätzen zu wissen in der Microsoft-, aber auch JavaScript-Welt, und alles innerhalb derselben Solution-Datei... Nur Meckern und Jammern geht auch so.
 
Sorry, aber dafür bin ich zu wenig Entwickler, also gar nicht. 😅
Für mich steht Windows was Apps angeht auf der Stelle, egal ob Windows 10 oder 11.
Das "mittlerweile öde" System mit Programmen als EXE-Datei.
Aber vielleicht ändert sich das ja mit den Android-Apps.
 
Puh, das ganze ist mehr als traurig. Bis ich meine Anwendung aber auf WPF ziehe, wird es noch lange dauern. Wenn man wie ich mit WPF gestartet ist, dann bei Windows Phone mit Silverlight Apps angefangen hat, später auf WinRT/UWP wechseln musste und dann wieder auf WPF wechselt, schließt sich der Kreis 😵.
 
Nutzt einfach nur Win32 und ihr habt keine Probleme.
Alles andere landet schnell mal auf dem Abstellgleis. Sollte mittlerweile auch der letzte verstanden haben.

Eigentlich trauere ich UWP nichts nach, ist nur blöd für die Xbox, denn dort ist nichts anderes erlaubt. Oder hat sich da was geändert?
Der neue Edge ist ja kein klassisches UWP sondern mehr Win32. Aber auch ein Programm von MS und nicht von dritten.


Aber seit HTML5 entwickelt man Oberflächen eh lieber mit Web-Technologien,
Leider. Langsam, resourcenfressend, und oftmals nicht-nativer Look.




Winui performances and resources usage are behind UWP
Unfortunately I have to agree on this, just take a look at windows 11 built-in widgets and chat, they use around 300mb of ram each (web tech) , as much as visual studio!

Ich habe den Eindruck, seit Mobile tot ist, ist MS der Resourcenverbrauch von Windows wieder ziemlich egal :(.
 
Zuletzt bearbeitet:
Unklar war bisher aber noch, wie es mit den klassischen UWP-Apps, die mit Windows 10 eingeführt wurden, weitergehen wird.

Die UWP-Apps wurden mit Windows 8 eingeführt. Dort hießen sie aber Metro und Modern UI. Außerdem waren sie im Vollbildmodus. Bzw. konnten nebeneinander gelegt werden. Und der Desktop war dort dann auch nur einer der Anwendungen.

Mit Windows 10 wurden dann lediglich die UWP-Apps als Fenster auf den Desktop gebracht, sofern man nicht den Tablet-Mode einschaltete.
 
Nachvollziehar. Der Aufwand den Code anzupassen wird für die UWPler in der Regel auch geringer sein als für die WPFler umgekehrt ihre Programme ins WinUI zu überführen.

Aber: das InkCanvas etc. in WinUI 3 / WindowsApp SDK 1.0 fehlt ist wohl ein schlechter Witz.

Das erwartet und muss keiner. Aber seit HTML5 entwickelt man Oberflächen eh lieber mit Web-Technologien, und immer mehr Client Server. Auch dazu ist .NET perfekt geeignet.

Mit HTML/CSS/JS ist das schlechteste aller Welten vereint. Hat nur einen einzigen Vorteil: Crossplatform zum geringsten Preis - für die Entwickler.

Für mich steht Windows was Apps angeht auf der Stelle, egal ob Windows 10 oder 11.
Das "mittlerweile öde" System mit Programmen als EXE-Datei.
Aber vielleicht ändert sich das ja mit den Android-Apps.

Nicht Dein Ernst oder? Mit Android Apps auf W11 wird es sich wie mit WebApps verhalten - man benutzt die halt weil nichts anderes da ist... .

An .exe Dateien ist erstmal grundsätzlich nichts falsch, die schlimmsten Probleme aus Anwendersicht werden ja mit dem .msix Paketen gelöst.

Wie das? Eben genau nicht, wenn man mit der Zeit geht. Vor 10 Jahren z. B. war SOAP state of the art, heute ganz andere Technologien wie REST.

REST dürfte seit ca. 20 Jahren "in" sein. Wie die Zeit vergeht...

Probiere das mal mit PHP oder anderen Script-Kiddy-Plattformen...

Spätestens wenn bei den Scriptsprachen die bevorzugte Major-Version keine Sicherheitsupdates mehr bekommt ist da mehr oder weniger viel Arbeit für die Entwickler angesagt.

Auf der Unix-Seite hat man das Problem das verschiedene Anwendungen verschiedene Versionen benötigen mit den Containern gelöst.

Wenn nun auf Windows jedes Programm/App sein eigenes WinUI und amdere Microsoft Libraries mitbringen kann ist schon mal ein guter Schritt in die richtige Richtung aus der "DLL Hölle". Das dies nicht "ganz optimal" in Sachen RAM-Verbrauch und bei manchen Benutzern auch SSD sein wird, mal schauen was Microsoft dazu noch alles einfällt...

Insgesamt gesehen soll mit der ersten Version vom WindwosApp SDK wohl den WPFlern etc. das aufhübschen ihrer Programme schmackhaft gemacht werden.

Ein paar Probleme werden für UWPler ja auch gelöst (nur ein Fenster), aber für viele fehlt da existentielles wie Ink.

Und die Lösung der wirklichen Probleme von WinUI/UWP steht weiterhin aus: die Open/Save Dialoge. Das wird eine Baustelle für Microsoft die so in Richtung "Windows 21" gehen kann. Falls sie überhaupt jemals aufgemacht wird...
 
Und da wundert man sich, dass nicht mehr Apps für Windows entwickelt werden. Es kann halt nichts werden, wenn man alle paar Minuten die Technologien und Strategien ändert und gleichzeitig erwartet, dass alle sofort auf das neue Pferd aufspringen...

Die grossen Projekte wechseln eh nicht die benutzten Technologien, deswegen gibts ja die XAML Islands damit man WinUI in die vorsichtig "reinbekommt" wo es Sinn macht.

Firmen werden neue Client/Server Projekte für den Browser entwickeln, weil da zu 99% die Datenverarbeitung den Gewinn macht, nicht das die Anwender ein besseres UI mit neuen Möglichkeiten haben.

Und genau DA liegt der Hase begraben: wo ist der Vorteil von Windows Apps? Ink und Touchbedienung. Aber das wars dann leider schon.

Was fehlt ist ein neues Paradigma für den Desktop. Im Endeffekt ist Mobile und Web ja "Desktop-Light". Und holt dank mehr CPU/GPU Power halt auf.

Der Desktop hingehen muss sich um weiter bestehen zu können schlichtweg weiterentwickeln. Die Sachen machen und Technologien anbieten die eben mit Mobile und Web nicht möglich sind.

Solange da Microsoft Stategien und Technoligien anbietet die da "nichts bringen" machen die Entwickler nicht massenhaft mit. Deswegen der häufige Wechsel und "Schlingerkurs" den die Entwickler "aussitzen"..

Aber wenn eine entsprechende Vision da ist und vermittelt werden kann sieht das ganz anders aus..

Kleiner Trost: bei Apple siehts auch nicht besser aus. Die letzte grosse Erfindung sind die Sheets - in MacOS X 10.0 .

Apple hat das "Desktop-Problem" für sich dahingehend gelöst das man iOS hat - sprich: Desktop ist nicht mehr wirklich.

Microsofts-Lösung scheint Azure zu sein.

Anscheinend fehlt beiden ein neues Xerox PARC wo man sich "bedienen" kann. Und wenn das Linux sein wird, dann ist das Pech für beide. Denn mit "Umsonst" kann man im Gegensatz zur Xerox Star nicht wirklich konkurrieren...
 
Zuletzt bearbeitet:
Und wieder ein Grabstein auf dem „Friedhof der Kuscheltiere“. Müßig darüber noch Worte zu verlieren. Das ist nicht der erste ehemalige Superstar, der dort landet. Er befindet sich dort in „bester“ Gesellschaft. Zusammen mit Windows Phone und Cortana können die wenigstens Skat spielen.
 
Das ist alles viel zu verwirrend. Wenn WinUI3 jetzt für alles genutzt werden soll, wieso hat es noch nicht die Style-Updates für Win11 bekommen, obwohl Win11 releast ist?
 
Wichtig ist aber, dass eine Unterstützung für .NET 5 und neuere Versionen nicht mehr kommen wird, ebenso werden klassische Universal Apps das moderne Windows App SDK nicht nutzen können.

Das was Microsoft mit .NET unter Windows macht, finde ich den Oberhammer.
Klar, UWP wird nicht auf .NET 5 oder neuer portiert.
Es ist aber so, dass zumindest bei Win10 21H1
- .NET Framework 4.8 vorinstalliert ist (aktuell existiert aber .NET 5.0.11 und 6.0 RC 2 als Vorabversion)
- Windows PowerShell 5.1.19041.1237 installiert ist (aktuell existiert jedoch PowerShell 7.1.5 und 7.2 existiert als Preview)
- C# 5 Compiler in der Version 4.8.4084.0 (aktuell existiert jedoch Version 9.0)
- Visual Basic 2012 Compiler in der Version 14.8.4084 (aktuell existiert jedoch Version 16)
- .. etc.

Und schon bei Windows 8.1, das 2013 rauskam, wurde beim Aufruf der Compiler gesagt, dass der Compiler veraltet ist und ein Link zum aktuellen Compiler gesetzt..

Hier mal die Ausgabe auf Win10:

PS C:\Users\theuserbl> C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe Microsoft (R) Visual C# Compiler version 4.8.4084.0 for C# 5 Copyright (C) Microsoft Corporation. All rights reserved. This compiler is provided as part of the Microsoft (R) .NET Framework, but only supports language versions up to C# 5, which is no longer the latest version. For compilers that support newer versions of the C# programming language, see http://go.microsoft.com/fwlink/?LinkID=533240 warning CS2008: Es wurden keine Quelldateien angegeben. error CS1562: Für Ausgaben ohne Quelle muss die Option /out angeben werden. PS C:\Users\theuserbl>

Ich habe es bisher noch nirgendwo anders erlebt, dass ein aktuelles Betriebssystem mit seit acht Jahren veralteter Software daherkommt, zu der der Hersteller schon längst selber neuere Versionen veröffentlicht hat.
Merkt man auch sehr schön an der PowerShell, wenn man

Get-ChildItem C:\Windows\System32

eingibt. Das dauert bei der vorinstallierten Windows PowerShell 5.1 eine halbe Ewigkeit, bis es fertig ist.
Bei der PowerShell 7.1.5 ist es hingegen zügig durchgelaufen.

Windows Forms und Windows Presentation Foundation hatte Microsoft doch auch auf .NET 5 portiert und ebenfalls unter die MIT-Lizenz gestellt. Und zumindest diese Windows Forms laufen auch unter Linux mit WINE.

Warum portiert nicht Microsoft alles, was unter Windows auf .NET aufbaut, auf .NET 5 oder .NET 6?
Stattdessen liefern sie - wie ich schon schrieb - mit ihrem Betriebssystem alte Software mit, obwohl es neuere Versionen gibt.

Grüße
theuserbl
 
Zuletzt bearbeitet:
Vermutlich weil einige Anwendungen diese Version vielleicht unbedingt benötigen, Downgrades nicht angeraten/möglich sind, die Updates/Upgrades aber ohnehin automatisch per Windows Updates kommen.
In einer sauberen leeren Windows-10-Test-VM, die ich lediglich über Windows Updates aktuell halte, ist z. B. .NET 4.8 installiert, nicht jedoch die Versionen <=3.5.
Und wenn du selbst Skripte betreiben möchtest, die neuere PowerShell-Features nutzen, steht es dir frei, die jeweils neueste Version mit einem Einzeiler zu installieren: How to Install or Update PowerShell to the Latest Version in Windows 10 | ITIGIC
 
Also Benutzer sieht man bei .NET vor allem:

Es gibt immer wieder neue Versionen, die nicht abwärtskompatibel sind.
 
Anzeige
Oben