Ich war vor einigen Jahren auf Ihrer Frustrationsebene, als ich zum ersten Mal mit der Portierung über WPF-Apps begann. Also ich verstehe deine Gefühle auf jeden Fall. Seitdem gab es einige Fortschritte und wie Sie sagten, versucht das WinUI-Team wirklich alles.

Aus meiner Sicht gibt es ein grundlegendes Designproblem, das wir nicht umgehen können: WinRT war technisch behindert, weil es direkt mit C++ und JavaScript interoperieren muss ( hier ist ein Beispiel und ein anderes ). Es passt auch nicht gut zu vielen der High-Level-Konzepte, wie zum Beispiel Generika. Natürlich gibt es auch bei dieser Architektur einen großen Vorteil: Alle Windows können jetzt die gleichen WinRT-APIs verwenden.

WinRT wurde auch vom Windows-Team unter Sinofsky erstellt, was bedeutet, dass sie in ihrer eigenen Welt lebten und keine Erfahrung mit der Arbeit mit dem bestehenden Endbenutzer-Entwickler-Ökosystem hatten. Am Ende hatten wir eine API mit dem kleinsten gemeinsamen Nenner, mit der sowohl native als auch verwaltete Entwickler nicht gerne arbeiten. Dies ist im Wesentlichen einer der Hauptgründe für den Tod von Windows Phone – Entwickler konnten Apps nicht einfach entwickeln/portieren. Ohne Apps keine Kunden. Microsoft hat diese Lektion gelernt.

Wir haben also einige der Vorteile von verwaltetem Code verloren, an die wir uns im Laufe der Jahre gewöhnt haben. Es scheint definitiv immer noch ein Schritt zurück von WPF zu sein - ich finde ständig Fehler und unvollständige Funktionen. Ich denke, #1830 würde in den WPF-Tagen nie passieren. Wir müssen noch irgendwie vorankommen.

WinUI 3.0 ist eindeutig ein Schritt in die richtige Richtung, um dies zumindest im Frontend zu beheben. Ich würde es jedoch vorziehen, dass Microsoft einen robusteren Entwicklungsprozess und mehr Tests implementiert, bevor neue Steuerelemente veröffentlicht werden ... Ich weiß, dass Entwicklung jetzt Änderungen durchschieben und später beheben wird. Das mag für Apps funktionieren, ist aber kein gutes Muster für eine Plattform, auf der es sehr schwer ist, sie später zu ändern, sobald die Dinge festgelegt sind. (TreeView, NumberBox usw. haben so viele Probleme bei der ersten Veröffentlichung, die vor 15 Jahren nie aus der Tür kommen würden, geschweige denn Planungsphasen).

Es ist traurig für mich zu sehen, wie sich die einst leistungsstärkste UI-Plattform WPF zu dieser entwickelt. Aber Microsoft hört jetzt langsam aber sicher auf Feedback und repariert Dinge. Es ist klar, dass noch viel zu tun ist.

Glauben Sie, dass die Benutzer das oben Genannte gerne tun werden? Nein, das werden sie nicht – tatsächlich tun es 79,8 % nicht (meine AppCenter-Daten belegen dies). Ich lasse mich entweder mit Benutzern zurück, die meine App nicht verwenden, oder meine App sieht einfach im Vergleich zu anderen nativen Apps unterdurchschnittlich aus.

Vielleicht denken Sie nicht daran, dass Ihre Benutzer tatsächlich innehalten, um zu denken: "Warte, möchte ich dieser App wirklich Zugriff auf mein gesamtes Laufwerk gewähren?" Dies ist eine Rotlichtwarnung für Personen, die mit der App/dem Entwickler/dem Unternehmen nicht vertraut sind.

Sie geben dem Prozess, den Benutzer durchlaufen müssen, um Ihrer App Zugriff auf ihr gesamtes Laufwerk zu gewähren, die Schuld für die niedrige Aufbewahrungsrate. Vielleicht sollten Sie Ihre "Bedürfnisse" für broadFileSystemAccess erst einmal überdenken und die Benutzer lieber manuell die Ordner auswählen lassen, auf die sie sich wohl fühlen.

Zu Ihrer Information, wenn ich eine App ausprobieren wollte und nach der Installation hieß es "Hey, gib mir die Erlaubnis, überall auf alles zuzugreifen", würde ich auch laufen.

Wenn Sie broadSystemAccess anfordern, verfügt Ihre Anwendung standardmäßig nicht über diesen Zugriff.

Offensichtlich... Sie haben nur eine Anfrage gestellt, Ihre Benutzer müssen Ihnen den Zugriff tatsächlich gewähren, wenn sie sich dabei wohl fühlen.

Auch aufgrund des respektlosen Titels, der gegen den Microsoft Open Source Code of Conduct verstößt, und des Inhalts, der sich nicht auf WinUI bezieht, sollte dieses Problem geschlossen werden. @jevansaks @jesbis

Eine letzte Sache noch hinzuzufügen. Ich denke, Rich Lander hat es beim .NET Community Standup am

@verelpode Sie fahren die im obigen Video erwähnte Linie, bleiben aber größtenteils konstruktiv und beim Thema, daher schätze ich Ihre Beiträge zum WinUI-Repo - auch wenn Sie manchmal der Meinung sind, dass sie fruchtlos sind, wie ich in Ihrem letzten gesehen habe Kommentare).

Wenn Sie broadSystemAccess anfordern, verfügt Ihre Anwendung standardmäßig nicht über diesen Zugriff.

Offensichtlich... Sie haben nur eine Anfrage gestellt, Ihre Benutzer müssen Ihnen den Zugriff tatsächlich gewähren, wenn sie sich dabei wohl fühlen.

Das ist nicht das Problem: Zumindest auf Android/iOS werden Sie danach gefragt, während Ihre App versucht, auf die Festplatte zuzugreifen, und sie wird nicht geschlossen , wie in unserem Fall.

Ihre App würde nicht geschlossen, wenn Sie Dateiauswahl(er) präsentieren, mit denen der Benutzer auswählen kann, worauf er Ihrer App Zugriff gewähren möchte.

Stattdessen wollen Sie alles, beschweren sich über einen kleinen einmaligen zusätzlichen Schritt, den die Benutzer unternehmen müssen, und geben Ihrer Bindungsrate die Schuld an diesem Schritt.

Auch aufgrund des respektlosen Titels, der gegen den Microsoft Open Source Code of Conduct verstößt, und des Inhalts, der sich nicht auf WinUI bezieht, sollte dieses Problem geschlossen werden. @jevansaks @jesbis

Es ist wirklich schwer, respektvoll zu sein, wenn ich fast den Verstand verliere. Um nicht zu sagen - ich habe dies schon einmal gesagt, es gibt keinen Platz, um über WinRT zu schreiben. Ich würde gerne einen anderen Ton verwenden, wenn ich wirklich schreiben könnte und jemand würde zuhören. Alle oben genannten Schreie sollten einfach nicht existieren - WinRT sollte ausgereift genug sein . Noch kein...

Wo kann die Community eigentlich mit dem WinRT-Team sprechen? Hört jemand zu?

Ihre App würde nicht geschlossen, wenn Sie Dateiauswahl(er) präsentieren, mit denen der Benutzer auswählen kann, worauf er Ihrer App Zugriff gewähren möchte.

Stattdessen wollen Sie alles, beschweren sich über einen kleinen einmaligen zusätzlichen Schritt, den die Benutzer unternehmen müssen, und geben Ihrer Bindungsrate die Schuld an diesem Schritt.

Meine App ermöglicht es Benutzern, Fotos und Videos zu bearbeiten, und ich möchte, dass der Benutzer eine einfache Vorschau nach Belieben ermöglicht und nicht eine Dateiauswahl im alten Stil verwendet. Also ja, es ist wirklich wichtig, dass ich auf alle Festplatten zugreifen kann. Und nein, diese virtuellen Ordner "Bilder" und "Videos" sind das, was Microsoft denkt, dass Benutzer ihre Fotos und Videos aufbewahren. Das ist nicht die Realität.

Ich habe dies schon einmal gesagt, es gibt keinen Platz, um über WinRT zu schreiben.

Wie aus Ihren Links hervorgeht, haben Sie bereits in den UWP-Q&A-Foren über WinRT geschimpft, wohin Sie weitergeleitet wurden.

Wenn Sie also hier posten, möchten Sie anscheinend nur ein größeres Publikum, anstatt tatsächlich etwas zu erreichen (da das WinUI-Team nicht an WinRT arbeitet).

Wie aus Ihren Links hervorgeht, haben Sie bereits in den UWP-Q&A-Foren über WinRT geschimpft, wohin Sie weitergeleitet wurden.

Es gibt jedoch keine Lösung für eines meiner Probleme. Bei einem Q & A stellen Sie Fragen und erhalten Antworten. Aber man kann (leider) nicht wirklich etwas zum Ändern vorschlagen.

Meine App ermöglicht es Benutzern, Fotos und Videos zu bearbeiten, und ich möchte, dass der Benutzer eine einfache Vorschau nach Belieben ermöglicht und nicht eine Dateiauswahl im alten Stil verwendet. Also ja, es ist wirklich wichtig, dass ich auf alle Festplatten zugreifen kann.

Nein, ist es nicht. Ihre Benutzer haben nicht überall auf dem Laufwerk Fotos und Videos, sie befinden sich an bestimmten Orten, die möglicherweise nicht die speziellen Ordner sind.

Lassen Sie die Benutzer diese Ordner einmal auswählen, dann haben Sie jederzeit Zugriff über die

@kmgallahan Sicher, der Ton kann etwas zurückgenommen werden, aber wir waren alle schon einmal frustriert. Noch frustrierender ist der Gedanke, dass offensichtliche Probleme nicht angegangen werden. Ich denke, es ist manchmal konstruktiv, dieser Frustration in einem Forum Luft zu machen, in dem die Leute sie validieren und auch mögliche Lösungen anbieten können. Seine technischen Punkte sind gültig, es ist nur für WinRT und ein bisschen UWP - beides nicht WinUI XAML-Steuerelemente, die dieses Repository darstellt. Aus diesem Grund sollte dies wahrscheinlich als Off-Topic geschlossen werden.

Ich denke, wir können diese Art von Diskussionen professionell halten, da sie wissen, dass sie aus Frustration und großem Interesse am Erfolg des Entwicklungsökosystems stammen.

Sicher, der Ton kann ein wenig zurückgenommen werden, aber wir waren alle schon einmal frustriert. Noch frustrierender ist der Gedanke, dass offensichtliche Probleme nicht angegangen werden.

Vielen Dank :)

Nein, ist es nicht. Ihre Benutzer haben nicht überall auf dem Laufwerk Fotos und Videos, sie befinden sich an bestimmten Orten, die möglicherweise nicht die speziellen Ordner sind.

Lassen Sie die Benutzer diese Ordner einmal auswählen, dann haben Sie jederzeit Zugriff über die

Offensichtlich befinden sie sich nicht an diesen bestimmten Orten....

Sicher, ich kann diese FutureAccessList verwenden und die Benutzer daran erinnern, wo sie ihre Fotos/Videos aufbewahren, denn wir alle wissen, wo wir alle unsere Fotos/Videos aufbewahren, oder?

Anstatt (was meine App tut) eine schöne Vorschau von Ordnern anzuzeigen und Ihnen die Ordner anzuzeigen, in denen Sie Fotos/Videos haben.

Ein paar Anmerkungen:

Danke @jtorjo, dass du dir die Zeit genommen hast, über deine Erfahrungen und dein Feedback zu schreiben, und auch für deine Zeit auf der Q&A-Seite .

Wie @robloo und @kmgallahan bereits erwähnt haben, hat das meiste davon nicht direkt mit WinUI zu tun und Sie können den Verhaltenskodex ein wenig vorantreiben 🙂

Wir erkennen jedoch auch an, dass das Engagement auf der Q&A-Site und dem Feedback-Hub in Bezug auf verschiedene Bereiche der Windows-Entwicklerplattform besser sein könnte. Wir versuchen wirklich aktiv, das zu verbessern, aber ich verstehe, dass es frustrierend ist, einen guten Ort zu finden, um Feedback zu geben und zu sehen, ob etwas passiert.

Zum Beispiel sehen wir wirklich alles, was über den Feedback Hub kommt, aber es gibt keine gute Möglichkeit, zu antworten oder eine Diskussion fortzusetzen. Solange es also konstruktiv bleibt und sich auf die UX/Entwicklung von Windows-Apps bezieht, können wir hier allgemeines Feedback zur Plattform diskutieren, wenn ein Thema derzeit an anderer Stelle nicht gut passt.

Für was es wert ist, erhalten diese Themen auch ernsthafte interne Aufmerksamkeit. Wir haben heute einige WinRT-Experten kontaktiert, um zu erfahren, ob es in diesen Bereichen Updates gibt, die wir teilen können, da Sie einige der wichtigsten Probleme mit der gesamten Plattform und den Tools sauber zusammengefasst haben.

Für die Entwicklung von Desktop-Apps: WinUI 3 ist ein großer Teil unserer Bemühungen, die Windows-Entwicklerplattform zu entkoppeln, um diese Interoperabilitätsbarrieren zu beseitigen und die schrittweise Einführung von WinUI und UWP zu erleichtern. Wir wissen, dass wir Desktop-Apps mit moderner UX besser aktivieren müssen, ohne alle aktuellen Einschränkungen zu erfordern. Wir haben viele Experten, darunter einige der wichtigsten Entwickler von WPF, die daran arbeiten.

Insbesondere verbringen wir viel Zeit auf Xaml-Inseln und auf WinUI für Desktop-Apps und freuen uns auf den nächsten Schritt, der eine Vorschau davon veröffentlichen wird, die später in diesem Jahr ausprobiert werden kann. Wir versuchen, Feedback-orientierter und transparenter zu sein, und das sollte einfacher werden, wenn wir Dinge wie die vollständige Xaml-Plattform (dh WinUI 3) auf Open Source umstellen.

Wenn die Leute sich für den aktuellen Stand der Desktop-Pläne interessieren, könnten wir auch in einem der monatlichen Community Calls etwas näher darauf eingehen – hier könnt ihr gerne Themen vorschlagen:

WinUI Community Call (22. Januar 2020) #1857

Hallo @jesbis ,

Danke für das Betrachten meiner Probleme!

Wie @robloo und @kmgallahan bereits erwähnt haben, hat das meiste davon nicht direkt mit WinUI zu tun und Sie können den Verhaltenskodex ein wenig vorantreiben 🙂

Ja, das tut mir wirklich leid, ich hatte nur das Gefühl, ich würde den Verstand verlieren. Die Dinge, die ich hier erwähnt habe, sind entscheidend - ich bin wirklich leidenschaftlich dabei, da ich auf alle oben genannten Dinge gestoßen bin. Sie alle fordern einen enormen Tribut, viele Leute geben einfach auf, es zu versuchen.

Wir erkennen jedoch auch an, dass das Engagement auf der Q&A-Site und dem Feedback-Hub in Bezug auf verschiedene Bereiche der Windows-Entwicklerplattform besser sein könnte. Wir versuchen wirklich aktiv, das zu verbessern, aber ich verstehe, dass es frustrierend ist, einen guten Ort zu finden, um Feedback zu geben und zu sehen, ob etwas passiert.

Total einverstanden. Als Randnotiz habe ich tatsächlich versucht, den broadSystemAccess auf Feedback Hub zu melden, und nachdem ich alle Details angegeben und etwa 15 Minuten damit verbracht hatte, drückte ich wahrscheinlich irgendwie einen Hotkey, der "Zurück" entsprach - also Ich habe meine gesamte Arbeit verloren (kein Rückgängigmachen, kein Text wird in die Zwischenablage kopiert, nichts). Offensichtlich war ich wahnsinnig frustriert und gab einfach auf.

Für was es wert ist, erhalten diese Themen auch ernsthafte interne Aufmerksamkeit. Wir haben heute einige WinRT-Experten kontaktiert, um zu erfahren, ob es in diesen Bereichen Updates gibt, die wir teilen können, da Sie einige der wichtigsten Probleme mit der gesamten Plattform und den Tools sauber zusammengefasst haben.

Cool!

Für die Entwicklung von Desktop-Apps: WinUI 3 ist ein großer Teil unserer Bemühungen, die Windows-Entwicklerplattform zu entkoppeln, um diese Interoperabilitätsbarrieren zu beseitigen und die schrittweise Einführung von WinUI und UWP zu erleichtern. Wir wissen, dass wir Desktop-Apps mit moderner UX besser aktivieren müssen, ohne alle aktuellen Einschränkungen zu erfordern. Wir haben viele Experten, darunter einige der wichtigsten Entwickler von WPF, die daran arbeiten.

Das ist toll! Ich freue mich auf jeden Fall noch mehr darauf. Es ist sehr wahrscheinlich, dass ich meine App aktualisieren werde, sobald dies erledigt ist, aber bis dahin stecke ich mit vielen Problemen fest.

Wenn die Leute sich für den aktuellen Stand der Desktop-Pläne interessieren, könnten wir auch in einem der monatlichen Community Calls etwas näher darauf eingehen – hier könnt ihr gerne Themen vorschlagen:

WinUI Community Call (22. Januar 2020) #1857

Kann ich die hier erwähnten WinRT-Themen vorschlagen?

Danke noch einmal!

Zum Beispiel sehen wir wirklich alles, was über den Feedback Hub kommt, aber es gibt keine gute Möglichkeit, zu antworten oder eine Diskussion fortzusetzen. Solange es also konstruktiv bleibt und mit der App-Entwicklung zu tun hat, können wir hier allgemeines Feedback zur Plattform aufnehmen, wenn ein Thema derzeit an anderer Stelle nicht gut passt.

@jesbis
Das sind gute Nachrichten! Vielen Dank an das WinUI-Team, um diese Flexibilität zu zeigen und zu versuchen, die (wahrgenommenen) WinRT-Feedback-Systemprobleme zu mildern, obwohl sie es nicht müssen!

@kmgallahan

Ich denke, Rich Lander hat es beim .NET Community Standup am 15. Januar (ab 01.12.40 Uhr) am besten gesagt.

So sagt Rich Lander dort, dass er Menschen mit ein wenig Aggression, aber gleichzeitig netten bevorzugt. Ich denke, eines der größten Probleme in der Gesellschaft ist, dass viele Menschen so sehr "höflich" sind, dass ihr Verhalten extremistisch wird und in Respektlosigkeit und Unhöflichkeit umschlägt, während sie oberflächlich "höflich" erscheinen. Sehr "höfliche" Menschen sprechen indirekt und vage, was ihre Kommunikation schwer verständlich und leicht fehlinterpretiert. Sehr "höfliche" Menschen sind respektlos und unhöflich, weil sie effektiv das Äquivalent von sagen:

"Ich glaube, dass Sie mit der direkten Wahrheit nicht umgehen können, deshalb werde ich Sie mit dicken, flauschigen Baumwollhandschuhen anfassen und Sie in Luftpolsterfolie packen und sehr höflich, indirekt und vage mit Ihnen sprechen, denn wenn ich Sie so behandle, als ... ein reifer Erwachsener und meine ehrliche Meinung äußern, wirst du ausflippen und explodieren und durchdrehen.Du bist ein sehr zerbrechlicher, zarter Mensch und du bist unreif, daher muss ich sehr höflich und indirekt mit dir sprechen, weil du das kannst nicht mit der direkten Wahrheit umgehen."

Auf diese Weise wird, wenn die sogenannte "Höflichkeit" auf die Spitze getrieben wird (wie es viele Leute tun), sie respektlos und unhöflich, während sie immer noch "höflich" erscheint. Mit anderen Worten, das Missverständnis von Höflichkeit und Respekt ist eines der größten Probleme in der Gesellschaft. Viele Menschen erkennen nicht, dass übermäßige Höflichkeit respektlos ist und Projekte scheitern lässt usw. Dieses Problem der falschen Höflichkeit verursacht jede Sekunde jeder Stunde jeden Tag irgendwo auf der Welt einen weiteren Kommunikationsfehler – es passiert ständig – und die Gesellschaft leidet sehr darunter.

@jtorjo
Hier ist der Ursprung des Problems:

Wiederholung des katastrophalen Fehlers von Nokia

WinRT/UWP wiederholte versehentlich den gleichen Fehler wie Nokia, BlackBerry, Apple und andere Unternehmen. Die Nokia-Geschichte: Nokia war ein sehr erfolgreicher Riese, aber später erkannte Nokia, dass sie in der Smartphone-Technologie zurückgefallen waren. Um dieses Problem zu lösen, musste es oberste Priorität haben, eine Reihe von verbesserten Versionen ihres bereits bestehenden Systems zu realisieren. Stattdessen versuchten sie, auf ein neues System umzusteigen, und es brachte sie um. Sie töteten sie buchstäblich – Nokia Mobile musste akzeptieren, von Microsoft aufgekauft zu werden.

Dann würde man erwarten, dass Microsoft aus dem Fehler von Nokia lernt und das gleiche Problem nicht wiederholt. Leider hat Microsoft den gleichen Fehler wie Nokia wiederholt. Microsoft hat sich für WinRT/UWP entschieden, anstatt neue Versionen von WPF und .NET Framework zu entwickeln. Rate, was passiert ist? Dieselbe katastrophale Katastrophe wie bei Nokia: Es hat sie getötet. Windows Mobile ist tot und wurde von Microsoft-Führungskräften abgebrochen. Microsoft hat also leider nicht aus dem katastrophalen Fehler von Nokia gelernt. Jetzt laufen alle Smartphones entweder mit Android oder Apple anstelle von WinRT/UWP, somit war WinRT/UWP ein katastrophaler Misserfolg, der dazu führte, dass Microsoft seinen Platz in einer milliardenschweren Smartphone-Industrie vollständig verlor. WinRT/UWP verursachte Microsoft Verluste in Höhe von mehreren Milliarden Dollar.

BlackBerry machte den gleichen Fehler wie Nokia und Microsoft. BlackBerry war sehr erfolgreich, aber später erkannte BlackBerry, dass sie in der Smartphone-Technologie zurückgefallen waren. Um dieses Problem zu lösen, musste es oberste Priorität haben, eine Reihe von verbesserten Versionen ihres bereits bestehenden Systems zu realisieren. Stattdessen versuchten sie, auf ein neues System umzusteigen. BlackBerry verwendete ursprünglich BlackBerry OS und wechselte dann um das Jahr 2013 zum QNX-System. Was ist passiert? Das gleiche wie WinRT und Nokia. Es hat sie getötet. Im Jahr 2016 kündigte BlackBerry an, die Entwicklung eigener Telefone einzustellen.

Bei Apple ist es auch einmal vorgekommen. Apple wäre fast zusammengebrochen und hatte großes Glück zu überleben. Einige Jahre später gelang Apple schließlich eine starke Erholung über Smartphones. Das Glück, nach dem katastrophalen Fehler noch am Leben zu sein.

Breaking Changes

Microsoft behauptet, sie könnten die WPF-Entwicklung nicht fortsetzen; konnte WPF wegen Breaking Changes nicht für Smartphones/Tablets verwenden, aber das ist ein Fall von extremer Angst vor Breaking Changes. Ja, es ist ratsam, sehr vorsichtig mit Breaking Changes umzugehen, aber wenn es auf die Spitze getrieben wird, dann tötet es Projekte und Unternehmen. Die Realität ist , dass wichtige Änderungen in der Tat eingeführt werden können. Microsoft hätte "WPF 5" mit Unterstützung für Smartphones/Tablets/Touchscreens herausbringen können und angekündigt, dass es Breaking Changes enthält, aber kein Entwickler gezwungen ist, sofort darauf zu aktualisieren. Vorhandene Apps gehen nicht kaputt, weil sie mit WPF 4 weiterlaufen, bis der App-Entwickler sich wohl fühlt und bereit ist, auf WPF 5 umzusteigen. Somit verursachen die Breaking Changes kein Chaos oder Ausfälle.

Es ist das gleiche Prinzip wie bei einer neuen Version eines NuGet-Pakets, das grundlegende Änderungen enthält. Ihre App bricht nicht plötzlich ab, wenn die neue Version des Pakets veröffentlicht wird. Ihre Benutzer verwenden Ihre App weiterhin und es treten keine Probleme auf, da Ihre App weiterhin die alte Version des Pakets verwendet, bis Sie damit vertraut und bereit sind, Ihre App auf die neueste Version des NuGet-Pakets zu aktualisieren. Somit können Breaking Changes eingeführt werden.

Umkehrung des Standpunkts zu verwaltetem Code

Microsoft sagte, dass verwalteter Code hervorragende Vorteile bietet, und dies war meiner Erfahrung nach mit verwaltetem und nicht verwaltetem Code absolut richtig. Ich begann meine Karriere mit dem Schreiben von nicht verwaltetem Code. Später habe ich die Behauptungen von Microsoft getestet und bin auf verwalteten Code umgestiegen und habe hervorragende Verbesserungen in Bezug auf Produktivität und Zuverlässigkeit erfahren. Später kehrte Microsoft seinen Standpunkt auf bizarre Weise um und produzierte WinRT auf Basis von nicht verwaltetem Code und dem alten Component Object Model (COM) aus dem Jahr 1993 und übermäßiger Nutzung von Win16 (auch bekannt als Win32). Die Basis von WinRT ist Technologie, die Jahrzehnte veraltet ist: Native Code, COM und Win16 AKA Win32. Es sollte nicht überraschen, dass die meisten App-Entwickler zögerten, auf WinRT/UWP umzusteigen.

Android ist jetzt Marktführer. Microsoft kann von Android lernen. Android-Apps werden normalerweise mit verwaltetem Code geschrieben. Obwohl ich Java nicht mag und lieber C# verwende, muss ich sagen, dass Java viel besser ist als natives Win16 und COM.

Mehrere Microsoft-Mitarbeiter sagen immer noch "native", als ob das eine gute Sache wäre. Ich habe meine Karriere mit "native" begonnen und ich weiß aus jahrelanger Erfahrung, dass "native" eine schlechte Sache ist. Legionen von Android-Entwicklern wissen auch, dass Native eine schlechte Sache ist, aber zu viele UWP-Mitarbeiter sagen es, als ob es großartig wäre. Um es mit den Worten von @jtorjo zu sagen , das WinRT-Team war und ist „realitätsfern“. Das WinRT-Team verhält sich weiterhin so, als ob WinRT ein Erfolg gewesen wäre, obwohl es katastrophal gescheitert ist und Windows Mobile bereits von Microsoft-Führungskräften abgebrochen wurde.

Ich muss diese Worte immer wieder wiederholen: WinRT/UWP war ein katastrophaler Fehlschlag. Ich bin gezwungen, diese Worte immer wieder zu wiederholen, weil das WinRT-Team in dem Sinne "realitätsfremd" ist, dass es sich weigert anzuerkennen, dass WinRT/UWP ein katastrophaler Fehler war und dass Microsoft nicht weiterhin die gleichen Fehler von wiederholen sollte WinRT, als ob nichts passiert wäre.

Zum Beispiel ist DataGrid derzeit in modernem verwaltetem Code geschrieben, aber die WinUI-Teams möchten DataGrid neu schreiben, um "nativen" Code zu verwenden, und glauben, dass dies ein "Upgrade" ist, obwohl es in Wirklichkeit eine Herabstufung und ein Rückschritt auf Praktiken ist die sind Jahrzehnte überholt. Im Allgemeinen wird WinRT/UWP von Verwechslungen zwischen modernen und veralteten Software-Engineering-Praktiken geplagt. Daher könnte @jtorjos Verwendung der Wörter _"realitätsfremd"_ als unhöflich interpretiert werden, aber ich glaube, es ist eine genaue Beschreibung, auch wenn es nicht die beste Wortwahl war.

Ein weiteres Beispiel für _"Realitätsverlust"_ ist das Design von WebView2 – es ist wie eine Zeitreise zurück zu den Anfängen meiner Karriere vor Jahrzehnten, als wir veraltete Konzepte verwendeten wie HRESULT anstelle der modernen Ausnahmebehandlung. Es ist erstaunlich zu sehen, dass WebView2 im Jahr 2020 als neues Projekt veröffentlicht wird, aber immer noch alte Techniken wie HRESULT und LPCWSTR . Das Design von WebView2 entspricht nicht den modernen Software-Engineering-Praktiken.

In Anlehnung an das, was Rich Lander gesagt hat, zeigt meine vorherige Nachricht meinen Respekt für das WinUI-Team, denn wenn ich das WinUI-Team nicht respektiere, würde ich immer sehr höflich zum Team sein oder überhaupt nichts sagen. Wenn ich das Team nicht respektiere, würde ich WinUI abschreiben und ignorieren: Ich würde überhaupt keine Nachrichten schreiben - ich würde WinUI als "hoffnungslos" und "verlorene Sache" ansehen und würde kein Feedback geben an alle. Dass ich detailliertes Feedback gebe, zeigt, dass ich das Team respektiere. Viele Leute geben kein Feedback – das ist respektlos gegenüber dem Team. Es ist respektlos, das Team als so hoffnungslos zu betrachten, dass es sich nicht lohnt, Feedback für sie zu schreiben.

Wenn Sie vor Gericht wären, würden Sie dem Richter sehr höflich „Euer Ehren“ sagen, auch wenn Sie seinen Mut hassen. Extreme Höflichkeit ist Unhöflichkeit. Richter interpretieren "Ihre Ehre" als Respekt, aber in Wirklichkeit ist es Respektlosigkeit.

Microsoft hat sich für WinRT/UWP entschieden, anstatt neue Versionen von WPF und .NET Framework zu entwickeln. ...

Einverstanden. Ich entwickle UWP jetzt schon seit einigen Monaten... Es gibt einige Einschränkungen, aber ich habe mein Bestes getan, um "Zen" zu sein und mehr oder weniger weiterzumachen. Aber je mehr ich arbeiten würde, desto mehr wurde mir klar - dass die Einschränkungen tatsächlich WinRT waren, nicht UWP.

Die Sache ist die, das ist, was wir haben, und klar müssen wir damit vorankommen. Das sollte meiner Meinung nach sein:

1. UWP muss die Tatsache, dass es WinRT verwendet, so gut wie möglich verbergen
2. WinRT sollte sich bemühen, so viele (unnötige) Einschränkungen wie möglich zu entfernen
3. Der Hauptfokus sollte Desktop sein und dann die anderen Plattformen (Hololens, Xbox usw.)

(ps Die Tatsache, dass ich für eine Datei, um ihre Eigenschaften zu erhalten, eine asynchrone Funktion aufrufen muss, lässt mich immer noch zucken)

Umkehrung des Standpunkts zu verwaltetem Code

Warum wir uns in WinRT mit COM befassen müssen, ist in der Tat jenseits meines Verständnisses. Es scheint, dass sie alten DCOM-Code oder so etwas verpackt haben, aber das sollte vor Benutzern von WinRT zu 100% verborgen sein.
Die Tatsache, dass wir uns über COM bewusst sein müssen, ist wirklich sehr schlecht. Das wiederum soll mir, dem Nutzer der Bibliothek(en), so gut wie möglich verborgen bleiben.

[später bearbeiten] Nun, wenn wir uns das vorstellen, brauchen wir zumindest COM, um mit DirectX umzugehen. Dennoch sollte es den Benutzern von Bibliotheken so gut wie möglich verborgen bleiben.

Mehrere Microsoft-Mitarbeiter sagen immer noch "native", als ob das eine gute Sache wäre.

Native, im Zusammenhang mit "compile to .net native" finde ich eine gute Sache, aber ich mag die Einschränkungen nicht. Mein Projekt kann nicht in .net native kompiliert werden, weil es eine andere Bibliothek verwendet, die ich auf UWP portiert habe, und einige APIs verwendet, die die mächtigen Store-Leute für "inakzeptabel" halten. Die fragliche Bibliothek ist https://github.com/naudio/NAudio - eine unglaublich leistungsstarke Bibliothek. Allein aus diesem Grund habe ich einfach gesagt - ich werde meine App NICHT im MS Store veröffentlichen.

Ein weiteres Beispiel für _"Realitätsfremdheit"_ ist das Design von WebView2 – es ist wie eine Zeitreise zurück zu den Anfängen meiner Karriere

Ich bin mir nicht 100% sicher, aber wahrscheinlich hast du recht. Ich weiß, dass WebView angeblich ein Wrapper über einem Win32-Steuerelement ist, und ich kenne einen seltsamen Fehler, bei dem WebView-Links nicht funktionierten, wenn WebView über einem anderen Steuerelement lag.

Hallo @robloo ,

Entschuldigung für die späte Antwort

Ich war vor einigen Jahren auf Ihrer Frustrationsebene, als ich zum ersten Mal mit der Portierung über WPF-Apps begann. Also ich verstehe deine Gefühle auf jeden Fall. Seitdem gab es einige Fortschritte und wie Sie sagten, versucht das WinUI-Team wirklich alles.

Ja, stimme voll und ganz zu. In den Jahren 2016-2017 würde ich UWP nicht einmal anfassen.

Aus meiner Sicht gibt es ein grundlegendes Designproblem, das wir nicht umgehen können: WinRT war technisch behindert, weil es direkt mit C++ und JavaScript interoperieren muss ( hier

Das ist mehr als traurig, um es gelinde auszudrücken ... Warum wollen wir JS-Interoperabilität?

... ist ein Beispiel und ein anderes ). Es passt auch nicht gut zu vielen der High-Level-Konzepte, wie zum Beispiel Generika. Natürlich gibt es auch bei dieser Architektur einen großen Vorteil: Alle Windows können jetzt die gleichen WinRT-APIs verwenden.

Es gibt viele Dinge, die ich an WinRT hasse - was gehört noch dazu?

Dass ich das überhaupt wissen muss, ist schlecht. Tatsächlich musste ich solche 2 kleinen Projekte erstellen, und es war alles Versuch und Irrtum, um zu verstehen, was ich tatsächlich verwenden darf.

Wir haben also einige der Vorteile von verwaltetem Code verloren, an die wir uns im Laufe der Jahre gewöhnt haben. Es scheint definitiv immer noch ein Schritt zurück von WPF zu sein - ich finde ständig Fehler und unvollständige Funktionen. Ich denke, #1830 würde in den WPF-Tagen nie passieren. Wir müssen noch irgendwie vorankommen.

Ja, das machen wir...

WinUI 3.0 ist eindeutig ein Schritt in die richtige Richtung, um dies zumindest im Frontend zu beheben. Allerdings würde ich es vorziehen, wenn Microsoft einen robusteren Entwicklungsprozess und mehr Tests implementiert, bevor neue Steuerelemente veröffentlicht werden... [...]

Einverstanden 100%.

Es ist traurig für mich zu sehen, wie sich die einst leistungsstärkste UI-Plattform WPF zu dieser entwickelt. Aber Microsoft hört jetzt langsam aber sicher auf Feedback und repariert Dinge. Es ist klar, dass noch viel zu tun ist.

Ja, es gibt eindeutig tolle Leute bei MS, die zuhören. Hoffen wir, dass wir das umdrehen können...

Die API zum Abfragen von Dateien ist mehr als langsam

Offenbar hat jemand einen Workaround dafür gefunden. Natürlich ist es wirklich sehr traurig, dass das so lange gedauert hat - und dies ist nicht die bevorzugte Art und Weise, wie ich mit der Suche nach Dateien umgehen möchte, aber zumindest funktioniert es tatsächlich.
https://github.com/microsoft/microsoft-ui-xaml/issues/1465#issuecomment -575987737

Also, vielen Dank an @duke7553 !

@jtorjo Gerne helfen!

Ich finde diese Diskussion sehr interessant und eigentlich sehr relevant für die Zukunft der Windows-Benutzeroberfläche. Das liegt daran, dass WinUI nicht in einem Vakuum sitzt. Dieses gesamte Repository hat nur einen sehr geringen Wert, es sei denn, es ist nützlich zum Erstellen von Apps, die auf etwas anderem als WinRT/UWP ausgeführt werden. WinUI 3.0 konnte nicht früh genug kommen.

Wir haben eine Vision und eine Roadmap für die Benutzeroberfläche von Windows, aber das steht ganz oben auf dem Stapel und es gibt keine Vision für das, was sich unter dieser Oberflächenschicht befindet:
Sieht WinUI gut aus? JAWOHL
Können Sie jetzt (JAN2020) moderne, gut aussehende Apps unter Windows erstellen? NEIN
Können Sie mit UWP eine gute App erstellen? AUF KEINEN FALL!

Wir können nicht wirklich vorankommen, ohne den Elefanten im Raum anzusprechen: die bereits erwähnte Tatsache, dass WinRT und UWP nicht nur geschäftlich, sondern auch technologisch total versagt haben. Ich persönlich gehöre zu den Leichenzählungen. Ich habe aufgehört, mein Hobbyprojekt zu entwickeln, als ich nicht herausfinden konnte, wie ich einen Sound abspielen sollte, als meine App den Fokus verlor. Trivial. Müssen triviale Dinge so schwer sein wie in UWP? Kann man eine Plattform großartig nennen, wenn triviale Dinge unmöglich schwierig sind? WinUI ist nur ein Teil einer Plattform, nicht wahr?

Ein weiterer Elefant im Raum. Wenn jemand fragt: Ich möchte ein neues Windows-Programm erstellen, wie mache ich das am besten? In JAN2020 gibt es keine eindeutige Antwort! Wenn Sie versuchen, UWP in die Antwort zu integrieren, werden Sie eine schlechte Zeit haben. (Gibt es einen einzigen Kommentar, einen Blogbeitrag, ein YouTube-Video, in dem jemand sagte: Ich habe eine großartige App mit UWP erstellt und der Prozess hat mir gefallen? Wir alle wissen, dass es keine gibt. Niemand schreibt über die Erstellung von Apps mit UWP, das tut es buchstäblich gibt es im Internet nicht). WPF? Keine moderne Steuerung - tote Technik, keine gute Idee (aber immer noch besser als UWP). Die ehrliche Antwort müsste lauten: Vielleicht Elektron versuchen? VSCode wurde damit erstellt, sodass Sie wissen, dass Sie damit eine gute App erstellen können.

Und diese Idee, dass Sie eine App für Windows mit jeder beliebigen Sprache erstellen können, ist nur ein Auszug. Wir befinden uns in einer Situation, in der Sie eine sehr schlechte UWP-App mit jeder gewünschten Sprache erstellen können. Bot nicht mindestens EINE ausgezeichnete Möglichkeit, dies zu tun.

Die zuvor im Thread erwähnte Navy-Sache? Stimme voll und ganz zu. Visual Studio – Der Juggernaut selbst (UI) wird mit verwaltetem Code erstellt – WPF. Es ist großartig, sogar fantastisch. Während selbst Microsoft mit diesem angeblichen nativen Superion-Code keine OK-Apps erstellen kann. Ich sehe jeden Tag unerwartetes Verhalten bei OneNote, Wetter und sogar Start/Suche/Taskleiste. Es fühlt sich wackelig an und manchmal funktioniert der Fokus nicht so, wie er sollte.

Dies ist ein reichhaltiges und wichtiges Thema. Sehr relevant für WinUI, und leider gibt es keinen besseren Ort, um darüber zu sprechen. Diese Themen müssen von Microsoft offen behandelt werden.

Wir haben eine Vision und eine Roadmap für die Benutzeroberfläche von Windows, aber das steht ganz oben auf dem Stapel und es gibt keine Vision für das, was sich unter dieser Oberflächenschicht befindet:
Sieht WinUI gut aus? JAWOHL

Ja, so ist es!

Können Sie jetzt (JAN2020) moderne, gut aussehende Apps unter Windows erstellen? NEIN

Ich glaube, Sie können es - aber es ist wirklich sehr schwer. Triviale Dinge sind wahnsinnig schwer zu tun (ich bin der lebende Beweis dafür, dass es möglich ist, aber Sie brauchen auf jeden Fall Nerven aus Stahl):

• An der UI-Front wird es Probleme geben, aber normalerweise hast du den Dreh raus
• an der Front "alles andere" sind die Dinge ziemlich düster.
• Der Umgang mit Dateien auf UWP ist die Hölle, aufgrund der StorageFile/Folder-API, die ich, um es in der Mitte zu sagen, von ganzem Herzen hasse

Wir können nicht wirklich vorankommen, ohne den Elefanten im Raum anzusprechen: die bereits erwähnte Tatsache, dass WinRT und UWP nicht nur geschäftlich, sondern auch technologisch total versagt haben. Ich persönlich gehöre zu den Leichenzählungen. Ich habe aufgehört, mein Hobbyprojekt zu entwickeln, als ich nicht herausfinden konnte, wie ich einen Sound abspielen sollte, als meine App den Fokus verlor. Trivial. Triviale Dinge müssen so schwer sein, wie sie sind

Einverstanden. Tatsächlich ist das Abspielen von Systemsounds, was in WPF wie SystemSounds.Beep.Play() , auf UWP nicht verfügbar.

Grundsätzlich gibt es auf UWP aufgrund der "großen" WinRT-Einschränkungen keine Soundbibliothek, was im Grunde bedeutet, dass Sie keine Funktionen aus DLLs importieren können, die Win32 sind. So ziemlich kann nicht jede anständige Bibliothek auf UWP portiert werden. Keine Bibliotheken, keine Apps.

In der "Soundbibliothek" von UWP hat naudio sein Bestes versucht, um an UWP zu arbeiten. Offensichtlich ist es platt gefallen. Ich habe eine Gabelung erstellt, viele #ifdefs entfernt und es funktioniert jetzt für meine Bedürfnisse. Ich werde meine App nie im MS Store veröffentlichen können und will.

Der beste Schritt in die richtige Richtung ist meiner Meinung nach, dass MS

1. Schließlich konzentrieren Sie sich ZUERST auf Windows Desktop . Hören Sie auf, nach tausend Plattformen wie Hololens, Xbox und dergleichen zu suchen. Sicher, es wird Leute geben, die für diese Plattformen entwickeln wollen, aber der Prozentsatz ist winzig.
2. Entfernen Sie alle API-Einschränkungen - damit die Leute tatsächlich Libs in UWP kompilieren können
3. Sobald Sie broadSystemAccess anfordern, geben Sie es einfach und hören Sie auf, so übervorsichtig zu sein.
4. Sobald Sie broadSystemAccess anfordern, erlauben Sie System.IO auf allen Festplatten
5. Vereinfachen Sie die Verteilung außerhalb des MS-Stores (+ das Problem mit dem "Neuen Zertifikat" beheben)

Ein weiterer Elefant im Raum. Wenn jemand fragt: Ich möchte ein neues Windows-Programm erstellen, wie mache ich das am besten? In JAN2020 gibt es keine eindeutige Antwort! Wenn Sie versuchen, UWP in die Antwort zu integrieren, werden Sie eine schlechte Zeit haben. (Gibt es einen einzigen Kommentar, einen Blogbeitrag, ein YouTube-Video, in dem jemand sagte: Ich habe eine großartige App mit UWP erstellt und der Prozess hat mir gefallen? Wir alle wissen, dass es keine gibt. Niemand schreibt über die Erstellung von Apps mit UWP, das tut es buchstäblich gibt es im Internet nicht). WPF? Keine moderne Steuerung -

Ja, ich stimme zu - gute Ressourcen für UWP zu finden ist nahe Null. Viele Probleme müssen Sie nur selbst angehen und beheben.

tote Technik, keine gute Idee (aber immer noch besser als UWP). Die ehrliche Antwort müsste lauten: Vielleicht Elektron versuchen? VSCode wurde damit erstellt, sodass Sie wissen, dass Sie damit eine gute App erstellen können.

Über WPF habe ich nur lobende Worte. Ich habe mich seit einigen Jahren entwickelt. Und obwohl die Lernkurve ziemlich steil ist, ist es erstaunlich, wenn Sie einmal den Dreh raus haben! Ich habe ein paar Hardcore-Bugs gefunden, von denen ich wusste, dass sie nie behoben werden würden, aber das war's.

Ich war gezwungen, auf UWP umzusteigen, da ich, um meine App schnell genug zu machen, win2d verwenden musste. Es gibt Dinge, die in UWP fehlen, wenn es um die Benutzeroberfläche geht (zum Beispiel, als ich mit der Portierung begann, gab es keine native Möglichkeit, Cursor für ein Steuerelement zu definieren), aber alles in allem habe ich immer Workarounds gefunden .

Die zuvor im Thread erwähnte Navy-Sache? Stimme voll und ganz zu. Visual Studio – Der Juggernaut selbst (UI) wird mit verwaltetem Code erstellt – WPF. Es ist großartig, sogar fantastisch. Auch wenn Microsoft das nicht kann

Ich wette eindeutig, dass Sie Visual Studio in UWP nicht mein Leben lang erstellen können – und ich spreche nicht über die Benutzeroberfläche, Sie könnten die Benutzeroberfläche von Visual Studio erreichen und übertreffen, aber den Rest. ...

Dies ist ein reichhaltiges und wichtiges Thema. Sehr relevant für WinUI, und leider gibt es keinen besseren Ort, um darüber zu sprechen. Diese Themen müssen von Microsoft offen behandelt werden.

100% einverstanden!

Können Sie jetzt (JAN2020) moderne, gut aussehende Apps unter Windows erstellen? NEIN

Ich glaube, Sie können es - aber es ist wirklich sehr schwer. Triviale Dinge sind wahnsinnig schwer zu tun (ich bin der lebende Beweis dafür, dass es möglich ist, aber Sie brauchen auf jeden Fall Nerven aus Stahl):

• An der UI-Front wird es Probleme geben, aber normalerweise hast du den Dreh raus
• an der Front "alles andere" sind die Dinge ziemlich düster.
• Der Umgang mit Dateien auf UWP ist die Hölle, aufgrund der StorageFile/Folder-API, die ich, um es in der Mitte zu sagen, von ganzem Herzen hasse

Wir sind hier wie geschlagene Hunde. Es ist tatsächlich so schwer, eine neue moderne App für den Windows-Desktop zu erstellen! Sollte es nicht mindestens eine hervorragende Möglichkeit geben, Apps zu erstellen? Wenn Sie unter Windows zum Microsoft Store gehen und versuchen, in der App-Kategorie zu scrollen, werden Sie keine anständige App finden, die mit UWP erstellt wurde. Übrigens kann ich es nicht selbst überprüfen, weil ...

Ja, "moderne", "native" App, meine Damen und Herren. Da Windows jetzt praktisch kostenlos ist, sollte die Hauptquelle der Monetarisierung nicht die solideste App auf dem System sein, aber ich schweife ab. Sie müssen die App eigentlich nicht recherchieren, um zu wissen, mit welcher Technologie sie erstellt wurde. Nur ein Blick und Sie können erkennen, ob es mit UWP erstellt wurde. Es gibt keine ernsthaften kommerziellen Projekte, die mit UWP erstellt werden, und was damit gebaut wird, ist ... Sie wissen schon ...

Und das liegt daran, dass es soooo schwer ist. Window10 ist die größte Plattform nach dem Internet und Android!!! Aber No One macht Apps dafür mit den Tools, die angeblich dafür gemacht wurden! Denken Sie einfach darüber nach. Mit UWP ist es einfacher, eine Electron-App für 3 Betriebssysteme zu erstellen als nur für Windows!

Ist es in Ordnung für uns, geschlagene Hunde, die nur Windows-Desktop-Apps erstellen wollen, um exzellente Tools zu verlangen? Ich sage ohne Entschuldigung ja! Aber alles, was wir haben, ist Funkstille von Microsoft. Wer möchte ein Märchen hören, dass Ihre App möglicherweise auf Holo Lens oder einem Windows Phone oder einer Xbox funktioniert? Niemand. Nach 5 Jahren gab es keine kommerzielle App, die auf 2 der für UWP versprochenen Plattformen funktioniert. (Meistens, weil diese Plattformen nicht beendet werden). Denken Sie noch einmal darüber nach! Das Beste, was uns passiert ist, ist, dass WinUI auf das alte Win32 zurückportiert wird.

Ich liebe den Windows-Desktop, ich habe gelernt, C# auf WinForms und WPF zu programmieren. Und es war einfach und ausgezeichnet für einen Neuling wie ich. Heute schaue ich mir diese saftigen Steuerelemente in WinUI an, aber jemand muss das Gesamtbild für die Plattform klarstellen. Wir brauchen eine klare Botschaft über die praktische Technologieführerschaft und nicht über die Marktbestrebungen einiger MS-Geschäftsführer.

Hi,
Ich bin etwas spät zu dieser Diskussion, wollte aber trotzdem meine bescheidene Meinung sagen.
Zu kommerziellen UWP-Apps: Eines, das mir in den Sinn kommt, ist Adobe XD. Dieser ist UWP und fühlt sich sehr ausgereift und vollständig an.
Meine eigenen Erfahrungen mit UWP als .Net-Entwickler seit 13 Jahren: Natürlich kann man damit eine gut aussehende, performante App erstellen. Aber... es ist keine schöne Erfahrung. Wir sind dabei, eine medizinische Anwendung zu erstellen und viele der Dinge, die hier und anderswo bereits erwähnt wurden, sind auch bei uns aufgetreten:

• Unglaublich langsame Datei-API
• Sehr langsame "F5-Zeit". Das Debuggen, um die Anwendung zu erstellen/zu starten, um etwas auszuprobieren, ist also mindestens 10 x langsamer als in WPF. (denken Sie an ca. 2 Minuten auf einem Surface Book 2)
• Im Allgemeinen durch die Sandbox eingeschränkt.
  Das sind nur die aus meinem Kopf. Am Ende, als XamlIslands veröffentlicht wurde, haben wir uns entschieden, unsere komplette UWP-Benutzeroberfläche in einem WPF-Fenster zu hosten, mit einem schnellen .net-Kern hinter allem. Ich glaube nicht, dass viele Leute XamlIsland in dieser Größenordnung verwendet haben (aus den von uns erstellten Github-Problemen / PRs). Diese Technologie hat jedoch auch einige sehr gravierende Einschränkungen. Nur als Beispiel, die Kompilierzeit wird noch höher. Verlust der Möglichkeit zur Live-Bearbeitung von Xaml. Erstellen Sie ein Installationsprogramm für eine seriöse WPF/XamlIsland/UWP-App? Es schmerzt. etc...
  Zusammenfassend lässt sich sagen, dass es natürlich möglich ist, schöne UWP-Apps zu erstellen. Aber es ist so unproduktiv und langsam. Und eingeschränkt.
  Wie viele andere warten wir also gespannt auf die Veröffentlichung und das Ausreifen von WinUI 3, da wir ohne Tricks "UWP"-Frontend und .net-Core (oder .net 5 ;-) ) Backend haben können.

@jasonwurzel das sind ein paar sehr gute Punkte

• Die Datei-API ist langsam, aber in der Zwischenzeit hat @duke7553 in #1465 (Kommentar) einen Workaround gepostet.
  Das stimmt, aber wir wussten es damals noch nicht. Überflüssig zu sagen, es ist irgendwie verrückt, diesen Workaround zu implementieren, nur um schnelle Datei-I/O zu erhalten ...
• F5-Zeit verlangsamt die Dinge und ich denke, das kann einige Verbesserungen gebrauchen
• Ich bin gespannt, auf welche Einschränkungen Sie gestoßen sind, als Sie versucht haben, eine reguläre UWP-App zu entwickeln, anstatt die Route der Xaml-Inseln zu gehen? Ich arbeite gerade an einigen Apps und konnte alle Einschränkungen durch die Einbeziehung von Win32-Prozessen beheben, aber ich verstehe, dass dies nicht immer der ideale Weg ist, um eine App zu erstellen.
  Ich denke, am Ende war es die Summe der Hindernisse, die wir trafen, von denen einige zweifellos mit externen Prozessen hätten gelöst werden können. In keiner bestimmten Reihenfolge:
• CD-Fach/USB-Anschlüsse auf eingelegte Medien beobachten
• Beobachten eines vom Benutzer gewählten Verzeichnisses irgendwo auf dem lokalen PC und die App/Windows merkt sich das Zugriffsrecht beim Aktualisieren
• BroadFileSystemAccess anfordern, Ausnahme erhalten, entsprechende Windows-Einstellungsseite öffnen, Benutzer prüft den Toggle der App, Boom-App schließt ohne Vorwarnung, keine Möglichkeit einzugreifen.
• gleiche Domäne: den Benutzer ein Verzeichnis auswählen zu lassen, ohne einen Windows-artigen FolderPicker öffnen zu müssen (nein, wir wollen unsere Vollbild-App nicht schön und schlank gestalten und dann springt dem Benutzer der Windows-Dialog ins Gesicht)
• Henne-Ei-Problem: Verfügbarkeit/Unterstützung von Nuget-Paketen (viel mehr Leute verwenden immer noch WPF, daher ist es viel schneller, Lösungen für kleine Probleme zu finden)
• Steuerung des Installationsorts

@AndrewPawlowski Ich bin überrascht, dass Sie sagen würden, dass es viele großartige UWP-Apps gibt, die sowohl modern als auch gut aussehend sind, einschließlich einer Handvoll, die auf GitHub Open Source sind.
Nur weil Sie das Erstellen einer App aufgegeben haben, weil Sie nicht herausgefunden haben, wie etwas zu tun ist, bedeutet dies nicht, dass eine Plattform ausgefallen ist, sondern dass Ihre App ausgefallen ist. Wenn Sie sich umschauen, können Sie viele Entwickler sehen, die hart gearbeitet und einige wirklich gute Apps erstellt haben, darunter Apps, die weiterhin Sound abspielen, wenn die App den Fokus verliert.

Ich sage nicht, dass es nicht möglich ist, aber es ist sehr, sehr schwer. Und ich spreche nicht von einer einfachen "Notepad-ähnlichen" App, ich spreche von einer sehr komplexen App, die sich mit Benutzeroberfläche / Videobearbeitung / Tonbearbeitung / Laden/Speichern vieler Dinge auf Festplatte befasst / (versucht und nicht erfolgreich ) Sachen starten (und erzähl mir bitte nichts von der fullTrust API). Ich spreche von einer 50-100K+ Codezeilen-App.

Das ist waaaay schwieriger.

Und die Tatsache, dass Sie einen Ton abspielen können, wenn die App den Fokus verliert - niemand sagt, dass Sie das nicht können, aber es sollte viel einfacher sein als jetzt.

Sie fragen, ob es jemanden gibt, dem der Prozess der Entwicklung von UWP-Apps Spaß macht, und die Antwort ist, dass es viele gibt, und in den letzten Monaten habe ich viele Anfragen von anderen Entwicklern nach Hilfe zu ihren Apps erhalten, die Plattform gewinnt eindeutig an Interesse.

Ich stimme zu, deshalb habe ich tatsächlich damit begonnen, meine App auf UWP zu portieren. Aber es war ein sehr holpriger Weg und ist es immer noch.

Sie behaupten auch, dass niemand über die Entwicklung von UWP-Apps schreibt, und ich muss sagen, dass das einfach falsch ist, @rudyhuyn , Martin Zikmund sind nur zwei Beispiele für Entwickler, die über UWP schreiben, aber es gibt auch viele andere.

Ich stimme voll und ganz zu, aber vergleiche das mit Leuten, die über wpf schreiben. Es ist ein Tropfen ins Wasser.

Führen Sie einfach eine einfache Github-Suche durch - "c# wpf" (3701 Ergebnisse) vs "c# uwp" (337 Ergebnisse).
Ich bin mir sicher, wenn Sie nach dem gleichen suchen und nach "Anzahl der Commits > 500" filtern würden (was irgendwie bedeutet, dass der Benutzer am Projekt festhält) -> Sie würden ein waaay Dimmer-Bild finden.

Dies zeigt ziemlich genau, dass Sie sowohl gut aussehende Apps im Jahr 2020 als auch moderne UWP-Apps erstellen können und dass viele Ihrer Aussagen nicht korrekt sind.

Ich möchte widersprechen - um eine komplexe UWP-App entwickeln zu können und dabei glücklich zu sein -> davon sind wir noch weit entfernt.

• Ich bin gespannt, auf welche Einschränkungen Sie gestoßen sind, als Sie versucht haben, eine reguläre UWP-App zu entwickeln, anstatt die Route der Xaml-Inseln zu gehen? Ich arbeite gerade an einigen Apps und konnte alle Einschränkungen durch die Einbeziehung von Win32-Prozessen beheben, aber ich verstehe, dass dies nicht immer der ideale Weg ist, um eine App zu erstellen.

Meinerseits habe ich im September versucht, win2d mit Xaml Islands zu verwenden - hat kein bisschen funktioniert. Ich habe einige Beispiele von MS ausprobiert und sie haben auch nicht funktioniert. An diesem Punkt wurde mir klar, dass ich meine App wirklich auf UWP portieren muss, sonst wird dies nie funktionieren.

Ein neuerer Test - https://github.com/microsoft/Win2D/issues/731

• Sehr langsame "F5-Zeit". Das Debuggen, um die Anwendung zu erstellen/zu starten, um etwas auszuprobieren, ist also mindestens 10 x langsamer als in WPF. (denken Sie an ca. 2 Minuten auf einem Surface Book 2)

Oh ja! Ich habe das nicht einmal erwähnt, aber ja, es ist wahnsinnig langsam. Ich habe es umgangen, indem ich optimiert habe, welche Projekte ich kompiliere und welche nicht - und je nachdem, an welchem ​​Teil der App ich arbeite, ist das anständig oder schrecklich (und mit anständig, ich meine, ungefähr 10-15). meistens Sekunden)

• Im Allgemeinen durch die Sandbox eingeschränkt.

Oh ja :)

• Die Datei-API ist langsam, aber in der Zwischenzeit hat @duke7553 in #1465 (Kommentar) einen Workaround gepostet.

Einverstanden, aber denken Sie nur daran, wie lange es dauerte, bis jemand diese Problemumgehung fand – die eindeutig existierte, aber tief in den Dokumenten vergraben war. Und im Moment wissen es wahrscheinlich nur sehr wenige Leute (einschließlich mir).

Wenn Sie eine Google-Suche durchführen, werden Sie keinen der Beiträge finden, die diese Problemumgehung zeigen, daher wird es wahrscheinlich einige Monate dauern, bis die meisten Entwickler davon erfahren.

@jasonwurzel

Wie viele andere warten wir also gespannt auf die Veröffentlichung und das Ausreifen von WinUI 3, da wir ohne Tricks "UWP"-Frontend und .net-Core (oder .net 5 ;-) ) Backend haben können.

Ich möchte nur darauf hinweisen, dass MS gesagt hat, dass Sie .NET 5 nach der Landung für Ihre UWP-Projekte problemlos verwenden können. Keine "Tricks" oder Situationen wie .NET Core 3.x erforderlich. Hier ist noch einmal der Ankündigungspost zu .NET 5: https://devblogs.microsoft.com/dotnet/introducing-net-5/

ja das meinte ich

Ich denke, das Wort "völlig" in _"völlig realitätsfremd"_ war unfair und ungenau, aber @jtorjo war aus verständlichen Gründen sehr frustriert. Wenn Microsoft völlig realitätsfern wäre, würde das WinUI-Team nicht daran arbeiten, WinUI von UWP zu trennen. Insgesamt scheint das WinUI-Team enger zu sein als andere Abteilungen von UWP/WinRT. Ich denke, eine genaue Beschreibung wäre, dass in einigen Teams derzeit ein gewisses Maß an Kontaktlosigkeit existiert.

Bedeutung einer Liste-mit-Spalten-GUI

Obwohl das WinUI-Team wahrscheinlich das leistungsstärkste Team aller Teams im Zusammenhang mit UWP/WinRT ist, denke ich, dass beim Projektmanagement von WinUI immer noch einige Fehler gemacht wurden. Eine GUI mit Listen-mit-Spalten (wie DataGrid ) ist eine wesentliche Mainstream-Funktion, die jeder Kunde täglich verwendet (wie in Windows Explorer und verschiedenen anderen Beispielen wie Spotify usw.). Seit dem Start von WinRT sind 8 Jahre ohne offiziellen Support für eine GUI mit Listen-mit-Spalten vergangen! Ich finde diese Situation schockierend. Aus diesem und anderen Gründen sage ich, dass UWP heute noch eine Alpha-Version ist (es ist noch nicht vollständig, also keine echte Beta). Es überrascht nicht, dass die meisten App-Entwickler UWP nie ernst genommen haben und daher Windows Mobile eingestellt wurde.

Eine offizielle Version von DataGrid von WinUI ist seit 8 Jahren überfällig. DataGrid war in der Minute überfällig, als WinRT 1.0 veröffentlicht wurde, da Microsoft niemals ein neues System hätte starten sollen (wie ich in meiner vorherigen Nachricht zu Nokia usw. erklärt habe). 8 Jahre mit fehlenden Grundlagen, 8 Jahre überfällig, und jetzt möchte das WinUI-Team DataGrid noch überfälliger machen, indem es noch mehr Zeit mit einem Downgrade auf nativen Code verschwendet. Aus mehreren Gründen ist es schwierig, UWP ernst zu nehmen und ihm zu vertrauen.

C++/CX wurde kürzlich durch C++/WinRT ersetzt

Hier ist ein weiteres Beispiel für „Realitätsverweigerung“:
Offensichtlich muss Software vernünftig geschrieben werden (ich meine "gesund" als Terminologie, keine Beleidigung wie "Du bist verrückt"). "Gesund" als Terminologie bedeutet, dass Sie keine obskure, verworrene schwarze Magie verwenden sollten, um eine einfache, unkomplizierte Aufgabe zu erledigen.
C++/CX wurde kürzlich durch C++/WinRT ersetzt. C++/WinRT verwendet das sogenannte _"kurioserweise wiederkehrende Vorlagenmuster"_ für den Funktionsaufruf über statischen Dispatch. Das ist ein wirklich schreckliches Design, weil es kein vernünftiges Design ist, weil es darum geht, obskure, verworrene schwarze Magie zu verwenden, um eine einfache, unkomplizierte Aufgabe zu erledigen. Darüber hinaus hat CLR/C# dieses Problem bereits vor Jahrzehnten gelöst, warum also spielt das WinRT-Team immer noch herum und verschwendet Zeit mit sehr alten und primitiven Themen, die bereits vor Jahrzehnten gelöst wurden? Warum erfindet das WinRT-Team das Rad neu?

Ich habe den NEUEN Quellcode von C++/WinRT durchsucht und habe den Eindruck, dass es sich um eine schrecklich minderwertige Software handelt, aber das WinRT-Team sieht sie als wunderbar fortschrittlich an. "Realitätsferne" ist also eine zutreffende Beschreibung.

UWP-Dateisystem ist immer noch Alpha-Version

@jtorjo und andere Leute haben die Leistungsprobleme der Dateisystem-APIs von UWP erwähnt. Die Leistung liegt unter dem Niveau, das erforderlich ist, um es als Betaversion mit vollständigen Funktionen zu bezeichnen. Ein weiterer Grund, warum die UWP FS-API immer noch eine Alpha-Version ist, ist die fehlende Möglichkeit, einen Ordner zu verschieben. Vor 25 Jahren hatte Windows 95 die Möglichkeit, Ordner zu verschieben, aber UWP fehlt diese grundlegende Fähigkeit immer noch. In gewisser Weise ist Windows 95 leistungsfähiger als UWP. In vielerlei Hinsicht sind WPF und .NET Framework immer noch leistungsfähiger als UWP. Microsoft erwartete, dass App-Entwickler UWP ernst nehmen würden, aber dies war sehr unvernünftig (oder "realitätsfremd"), da Microsoft UWP nie von der Alpha- zur Beta-Phase weiterentwickelte.

Windows ging davon aus, dass Mobilgeräte wie "App Dev" der boomende Markt waren und modern waren, da Sicherheit und Akkulaufzeit im Mittelpunkt standen.

Sie wurden aufgrund der Marktkräfte aus dem Mobilfunkmarkt verdrängt. Geräte wie Hololens und Xbox versuchen, die Legacy-Unterstützung von Win32 zu entfernen – um die Entwicklung für sie zu vereinfachen und eine schlankere, leistungsfähigere Betriebssystem-Codebasis zu schaffen.

Diese Wetten haben sich nicht vollständig ausgezahlt, aber die Ideale für ein modernes App-Bereitstellungs- und Sicherheitsmodell sind lobenswerte Ziele.

Nach einiger Seelensuche hat sich Microsoft entschieden, das moderne App-Framework vom UI-Framework zu trennen.

WinUI 3.0 sollte das Beste aus beiden Welten sein und den Zugriff auf die meisten modernen APIs ermöglichen, die von Sprachprojektion, modernen Codierungsstandards und mobiler Vertrautheit profitieren. Aber auch, dass Apps die weniger sicheren, aber leistungsfähigeren Win32- und .NET-Laufzeiten verwenden können.

Natürlich wird das Vertrauen auf den Win32-Zugriff einschränken, auf welchen Plattformen sie laufen - und wer weiß, wohin sich der Markt in den kommenden Jahren bewegen wird.

Ich würde vorschlagen, anstatt die gleichen alten Gründe und Beschwerden zu bearbeiten, diese Community zu verwenden, um zu fragen, was Entwickler für die Zukunft wollen, und keine Schuldzuweisungen oder Schimpfwörter in einer Weise zu machen, die das Projekt nicht voranbringt.

@mdtauk schrieb:

Sie wurden aufgrund der Marktkräfte aus dem Mobilfunkmarkt verdrängt.

Verschiedene UWP/WinRT-Mitarbeiter möchten diese Erklärung sehr gerne glauben, um sich besser zu fühlen, was passiert ist. Ich glaube diese Erklärung nicht. Ich glaube, dass UWP aus folgenden Gründen fehlgeschlagen ist:

1. Missmanagement und
2. Versäumnis, das Problem anzugehen, dass App-Entwickler die UWP-Versionen ihrer Apps ständig verschieben, weil sie den Eindruck haben, dass UWP noch nicht bereit war und immer noch nicht für die Hauptsendezeit bereit ist, und
3. Übermäßige Nutzung unproduktiver alter Software-Engineering-Techniken und
4. Versäumnis, das Vertrauen der Mehrheit der App-Entwickler zu gewinnen, und
5. Dinge, die UWP albern aussehen ließen, wie die Förderung der Verwendung von JavaScript anstelle von Java, was bedeutet, dass der Unterschied zwischen einer Skriptsprache und einer Programmiersprache nicht erkannt wird.

Angesichts der Tatsache, dass Missmanagement der Hauptgrund für das Scheitern von UWP ist, ist es leider ironisch, dass UWP in nicht verwaltetem Code geschrieben ist, da das Wort "unmanaged" den Grund für das Scheitern wirklich zusammenfasst: Missmanagement sowohl des Quellcodes als auch des Projektmanagements.

@jtorjo schrieb:

Native, im Zusammenhang mit "compile to .net native" finde ich das eine gute Sache

Ich stimme zu. Der Unterschied besteht in der automatischen und der manuellen Generierung von nativem Code. Wenn nativer Code automatisch von einem Compiler oder Tool erstellt wird, ist dies normalerweise eine gute Sache. Wenn nativer Quellcode jedoch manuell geschriebener Quellcode ist, leiden Produktivität, Funktionsumfang und Zuverlässigkeit erheblich.

Wenn Sie sich den Zeitrahmen der WPF-Entwicklung im Vergleich zum Zeitrahmen der WinUI-Entwicklung ansehen, dann war die Entwicklung von WPF viel schneller (viel bessere Produktivität), obwohl WinUI einfacher/schneller zu entwickeln hätte sein sollen als WPF, da WinUI viele davon wiederverwendet Konzepte, die _bereits_ für WPF erstellt wurden. Leider hat sich Microsoft dazu entschieden, exzessiv alte Software-Engineering-Techniken zu verwenden, die ihrem eigenen früheren Standpunkt widersprachen und ihre eigene Produktivität sabotierten und dazu führten, dass App-Entwickler die Entwicklung von UWP-Apps ständig verschoben.

Was kann jetzt getan werden, um die Fehler der Vergangenheit zu beheben? Hören Sie auf, dieselben Fehler zu wiederholen, die zum Scheitern von UWP geführt haben. Fahren Sie nicht fort, als ob nichts Schlimmes passiert wäre. Ich verwende hier DataGrid als Beispiel: Fügen Sie DataGrid neue Funktionen hinzu, anstatt DataGrid noch weiter zu verzögern. Machen Sie DataGrid nicht noch mehr als 8 Jahre überfällig, indem Sie eine nutzlose manuelle Umschreibung/Konvertierung in nativen Code durchführen.

Den Endbenutzern ist es egal, ob DataGrid in verwaltetem oder nicht verwaltetem Code geschrieben ist, und sie wissen nicht, was diese Begriffe bedeuten. Daher ist es viel wichtiger und sinnvoller, den verwalteten Code unverändert beizubehalten und die Funktionalität/Merkmale von DataGrid. Die Menge an manuell geschriebenem nativem Code in UWP ist bereits eine katastrophale Situation. Warum also die Situation noch verschlimmern, indem man noch mehr nativen Code und noch mehr veralteten Code auf Basis von Win16/32 und COM schreibt?

Ich verstehe, dass Sie den veralteten Code nicht einfach wegwerfen können, aber Sie KÖNNEN aufhören, die Situation noch schlimmer zu machen, als sie bereits ist. Das heißt, hören Sie auf, noch mehr antiken nativen Code zu schreiben. Legen Sie eine Richtlinie fest, dass von nun an alle neuen Codes/Projekte mit modernen Software-Engineering-Techniken geschrieben werden. Führen Sie kein Downgrade von bereits vorhandenem verwaltetem Code wie DataGrid usw. durch.

UWP-Dateisystem ist immer noch Alpha-Version
@jtorjo und andere Leute haben die Leistungsprobleme der Dateisystem-APIs von UWP erwähnt. Die Leistung liegt unter dem Niveau, das erforderlich ist, um es als Betaversion mit vollständigen Funktionen zu bezeichnen. […]

Ich habe dies bereits erwähnt und ich werde es noch einmal erwähnen - die StorageFolder/StorageFile-API ist eine der schlechtesten APIs, die ich je gesehen habe. Wir befinden uns im 21. Jahrhundert, und ich muss fragen: "Oh bitte, kann ich darauf zugreifen? und darauf? und sie dann der großartigen FuturesAccessList hinzufügen?"

Und ich muss asynchron nach grundlegenden Eigenschaften wie der Dateigröße fragen? Es ist mir egal, welche Gründe das gehabt haben könnte, aber es ist im Moment ziemlich realitätsfremd.

Diese Wetten haben sich nicht vollständig ausgezahlt, aber die Ideale für ein modernes App-Bereitstellungs- und Sicherheitsmodell sind lobenswerte Ziele.

Ich bin völlig einverstanden...

[....] Natürlich wird der Zugriff auf Win32 einschränken, auf welchen Plattformen sie laufen - und wer weiß, wohin sich der Markt in den kommenden Jahren bewegen wird. […]

Ich stimme voll und ganz zu, aber zu viel in die Zukunft zu denken kann auch schmerzlich sein...
Damit meine ich - wenn Sie den Win32-Zugriff von Anfang an einschränken, wird das Portieren von Bibliotheken so ziemlich ein "No-Go" sein, so dass Sie keine Gegenwart haben, geschweige denn eine Zukunft.

Indem wir es uns erlauben, auch Win32-Code zu verwenden, können wir möglicherweise nicht auf eine andere (kommende) Plattform portieren, aber zumindest haben wir Code für heute. Und morgen, das ist ein weiterer Tag, und wenn wir dort ankommen, werden wir einen Weg finden, unseren Code zu portieren, wenn wir es wirklich wollen.

Aber ich tue, was ich der Wahl habe, und ich werde die Risiken verstehen.

Ich würde vorschlagen, anstatt die gleichen alten Gründe und Beschwerden zu bearbeiten, diese Community zu verwenden, um zu fragen, was Entwickler für die Zukunft wollen, und keine Schuldzuweisungen oder Schimpfwörter in einer Weise zu machen, die das Projekt nicht voranbringt.

Ich bin mir nicht sicher, ob das an mich gerichtet war oder so, ich bin kein englischer Muttersprachler. Trotzdem möchte ich dieses Projekt definitiv vorantreiben, aber ich denke, es ist wichtig, dass wir einige Probleme ansprechen, die uns von der Bereitstellung abhalten – heute.

Ich würde vorschlagen, anstatt die gleichen alten Gründe und Beschwerden zu bearbeiten, diese Community zu verwenden, um zu fragen, was Entwickler für die Zukunft wollen, und keine Schuldzuweisungen oder Schimpfwörter in einer Weise zu machen, die das Projekt nicht voranbringt.

Ich bin mir nicht sicher, ob das an mich gerichtet war oder so, ich bin kein englischer Muttersprachler. Trotzdem möchte ich dieses Projekt definitiv vorantreiben, aber ich denke, es ist wichtig, dass wir einige Probleme ansprechen, die uns von der Bereitstellung abhalten – heute.

Ich ziele auf niemanden ab, aber der Diskussionstitel ist ein wenig negativ und die Leute neigen nicht dazu, zu reagieren und legitime Probleme anzusprechen, wenn sie mit Beleidigungen und Anschuldigungen verbunden sind.

Außerdem wissen wir jetzt, dass mit WinUI 3.0 ein Win32/.NET-App-Framework kommen wird - es macht wenig Sinn, sie noch immer als WinRT zu kritisieren. 😁

@jtorjo

Wir befinden uns im 21. Jahrhundert, und ich muss fragen: "Oh bitte, kann ich darauf zugreifen? und darauf? und sie dann der großartigen FuturesAccessList hinzufügen?"

Dass Apps den Nutzer fragen müssen, ist meiner Meinung nach ein Schritt in die richtige Richtung. Die Tatsache, dass die App im Gegensatz zu Winforms und WPF-Apps nicht einfach alle meine Dateien scannen kann und ich die Kontrolle darüber habe, auf welche Ordner sie zugreifen kann, ist aus Sicherheitsgründen sehr wichtig. Wenn Sie der Meinung sind, dass es schlecht ist, dass wir die Ressourcen beschränken, auf die Apps zugreifen können, um den Benutzer zu schützen, dann ist das wohl Ihre Ansicht, aber ich möchte nicht, dass jede App mit meinen Dateien macht, was sie will.

Und ich muss asynchron nach grundlegenden Eigenschaften wie der Dateigröße fragen? Es ist mir egal, welche Gründe das gehabt haben könnte, aber es ist im Moment ziemlich realitätsfremd.

Ich denke, der Grund war, dass der UI-Thread nicht blockiert werden sollte, da das Schlimmste, was von einem UX-Punkt aus passieren kann, darin besteht, dass die App nicht mehr reagiert, weil der Entwickler vergessen hat, dass Disc-Operationen etwas dauern können. Mit wait können Sie das Problem umgehen und zwingt Sie, den UI-Thread irgendwann zu entsperren. (Zumindest verstehe ich Async-Await so).

Wie @mdtauk richtig darauf hingewiesen hat, ist der Diskussionstitel tatsächlich ein wenig negativ, und anstatt die gleichen alten Beschwerden zu wiederholen, sollten solche Diskussionen verwendet werden, um Ideen zur Lösung solcher Probleme zu entwickeln.

Ich denke, wir alle sollten daran denken, den Open-Source-Verhaltenskodex von Microsoft einzuhalten, eine professionelle Diskussion zu führen und allen gegenüber respektvoll zu sein, unabhängig davon, ob sie anwesend sind oder nicht.

https://opensource.microsoft.com/codeofconduct/

Dass Apps den Nutzer fragen müssen, ist meiner Meinung nach ein Schritt in die richtige Richtung. Die Tatsache, dass die App im Gegensatz zu Winforms und WPF-Apps nicht einfach alle meine Dateien scannen kann und ich die Kontrolle darüber habe, auf welche Ordner sie zugreifen kann, ist aus Sicherheitsgründen sehr wichtig. Wenn Sie der Meinung sind, dass es schlecht ist, dass wir die Ressourcen beschränken, auf die Apps zugreifen können, um den Benutzer zu schützen, dann ist das wohl Ihre Ansicht, aber ich möchte nicht, dass jede App mit meinen Dateien macht, was sie will.

Wir beginnen also mit einem großen Nachteil gegenüber WPF-Apps. Das ist das eine – das andere ist

1. Das frage ich schon bei der Installation.
2. Selbst wenn Benutzer nicht aufpassen, könnte Windows dem Benutzer erneut anzeigen "Diese App möchte auf Ihre Dateien zugreifen" und der Benutzer könnte Ja/Nein sagen. Damit wäre ich völlig in Ordnung. Dies ist jedoch WEIT von dem, was geschieht.

Und ich muss asynchron nach grundlegenden Eigenschaften wie der Dateigröße fragen? Es ist mir egal, welche Gründe das gehabt haben könnte, aber es ist im Moment ziemlich realitätsfremd.

Ich denke, der Grund war, dass der UI-Thread nicht blockiert werden sollte, da das Schlimmste, was von einem UX-Punkt aus passieren kann, ist, dass die App nicht mehr reagiert, weil der Entwickler es vergisst

Die Dateigröße sollte vorab abgerufen werden (wie letztes Zugriffsdatum / letztes Schreibdatum) - es ist so wichtig, dass sie bei einer Dateiabfrage vorab abgerufen werden sollte.

Wie @mdtauk richtig darauf hingewiesen hat, ist der Diskussionstitel tatsächlich ein wenig negativ, und anstatt die gleichen alten Beschwerden zu wiederholen, sollten solche Diskussionen verwendet werden, um Ideen zur Lösung solcher Probleme zu entwickeln.

Ich möchte unbedingt, dass diese gelöst werden, sonst nichts.

Ich denke, wir alle sollten daran denken, den Open-Source-Verhaltenskodex von Microsoft einzuhalten, eine professionelle Diskussion zu führen und allen gegenüber respektvoll zu sein, unabhängig davon, ob sie anwesend sind oder nicht.

Diese Diskussion hätte hier nicht stattgefunden, wenn wir tatsächlich einen Ort gehabt hätten, um diese Fragen zu stellen, und WinRT an anderer Stelle auf Feedback hören könnte.

Ich ziele auf niemanden ab, aber der Diskussionstitel ist ein wenig negativ und die Leute neigen nicht dazu, zu reagieren und legitime Probleme anzusprechen, wenn sie mit Beleidigungen und Anschuldigungen verbunden sind.

Ich stimme zu, dass es ein wenig negativ ist, noch einmal, dies wäre nicht passiert, wenn es woanders gegeben hätte, um Feedback zu WinRT-Problemen zu geben.

Außerdem wissen wir jetzt, dass mit WinUI 3.0 ein Win32/.NET-App-Framework kommen wird - es macht wenig Sinn, sie noch immer als WinRT zu kritisieren. 😁

Ehrlich gesagt hoffe ich wirklich, dass dies der Fall ist. Ich werde sicherlich warten, bis diese Probleme gelöst sind, und kann es persönlich kaum erwarten, dass diese Nicht-Sandbox-Plattform verfügbar ist. Aber bis dahin arbeite ich noch an einer App und stehe immer noch vor den Problemen, die ich eingangs skizziert habe.

Wir beginnen also mit einem großen Nachteil gegenüber WPF-Apps. Das ist das eine – das andere ist

Nur um das klarzustellen, ist es Ihrer Meinung nach ein Nachteil, der Verwendung die Wahl zu lassen, Apps den Zugriff auf alle Dateien zu verweigern?
Wir als Entwickler müssen die Software für die Nutzer entwickeln und nicht gegen sie. Und dem Benutzer keine Wahl zu lassen, welche Daten Ihre App sieht, ist meiner Meinung nach ein Sicherheitsnachteil für Benutzer.

1. Das frage ich schon bei der Installation.

Meinst du die Funktion "broadFileSystemAccess"? Meiner Meinung nach gibt es nur sehr sehr wenige Apps, die einen legitimen Grund haben, diese Funktion zu haben. (wie @kmgallahan bereits erwähnt hat)
Schauen Sie sich einfach alle Apps an, die Sie täglich verwenden. Wie viele davon benötigen ständig Zugriff auf alle Dateien? Wahrscheinlich nicht so viele, wenn es überhaupt welche gibt.

Wie Sie in Ihrem Eingangskommentar sagten:

Glauben Sie, dass die Benutzer das oben Genannte gerne tun werden? Nein, das werden sie nicht – tatsächlich tun es 79,8 % nicht (meine AppCenter-Daten belegen dies).

Ich denke, es gibt wahrscheinlich einen Grund, warum Benutzer dies nicht gerne tun (abgesehen von der Tatsache, dass dies eine Sicherheitseinstellung ist, die sie ändern müssen).

Ich kenne jedoch möglicherweise nicht alle Geschäftsfälle, die den Zugriff auf alle Dateien erfordern würden, also freue ich mich, wenn es welche gibt. Letztendlich sind wir nicht hier, um zu kämpfen, sondern um (hoffentlich) die Standpunkte des anderen zu bereichern 😅

Bearbeiten:

Die Dateigröße sollte vorab abgerufen werden (wie letztes Zugriffsdatum / letztes Schreibdatum) - es ist so wichtig, dass sie bei einer Dateiabfrage vorab abgerufen werden sollte.

Oh richtig, ja, einige davon sollten auf jeden Fall vorab abgerufen werden. Ich stimme zu, dass dies für uns Entwickler etwas unbequem ist.

Diese Diskussion hätte hier nicht stattgefunden, wenn wir tatsächlich einen Ort gehabt hätten, um diese Fragen zu stellen, und WinRT an anderer Stelle auf Feedback hören könnte.

Offiziell ist der Feedback-Hub dafür gedacht (glaube ich), aber ja, es fühlt sich manchmal etwas nicht an. Hoffentlich verbessert sich der Feedback-Hub. Soweit ich sehen kann, haben sie im Laufe der Zeit bereits einige Änderungen vorgenommen, daher denke ich, dass sich dies hoffentlich auch ändern wird.

@Felix-Dev

Hier ist noch einmal der .NET 5-Ankündigungspost

Danke für die Verlinkung. Ich fand diesen Teil besonders interessant, und ich glaube, das sind positive Neuigkeiten:

"Java-Interoperabilität wird auf allen Plattformen verfügbar sein.

Es gibt auch ein wenig Java-Diskussion in den Kommentaren am Ende dieser Webseite, wo Rich Lander die Zwei-Wege-Interop bestätigt. Ich interpretiere das als positives Zeichen, dass Microsoft wieder mit der Realität

Ob es Ihnen gefällt oder nicht, es ist notwendig, aufzuwachen und die Realität der Situation anzuerkennen: Marktführer ist Android mit seinem Fokus auf Java-App-Entwicklung. Java und C# bedeuten verwalteten Code. Microsoft hat einen sehr kostspieligen Fehler gemacht, als es seinen Standpunkt zu verwaltetem Code änderte.

Auch wenn ich Java nicht wirklich mag, ist mir klar, dass die Java-Techniken von Android viel besser sind als die klobige alte Art und Weise, in der Microsoft WebView2 mit der Verwendung von antiken Win16-Programmiertechniken wie 16-Bit- versus 32-Bit-Zeigern entwickelt , und HRESULT anstelle der modernen Ausnahmebehandlung usw. WebView2 verwendet LPCWSTR und L bedeutet "langer Zeiger", was einen 32-Bit-Zeiger im Gegensatz zum 16-Bit-Zeiger bedeutet "kurze" Zeiger in Win16. W bedeutet "breite Zeichen", was Unicode (UTF-16) im Gegensatz zu 8-Bit-ASCII/ANSI-Zeichen bedeutet. Im Vergleich dazu ist die Verwendung von Java bei Android weitaus professioneller, moderner und vertrauenserweckender als das, was einige Abteilungen von Microsoft tun.

Positiv zu vermerken ist also, dass Microsoft Java unterstützen wird (auch wenn ich persönlich C# gegenüber Java bevorzuge). Android-App-Entwickler werden ihr Interesse an Windows steigern, sobald ein gutes, zuverlässiges Java-Interop veröffentlicht wird.

Außerdem wissen wir jetzt, dass mit WinUI 3.0 ein Win32/.NET-App-Framework kommen wird - es macht wenig Sinn, sie noch immer als WinRT zu kritisieren. 😁

1. Die Zukunft ist rosig, ich liebe, was ich sehe, was in WinUI entwickelt wird.
2. Die Vergangenheit war ziemlich düster, für eine Plattform mit 900 MILLIONEN Geräten ist die geringe Verbreitung von UWP schwer zu verteidigen. EDIT: Die Vergangenheit ist der einzige Ort, aus dem wir lernen können, daher ist es wichtig zu diskutieren.
3. Die Gegenwart ist meiner Meinung nach der Kernpunkt dieses Threads und wird nicht angesprochen. Wenn jemand heute eine nicht triviale App starten möchte, deren Entwicklung 1-1,5 Jahre dauern wird, welcher ehrliche Rat kann ihm gegeben werden? Meine Antwort wäre: Experimentieren Sie mit WinUI, erstellen Sie Ihre Bibliotheken in dotnet Core und warten Sie, bis WinUI3.0 herauskommt, um wirklich mit der Erstellung Ihrer App zu beginnen. Kümmern Sie sich nicht um UWP, da Sie es sowieso aus Ihrer App werfen möchten. Sie möchten wahrscheinlich keine anderen Plattformen, da die 900 Millionen eine ziemlich groß ist. Die Fragen der Gegenwart sind nicht trivial, unternehmerische Entscheidungen müssen heute getroffen werden.

Was nicht gesagt wird, aber was wirklich passiert ist, dass UWP und die moderne Benutzeroberfläche nicht auf Win32 erweitert werden, sondern UWP tatsächlich AUS dem Stapel umgestaltet wird . Warum sollte sich jemand mit UWP befassen, wenn er die Leistung von Dotnet Standard 2 und Dotnet Core 3 und allen damit verfügbaren Libs nutzen könnte?

Über Sandboxing und andere gute Ideen, die in UWP eingeführt wurden: Sie waren gute Ideen, hätten aber viel besser umgesetzt werden können. Ich hoffe, dass sie zurückkommen und es die Möglichkeit geben wird, OPT-IN in eine Sandbox oder OPT-IN in die Zustandsverwaltung ähnlich wie UWP zu integrieren. Als Entwickler möchten wir den Benutzern dienen, aber in UWP wurden wir als das Problem bedroht, das die Plattform enthalten musste.

Welche ehrlichen Ratschläge gibt es? Warte ab?

@AndrewPawlowski Wenn Sie festgestellt haben, dass UWP und die Sandbox für Sie nicht funktionieren, denke ich, dass das Schreiben einer MSIX-gepackten WPF-App eine gute Wahl ist, bis WinUI 3 landet. Sie können bereits Windows 10 exklusive APIs aufrufen, dem Benutzer ein modernes Installations-/Deinstallationserlebnis bieten und im Allgemeinen aus der Windows 10-API-Oberfläche auswählen, was Ihnen gefällt und was nicht (dh Sie können mit der Verwendung von Windows 10 Shell-APIs beginnen). Im Vergleich zu früheren Win32-Methoden macht es wirklich Spaß, mit einigen WinRT-APIs zu arbeiten, und einige Szenarien lassen sich meiner Meinung nach sogar am besten auf DesktopBridge statt auf reinem UWP ausführen. Ein typisches Beispiel: Registrieren einer App für den automatischen Start bei der Anmeldung. In diesem Beitrag finden Sie einen Vergleich des Verhaltens von UWP und DesktopBridge. Im Fall von DesktopBridge überlässt man zwar letztendlich dem Benutzer die Kontrolle, aber der Benutzer wird nicht ständig zweimal gefragt (zuerst ein Umschalten in der App, dann eine Systemabfrage zur Bestätigung), wenn er den Start bei der Anmeldung aktiviert. in der App.

Leider zeigen viele Teile der WPF-APIs jetzt wirklich ihr Alter im Vergleich zu UWP-UI-APIs, sodass Sie nur noch ein paar Monate (mindestens) damit leben müssen. Die vielen verfügbaren WPF-Toolkits werden diese Tatsache mildern, aber wenn Sie wirklich ein natives Erscheinungsbild für Ihre Windows-Desktop-App (und eine moderne XAML-Entwicklungserfahrung!) wünschen, werden Sie den UWP-UI-APIs wirklich nicht entkommen (und später die WinUI 3-APIs). Das heißt, selbst wenn Sie später einen Teil des WPF-UI-Codes für WinUI wiederverwenden können, wird die Modernisierung der Benutzeroberfläche meiner Meinung nach immer noch eine ziemlich große Arbeitsaufgabe sein.

Dies ist der Stand der nativen Windows-App-Entwicklung, den ich derzeit für Sie sehe, wenn Sie nicht warten können, bis WinUI 3 ausgeliefert wird und UWP keine Option für Sie ist.

@AndrewPawlowski

1. Die Zukunft ist rosig, ich liebe, was ich sehe, was in WinUI entwickelt wird.

Zustimmung

1. Die Vergangenheit war ziemlich düster, für eine Plattform mit 900 MILLIONEN Geräten ist die geringe Verbreitung von UWP schwer zu verteidigen. EDIT: Die Vergangenheit ist der einzige Ort, aus dem wir lernen können, daher ist es wichtig zu diskutieren.
2. Die Gegenwart ist meiner Meinung nach der Kernpunkt dieses Threads und wird nicht angesprochen. Wenn jemand heute eine nicht triviale App starten möchte, deren Entwicklung 1-1,5 Jahre dauern wird, welcher ehrliche Rat kann ihm gegeben werden? Meine Antwort wäre: Experimentieren Sie mit WinUI, erstellen Sie Ihre Bibliotheken in dotnet Core und warten Sie, bis WinUI3.0 herauskommt, um wirklich mit der Erstellung Ihrer App zu beginnen. Kümmere dich nicht um UWP, weil

Mein erster Gedanke war der gleiche, aber ich habe nicht gewartet....

Über Sandboxing und andere gute Ideen, die in UWP eingeführt wurden: Sie waren gute Ideen, hätten aber viel besser umgesetzt werden können.

Einverstanden 100%

Ich kenne jedoch möglicherweise nicht alle Geschäftsfälle, die den Zugriff auf alle Dateien erfordern würden, also freue ich mich, wenn es welche gibt. Letztendlich sind wir nicht hier, um zu kämpfen, sondern um (hoffentlich) die Standpunkte des anderen zu bereichern 😅

Überall, wo Sie eine Vorschau anzeigen möchten, benötigen Sie schnellen Zugriff auf Dateien. In meinem Fall möchte ich eine Vorschau der Ordner anzeigen, um dem Benutzer visuell zu zeigen, wo sich die Fotos/Videos befinden, und bei Videos möchte ich, dass der Benutzer das Video in der Vorschau anzeigt, bevor er es auswählt. Der springende Punkt ist: Die Dateiauswahl bietet ein ziemlich unterdurchschnittliches Erlebnis, und das wollte ich bereichern.

Offiziell ist der Feedback-Hub dafür gedacht (glaube ich), aber ja, es fühlt sich manchmal etwas nicht an. Hoffentlich verbessert sich der Feedback-Hub. Soweit ich sehen kann, haben sie im Laufe der Zeit bereits einige Änderungen vorgenommen, daher denke ich, dass sich dies hoffentlich auch ändern wird (^∇^)

Persönlich mag ich den Feedback-Hub nicht - er ist unter anderem zu unspezifisch.

@jtorjo @chingucoding Feedback-Hub für WinRT-APIs könnte bald durch Microsoft Q&A ersetzt/gepaart werden, sehen Sie sich diesen Commit an: https://github.com/MicrosoftDocs/winrt-api/commit/efcc4e041122e8a816a12c0581199c2f36ba36fc

Da Chigusa dort erwähnt wurde: @chigy Wird die Microsoft Q&A-Plattform die bevorzugte Feedback-Plattform für Nicht-WinUI-WinRT-APIs sein? Wenn nicht, wie verhält es sich mit dem Feedback-Hub (dh Dateifehler/Fragen zu Q&A, API-Anfragen zum Feedback-Hub,...)?

Hoffentlich landen wir nicht bei drei verschiedenen Feedback-Plattformen 😆

Da dies eine Diskussion über UWP ist, kann ich eine Funktionsanfrage hervorheben: Kontextmenüverben mit Datei-Explorer-Integration zulassen, ohne eine Dateitypzuordnung https://aka.ms/AA71n2t btw. https://aka.ms/AA6rmrk (aber es ist in der falschen Kategorie - vielleicht kann das jemand beheben?)

Eine gute Quelle für Funktionsanfragen ist:
https://web.archive.org/web/20161221051552/https://wpdev.uservoice.com/forums/110705-universal-windows-platform/category/171141-missing-apis
Schade, dass der Schnappschuss dieser Uservoice ziemlich alt ist (2016). Ich kann mich erinnern, dass es Dinge gab wie:

• Richten Sie das Verhalten der broadFileSystemAccess-Anfrage so aus, wie es sich beim Anfordern von Kamera, Standort, Starten der App beim Start verhalten würde...
• Auto. Drucken (wird derzeit nur für POS im IoT unterstützt, soweit ich mich erinnere)
• Machen Sie das Drucken konfigurierbarer

@jtorjo

Überall, wo Sie eine Vorschau anzeigen möchten, benötigen Sie schnellen Zugriff auf Dateien. In meinem Fall möchte ich eine Vorschau der Ordner anzeigen, um dem Benutzer visuell zu zeigen, wo sich die Fotos/Videos befinden, und bei Videos möchte ich, dass der Benutzer das Video in der Vorschau anzeigt, bevor er es auswählt. Der springende Punkt ist: Die Dateiauswahl bietet ein ziemlich unterdurchschnittliches Erlebnis, und das wollte ich bereichern.

Ich vermute, dass Sie dafür zuerst den Benutzer einen Ordner auswählen lassen, in dem er Ihre App verwenden möchte. Schließlich weiß der User am besten, wo er seine Videos gespeichert hat.

Ansonsten sollten Sie sich Folgendes ansehen:
https://docs.microsoft.com/en-us/windows/uwp/files/quickstart-managing-folders-in-the-music-pictures-and-videos-libraries

Aber um ehrlich zu sein, weiß ich nicht, was Ihnen broadFileSystemAccess in diesem Fall helfen würde. Sie können nicht sicher sein, wo genau sich die Dateien befinden (im Gegensatz zum Benutzer). Aber vielleicht verstehe ich die Idee Ihrer App nicht richtig.

@Felix-Dev
Danke für die Informationen, wusste nicht, dass sich WinRT-Feedback verschieben könnte.

Hoffentlich landen wir nicht bei drei verschiedenen Feedback-Plattformen 😆

Haha ja hoffentlich nicht!

@jtorjo -- Haben Sie daran , die Portierung Ihrer App von WPF auf UWP abzubrechen? Sie können es abbrechen und warten, bis WinUI 3 veröffentlicht wird, und dann werden Sie nicht gezwungen, die problematische UWP-Dateisystem-API, broadFileSystemAccess usw. zu verwenden. In der Zwischenzeit können Sie, während Sie auf WinUI 3 warten, fortfahren Stellen Sie Ihren Benutzern neue Versionen Ihrer App bereit, indem Sie die WPF-Version Ihrer App weiterentwickeln.

In den 8 Jahren seit dem Beginn von WinRT haben wir unseren Benutzern nie eine WinRT- oder UWP-App zur Verfügung gestellt. Stattdessen haben wir ihnen viele Updates gegeben, die weiterhin die WPF-Version unserer Software verwenden. Unsere Benutzer haben keine Beschwerden darüber, weil sie sich nicht um technische Details wie WPF, WinUI, UWP kümmern, sondern sich darum kümmern, wie gut die App funktioniert und welche Funktionen sie hat. Unsere Benutzer haben auch keine Beschwerden über alte GUI, da unsere WPF-Apps eine Reihe von GUI-Modernisierungen enthalten.

@AndrewPawlowski sagte "experimentieren Sie mit WinUI". Ja, experimentieren. Ich habe im Laufe der Jahre eine Menge Code für UWP und WinUI geschrieben, aber es ist alles experimenteller, Alpha- oder Betacode. Ich habe nie einen Punkt erreicht, an dem ich mich wohl genug fühlte, UWP-Apps für Benutzer freizugeben.

Die Trennung von WinUI 3 von UWP ist eine große Hilfe, aber ich glaube nicht, dass es eine vollständige Lösung ist. WinUI 3 geht nicht auf die geringe Produktivität/das langsame Entwicklungstempo von WinUI ein: WPF wurde viel schneller entwickelt als WinUI, obwohl WPF schwieriger als WinUI war.

Das WinUI-Team sagt, dass sich das Tempo beschleunigen wird, wenn WinUI 3 Open Source ist, und vielleicht wird es das, aber ich persönlich werde keine C++/CX-, C++/WinRT-, Win16/32- oder COM-Beiträge für WinUI 3 schreiben begann meine Karriere mit Win16/Win32 vor Jahrzehnten, und Win32 war ein Albtraum, und ich habe nicht die Absicht, jemals zu solch alten und problematischen Programmiertechniken zurückzukehren. Im Laufe der Jahre habe ich meine Software-Engineering-Kenntnisse auf dem neuesten Stand gehalten und bin auf C# und .NET Framework umgestiegen Tage und große Mengen an manuell geschriebenem nativem Code.

@AndrewPawlowski schrieb:

Welche ehrlichen Ratschläge gibt es? Warte ab?

Das ist eine wirklich schwer zu beantwortende Frage. Einerseits, ja, warten Sie auf WinUI 3, aber andererseits ist WinUI 3 keine vollständige Lösung des großen Problems, das vor 8 Jahren von WinRT initiiert wurde. WinUI 3 ist eine hilfreiche Teilauflösung.

Tolles Video von Ignite: https://youtu.be/Ul5JcdIJv5s

Ich denke, ein Großteil der Diskussion hier stellt den Zweck von WinRT in Frage. Entwickler und Benutzer fragen sich immer noch, welche Rolle es spielen wird, wenn WinUI 3 und .NET 5.0 eine einfache Interaktion zwischen den verschiedenen Technologien ermöglichen. Ganz zu schweigen von der Möglichkeit, zwischen Sandkasten- und klassischen App-Modellen zu wählen.

Ich gehe davon aus, dass das Schreiben neuer WinRT-APIs für Microsoft intern einfacher ist, was erklärt, warum sie schon oft erklärt haben, dass die meisten Innovationen auf der API-Ebene innerhalb von WinRT durchgeführt werden. Dies bedeutet, dass es für neue, moderne Windows-Anwendungen sinnvoll ist, WinRT zu verwenden, da es die neuesten und besten Integrationen mit neuen Erfahrungen bietet, die mit den neuen Formfaktoren einhergehen. WinRT ist nur als ein bestimmter Satz universeller APIs gedacht, die in Ihrer .NET-App unter Windows aufleuchten.

Vor diesem Hintergrund denke ich, dass wir uns alle einig sind, dass universelle Apps wertvoller werden würden, wenn das UWP Desktop Extension Pack bessere Integrationsfähigkeiten mit der vorhandenen Windows-Shell hätte.

Wer weiß, Microsoft hat möglicherweise Pläne, die Windows Explorer-Shell irgendwann durch die neuere Composable Shell (CShell) in Windows 10X usw. zu ersetzen. Experten auf Twitter haben auch ein neues UDK (Undocked Development Kit) in Windows entdeckt, das möglicherweise bessere Integration mit dieser neuen Shell in der Zukunft.

@AndrewPawlowski

Sie möchten wahrscheinlich keine anderen Plattformen, da die 900 Millionen eine ziemlich groß ist.

Während ich verstehe, was Sie meinen, müssen Sie erkennen, dass UWP und .NET nicht mehr diese sich gegenseitig ausschließenden Dinge sind. Wenn es also sinnvoll ist, Ihre App mit universellen Funktionen zu starten, sollte man in das Verständnis von Teilen von WinRT investieren.

Ich schweife ab. Als jemand, der einen Konkurrenten für den Windows-Datei-Explorer mit einem reinen UWP-App-Modell entwickelt hat, kann WinUI 3 nicht schnell genug kommen. In naher Zukunft müssen Sie sich nicht zwischen Universalfunktionen und den "900 Millionen Nutzern" entscheiden 😀

@jtorjo Ich würde empfehlen, den Titel in einen Titel zu ändern, der weniger negativ wahrgenommen wird, damit mehr Leute hier Beiträge leisten.
Vielleicht "Möglichkeiten, WinRT einen Mehrwert zu verleihen"

@verelpode

@jtorjo -- Haben Sie daran , die Portierung Ihrer App von WPF auf UWP abzubrechen? Sie können es abbrechen und warten, bis WinUI 3 veröffentlicht wird, und dann werden Sie nicht gezwungen, die problematische UWP-Dateisystem-API, broadFileSystemAccess usw. zu verwenden. In der Zwischenzeit können Sie, während Sie auf WinUI 3 warten, fortfahren Stellen Sie Ihren Benutzern neue Versionen Ihrer App bereit, indem Sie die WPF-Version Ihrer App weiterentwickeln.

Ich habe lange und intensiv darüber nachgedacht - das war es, was ich tun wollte. Aber ich kann es nicht, weil ich wirklich win2d brauche (oder besser gesagt einen guten Wrapper über Direct2D). ShapDX (ein weiterer Wrapper für Direct2D) schien viel komplizierter zu sein, also entschied ich mich für win2d (das ist UWP). Portieren Sie daher alles nach UWP.

Ich vermute, dass Sie dafür zuerst den Benutzer einen Ordner auswählen lassen, in dem er Ihre App verwenden möchte. Schließlich weiß der User am besten, wo er seine Videos gespeichert hat.

Wetten Sie wirklich Ihr Leben darauf? Ich würde es nicht tun - klar, wenn Sie ein fortgeschrittener Benutzer sind, sind Sie vielleicht wahnsinnig organisiert und wissen, wo sich alles befindet. Andernfalls....

Und dann, wenn Sie (der Benutzer) Fotos/Videos irgendwie in einen neuen Ordner kopieren, müssen Sie daran denken, meiner App mitzuteilen, dass sie dies ebenfalls einschließen soll...

Um nicht zu sagen, dass die "großartige" FutureAccessList - nicht wirklich spezifiziert -> wenn ich einen Ordner hinzufüge, werden dann alle seine Unterordner für meine App zugänglich sein?

Wenn ich FutureAccessList etwas hinzugefügt habe, muss ich es dann von dort abrufen oder kann ich es mit GetFolderFromPathAsync/GetFileFromPathAsync abrufen (es ist ersteres, ich würde lieber von einer Klippe springen)?

Und wussten Sie, dass Sie eine Ausnahme erhalten, wenn Sie FutureAccessList.AddOrReplace verwenden und den Pfad der Datei als Token verwenden? Wie nachdenklich ... (es steht nirgendwo in der Beschreibung)

WinUI 3 und .NET Core werden in Zukunft eine Option sein - ich gehe davon aus, dass diese Kombination ohne UWPs Sandbox genauso funktioniert wie WPF, aber mit den neueren XAML-Steuerelementen, Visual Layer und einfachem WinRT-API-Zugriff.

Ich vermute, dass Sie dafür zuerst den Benutzer einen Ordner auswählen lassen, in dem er Ihre App verwenden möchte. Schließlich weiß der User am besten, wo er seine Videos gespeichert hat.

Wetten Sie wirklich Ihr Leben darauf? Ich würde es nicht tun - klar, wenn Sie ein fortgeschrittener Benutzer sind, sind Sie vielleicht wahnsinnig organisiert und wissen, wo sich alles befindet. Andernfalls....

Nun, wenn der Benutzer nicht weiß, wo er seine Videos gespeichert hat, was soll Ihre App tun? Alle Dateien im System scannen, was selbst mit der schnellsten Software Stunden dauern kann? Zumindest für mich scheint dies keine gute Erfahrung zu sein. Wenn sich Ihre App schließlich an Nutzer richtet, die etwas mit Videos machen wollen, sind die Nutzer schon einigermaßen „organisiert“ in dem Sinne, dass sie wissen, dass sie irgendwo Videos haben. Aber wieder nur meine Gedanken, ohne Ihre App und Ihren spezifischen Business Case wirklich zu kennen.

Und dann, wenn Sie (der Benutzer) Fotos/Videos irgendwie in einen neuen Ordner kopieren, müssen Sie daran denken, meiner App mitzuteilen, dass sie dies ebenfalls einschließen soll...

Ich denke, wenn Sie Zugriff auf das übergeordnete Verzeichnis haben, können Sie auch auf zukünftige untergeordnete Ordner zugreifen (ich bin mir jedoch nicht 100% sicher).

Und wussten Sie, dass Sie eine Ausnahme erhalten, wenn Sie FutureAccessList.AddOrReplace verwenden und den Pfad der Datei als Token verwenden? Wie nachdenklich ... (es steht nirgendwo in der Beschreibung)

Das ist seltsam, das sollte unbedingt dokumentiert werden!

Persönlich bin ich nicht wirklich ein Fan von Apps, die "broadFileSystemAccess" anfordern, da viele von ihnen es nicht brauchen. Vielleicht gibt es einige Fälle, in denen es Sinn macht (einen Datei-Explorer schreiben usw.), aber viele Fälle, die Zugriff auf EINIGE Ordner benötigen, sollten nicht sagen "Bitte erlauben Sie mir den Zugriff auf alle Dateien", da Sie auch danach fragen könnten dass Ordner insbesondere.

Aber vielleicht kenne ich dafür nicht genug Business Cases. Wenn es noch mehr gibt, würde ich sie gerne hören!

Aber vielleicht kenne ich dafür nicht genug Business Cases. Wenn es noch mehr gibt, würde ich sie gerne hören!

• Tools und Utilities-Software, wie ein (De-)Kompressions-Tool. Wenn Sie die komprimierte Datei in das gleiche Verzeichnis entpacken möchten, in dem sich die aktuelle Datei befindet und die App über das Kontextmenü des Windows-Explorers aufgerufen wurde, haben Sie nur Schreibzugriff auf die ausgewählte Datei. Kann also keine neue Datei oder ein neues Verzeichnis erstellen (für die unkomprimierte(n) Datei(en)).

  • Wenn der Benutzer die Datei in Ihre uwp-App gezogen hat, haben Sie keinen Schreibzugriff auf diese Datei!
    https://stackoverflow.com/questions/48001601/c-sharp-uwp-drag-and-drop-file-folder-permission?rq=1

wie ein (De-)Kompressionswerkzeug. Wenn Sie die komprimierte Datei in das gleiche Verzeichnis entpacken möchten, in dem sich die aktuelle Datei befindet und die App über das Kontextmenü des Windows-Explorers aufgerufen wurde, haben Sie nur Schreibzugriff auf die ausgewählte Datei. Kann also keine neue Datei oder ein neues Verzeichnis erstellen (für die unkomprimierte(n) Datei(en)).

Ich denke, es ist sehr fraglich, ob Sie Zugriff auf den gesamten Ordner erhalten sollten, wenn Sie mit der rechten Maustaste auf eine einzelne Datei klicken oder nicht. Allerdings gebe ich beim Komprimieren/Dekomprimieren normalerweise einen anderen Ordner an, da ich diese normalerweise nur zum "Austauschen" brauche, dh für Backups oder Downloads/Uploads. Daher ist es für mich fast notwendig, anzugeben, wo genau die Dateien gespeichert werden sollen. Dies kann jedoch je nach Wahl des Benutzers ein gültiger Anwendungsfall sein 😅

Wenn der Benutzer die Datei in Ihre uwp-App gezogen hat, haben Sie keinen Schreibzugriff auf diese Datei!
https://stackoverflow.com/questions/48001601/c-sharp-uwp-drag-and-drop-file-folder-permission?rq=1

Nun, das scheint für Benutzer und Entwickler nur ein bisschen zu kompliziert zu sein. Ich hätte erwartet, dass Sie zumindest Schreibzugriff auf die abgelegten Dateien bekommen. Meiner Meinung nach ist dies nur eine unnötige Einschränkung für Entwickler.

Obwohl ich zumindest im täglichen Gebrauch von Apps nur Dateien in GitHub-Kommentare lege. Für jeden anderen Fall doppelklicke ich einfach oder klicke mit der rechten Maustaste, aber in einigen Fällen stimmte das einfach nicht so gut. Ich denke, es gibt doch einige Fälle, in denen es sinnvoll wäre, auf alle Dateien zugreifen zu können.

Nun, wenn der Benutzer nicht weiß, wo er seine Videos gespeichert hat, was soll Ihre App tun? Alle Dateien im System scannen, was selbst mit der schnellsten Software Stunden dauern kann? ...

Es gibt offensichtlich viele Möglichkeiten, eine davon ist, wenn der Benutzer einen Ordner erweitert, eine Vorschau für ihn anzuzeigen - so sieht er leicht, welche Ordner Fotos/Videos enthalten und welche nicht. Eine Sache würde meine App tatsächlich tun, wenn Windows mich zulassen würde

Persönlich bin ich nicht wirklich ein Fan von Apps, die "broadFileSystemAccess" anfordern, da viele von ihnen es nicht brauchen.

Ich ist egal. Das Dateisystem-Schutzmodell der Sandbox von WinRT ist weit von der Realität entfernt. Es ist etwas, das jemand aus dem großartigen Mantra "Mobile first" übernommen hat, das einfach nicht auf den Desktop zutrifft.

Tatsächlich besteht eine viel intelligentere Methode zum Sandboxen von Dateien/Ordnern darin, den Benutzer entscheiden zu lassen, welche Dateien/Ordner er schützen möchte - es sollte einen sehr einfachen Weg geben (z. B. im Datei-Explorer mit einem Rechtsklickbefehl). .

Dies steht im Gegensatz dazu, dass standardmäßig alles blockiert wird und Benutzer Ihnen versehentlich versehentlich Zugriff auf vertrauliche Dateien gewähren.

Lassen Sie mich hier direkt sein - jede nicht triviale App lebt nicht in einem Vakuum.

Es gibt offensichtlich viele Möglichkeiten, eine davon ist, wenn der Benutzer einen Ordner erweitert, eine Vorschau für ihn anzuzeigen - so sieht er leicht, welche Ordner Fotos/Videos enthalten und welche nicht. Eine Sache würde meine App tatsächlich tun, wenn Windows mich zulassen würde

Ja das ist eine Möglichkeit. Aber wann scannen Sie den Ordner? Und welche Ordner genau kann der Nutzer in Ihrer App expandieren?

Ich ist egal.

Was genau willst du hier sagen?

Tatsächlich besteht eine viel intelligentere Methode zum Sandboxen von Dateien/Ordnern darin, den Benutzer entscheiden zu lassen, welche Dateien/Ordner er schützen möchte - es sollte einen sehr einfachen Weg geben (z. B. im Datei-Explorer mit einem Rechtsklickbefehl). . Benutzer werden eindeutig wissen, welche Dokumente/Dateien vertraulich sind, und diese schützen.

Ich denke, bei diesem ganzen Zugriffsschutz geht es nicht nur um "vertrauliche" Dateien, sondern um Datenschutz im Allgemeinen, z. B. Konfigurationsdateien (die normalerweise in Ordnern versteckt sind, die Benutzer nicht sehen) oder nur welche Programme installiert sind. Dies sind Informationen, auf die ich nicht möchte, dass jedes Programm darauf zugreifen kann, insbesondere "triviale Apps", wie Sie sie genannt haben.

Und es gibt auch eine Analogie aus der realen Welt – denken Sie nur an Seifs.

Ja, Sie können in Safes Sachen wegsehen. Das ändert aber nichts daran, dass Sie einen Schlüssel zu Ihrer Wohnung oder Ihrem Haus haben. Aber zu sagen, dass jedes Programm auf alles zugreifen kann, außer in einem Safe, ist wie zu sagen, Sie brauchen keine Tür für Ihre Wohnung, weil Sie einen Safe für Ihre Wertsachen haben.

Dies steht im Gegensatz dazu, dass standardmäßig alles blockiert wird und Benutzer Ihnen versehentlich versehentlich Zugriff auf vertrauliche Dateien gewähren.

Diese Fehler können in beiden Fällen auftreten, aber ich denke, es ist wahrscheinlicher, dass das Sperren einer vertraulichen Datei vergessen wird, als versehentlich Zugriff auf eine vertrauliche Datei zu gewähren.

Lassen Sie mich hier direkt sein - jede nicht triviale App lebt nicht in einem Vakuum. Es muss Daten von irgendwo (Eingabe) abrufen und irgendwo ausgeben. Die Eingabe und Ausgabe sind oft Dateien - Sie müssen mit anderen Apps interagieren und so weiter. Und WinRT macht es mir einfach zu unmöglich, eine schöne Benutzeroberfläche zu entwerfen, die ich meinen Benutzern zur Verfügung stellen kann.

Zu sagen, es sei unmöglich, ist hier weit hergeholt, da es viele großartige UWP-Apps gibt (wenn auch leider nicht viele).

Ja das ist eine Möglichkeit. Aber wann scannen Sie den Ordner? Und welche Ordner genau kann der Nutzer in Ihrer App expandieren?

Kennen Sie das Konzept des Windows Explorers? Sie erweitern einen Ordner oder ein Laufwerk - dann würde ich mit dem Scannen beginnen

Ich denke, bei diesem ganzen Zugriffsschutz geht es nicht nur um "vertrauliche" Dateien, sondern um Datenschutz im Allgemeinen, z. B. Konfigurationsdateien (die normalerweise in Ordnern versteckt sind, die Benutzer nicht sehen) oder nur welche Programme installiert sind. Dies sind Informationen, auf die ich nicht möchte, dass jedes Programm darauf zugreifen kann, insbesondere "triviale Apps", wie Sie sie genannt haben.

Dies ist kein Problem, wenn die App ihre Dateien in ihrem eigenen Ordner "nur diese App kann darauf zugreifen" speichern würde.

Dies steht im Gegensatz dazu, dass standardmäßig alles blockiert wird und Benutzer Ihnen versehentlich versehentlich Zugriff auf vertrauliche Dateien gewähren.

Diese Fehler können in beiden Fällen auftreten, aber ich denke, es ist wahrscheinlicher, dass das Sperren einer vertraulichen Datei vergessen wird, als versehentlich Zugriff auf eine vertrauliche Datei zu gewähren.

Ich bin völlig anderer Meinung - der ganze Punkt "vertraulich" sollte Sie dazu bringen, diese Datei zu sperren.

Zu sagen, es sei unmöglich, ist hier weit hergeholt, da es viele großartige UWP-Apps gibt (wenn auch leider nicht viele).

Sie widersprechen sich hier selbst. Aber lassen Sie uns in die Weite großartiger UWP-Apps eintauchen:

Beachten Sie die "Fülle" von Likes, die Ihnen sagen sollten, wie viele Leute es verwenden. Ich wollte einen Kontrast zum Apfelladen geben, aber ich kann nicht, da ich keinen Apfel habe. Aber sehen wir uns Android an - Facebook hat über 70 Millionen Bewertungen (im Vergleich zu 1353 unter Windows). Instagram hat über 93 Millionen Bewertungen (im Vergleich zu 1578 hier). Und ich bin mir fast sicher, dass sowohl Fb als auch Instagram tatsächlich Elektron-Apps sind, nicht UWP.

Kennen Sie das Konzept des Windows Explorers? Sie erweitern einen Ordner oder ein Laufwerk - dann würde ich mit dem Scannen beginnen

Sie erstellen also etwas Ähnliches wie Windows Explorer, das eine Vorschau von Videodateien in Ordnern anzeigt?

Dies ist kein Problem, wenn die App ihre Dateien in ihrem eigenen Ordner "nur diese App kann darauf zugreifen" speichern würde.

Apps sollten also einerseits generell Zugriff auf alle Dateien haben, andererseits werden aber einige Dateien und Ordner vom Nutzer gesperrt (da er nur "vertrauliche" Dateien hat und alles andere automatisch nicht vertraulich ist) und manche Ordner sind von Apps selbst blockiert? Und was ist, wenn ich eine App programmieren möchte, die mit Dateien umgeht, die von Programmen generiert wurden? Würde jedes Backup-Programm fehlschlagen, da es nicht in der Lage wäre, Programme zu sichern? Ich bin mir nicht ganz sicher, wie das funktionieren würde, und es tut mir leid, wenn ich Ihre Idee hier falsch verstanden habe.

Ich bin völlig anderer Meinung - der ganze Punkt "vertraulich" sollte Sie dazu bringen, diese Datei zu sperren.

Was genau würde ich nicht als vertraulich auswählen? Ich möchte nicht, dass jede App meine Urlaubsbilder sieht, aber Photoshop sollte sie sehen können. Sind sie also vertraulich oder nicht? Oder ist dieses vertrauliche "Flag" eine Liste von Programmen und einige Dateien sind für einige Apps nicht vertraulich?

Sie widersprechen sich hier selbst.

Ja, meine Formulierung war dort Quatsch. Das tut mir leid. Ich wollte darauf hinweisen, dass es definitiv großartige, nicht "triviale" Apps gibt, die einfach gut funktionieren.

Beachten Sie die "Fülle" von Likes, die Ihnen sagen sollten, wie viele Leute es verwenden. Ich wollte einen Kontrast zum Apfelladen geben, aber ich kann nicht, da ich keinen Apfel habe. Aber sehen wir uns Android an - Facebook hat über 70 Millionen Bewertungen (im Vergleich zu 1353 unter Windows). Instagram hat über 93 Millionen Bewertungen (im Vergleich zu 1578 hier). Und ich bin mir fast sicher, dass sowohl Fb als auch Instagram tatsächlich Elektron-Apps sind, nicht UWP.

Dies ist kein Problem mit UWP, sondern eher mit der Tatsache, dass:

1. Die Leute neigen normalerweise nicht dazu, Kommentare zu schreiben
2. Der iTunes Store/Google Play Store ist viel älter als der Microsoft Store
3. Der Microsoft Store kam bei den Nutzern nicht gut an und startete nicht gut
4. Die meisten Unternehmen bevorzugen die Entwicklung von Websites anstelle von plattformbeschränkten Apps

Und ich bin mir fast sicher, dass sowohl Fb als auch Instagram tatsächlich Elektron-Apps sind, nicht UWP.

Es ist schwer zu sagen, ob es sich um Elektron handelt oder nicht, da die Website und die App sehr unterschiedlich aussehen. Aufgrund der Tatsache, dass die Dialoge fast genauso aussehen wie die Standarddialoge, können sie UWP-Apps sein.

Sie erstellen also etwas Ähnliches wie Windows Explorer, das eine Vorschau von Videodateien in Ordnern anzeigt?

Das ist ein Teil eines Assistenten aus meiner App.

Apps sollten also einerseits generell Zugriff auf alle Dateien haben, andererseits werden aber einige Dateien und Ordner vom Nutzer gesperrt (da er nur "vertrauliche" Dateien hat und alles andere automatisch nicht vertraulich ist) und manche Ordner sind von Apps selbst blockiert? Und was ist, wenn ich eine App programmieren möchte, die mit Dateien umgeht, die von Programmen generiert wurden?

Meine Idee war das Gegenteil von dem, was wir jetzt haben. Ich sage nicht, dass es perfekt ist, bei weitem nicht – aber alles ist besser als das, was jetzt passiert. Standardmäßig haben Sie also Zugriff auf alle nicht vertraulichen Dateien. Wenn Sie Zugang zu vertraulichen Dateien benötigen, müssen Sie zuerst nachfragen.

Was genau würde ich nicht als vertraulich auswählen? Ich möchte nicht, dass jede App meine Urlaubsbilder sieht, aber Photoshop sollte sie sehen können. Sind sie also vertraulich oder nicht? Oder ist dieses vertrauliche "Flag" eine Liste von Programmen und einige Dateien sind für einige Apps nicht vertraulich?

So wie ich es sehe, würde dieses "Flag" eine Datei oder einen Ordner als "Zugriff verweigert" anzeigen. Wenn Sie wirklich darauf zugreifen wollten, könnten Sie um Erlaubnis bitten, und der Benutzer könnte wählen, ob er es Ihnen erteilen möchte oder nicht (und die Erlaubnis könnte - nur dieses Mal oder für immer) sein.

Ja, meine Formulierung war dort Quatsch. Das tut mir leid. Ich wollte darauf hinweisen, dass es definitiv großartige, nicht "triviale" Apps gibt, die einfach gut funktionieren.

Ich sage nicht, dass es keine gibt. Ich sage, es ist wahnsinnig schwer, einen zu machen, verglichen mit WPF.
Ich sage, ich verschwende Tage damit, mich mit Problemen zu befassen, die einfach nicht existieren sollten.

Zum Beispiel erhalte ich manchmal eine Ausnahme (eine COM-Ausnahme, um genau zu sein), und anstatt sie an der Fehlerstelle zu erhalten, erhalte ich sie tatsächlich in einem anderen Thread, und meistens ist sogar der Stack-Trace hat verloren. Herauszufinden, was passiert ist, ist sehr, sehr schmerzhaft.

Ein weiteres Problem ist das ganze Mantra "Lasst Informationen asynchron erhalten" - was ich sehr hasse. Ich beschäftige mich mit Rendering, das sofort erfolgen muss, aber das Laden von Bitmaps ist asynchron. Also musste ich nur dafür einen wirklich komplizierten Caching-Mechanismus bauen.

Und lass uns nicht in Compile-Zeiten einsteigen. Und in letzter Zeit bekomme ich manchmal beim Erstellen eine "...dll wird im Release-Modus erstellt" (was im Grunde nicht sein kann, weil ich Debug erstelle). Die Problemumgehung besteht darin, einfach alle Lösungen zu bereinigen und neu zu erstellen (was mehr als 1 Minute dauert).

Und ja, Abstürze. VS stürzt alle 10-20 Läufe ab, warum.

Und das sind die Themen, die mir gerade durch den Kopf gegangen sind. Es gibt unzählige weitere.

Dies ist kein Problem mit UWP, sondern eher mit der Tatsache, dass:

1. Die Leute neigen normalerweise nicht dazu, Kommentare zu schreiben
2. Der iTunes Store/Google Play Store ist viel älter als der Microsoft Store
3. Der Microsoft Store kam bei den Nutzern nicht gut an und startete nicht gut
4. Die meisten Unternehmen bevorzugen die Entwicklung von Websites anstelle von plattformbeschränkten Apps

Nun, ich wünschte, ich hätte einen Apple Store Vergleich gehabt - ich bin mir ziemlich sicher, dass ihre Top-Apps Millionen von Bewertungen haben. Die Idee ist, dass sich MS Store nie durchgesetzt hat - weil die Leute UWP/WinRT einfach aufgeben. Hätte ich win2d nicht gebraucht, hätte ich mindestens 20 mal aufgegeben.

Denken Sie nur daran - ich muss Windows bitten, als UWP-App in den Vollbildmodus zu wechseln. Das ist mehr als verrückt. Und um es noch dümmer zu machen, gilt das erst beim nächsten Lauf .

Ich habe mir die API "Grab a screenshot of the screen" angesehen - ich habe sie einfach aufgegeben, sie ist nutzlos. Ich wollte im Grunde eine coole Möglichkeit haben, die App basierend auf dem aktuellen Bildschirm zu starten (sozusagen einen Übergang in meine App) -> es ist nicht möglich, weil es eine Benutzerinteraktion erfordert (nämlich muss der Benutzer sagen - ja , ich möchte erlauben, einen Screenshot aufzunehmen, was das Ganze ruiniert)

Lassen Sie mich nicht mit der Zwischenablage beginnen – die funktioniert nur, wenn sich Ihre App im Vordergrund befindet. Und um es noch lustiger zu machen, dachte Microsoft: "Wir geben Ihnen beim Debuggen jederzeit Zugriff auf die Zwischenablage", aber in der Veröffentlichung erhalten Sie eine nette Ausnahme "Zugriff verweigert". Weißt du, wie viele Stunden ich gebraucht habe, um endlich herauszufinden, warum meine App im Release nicht gestartet wurde (während im Debug alles nur Dandy war)

Die Liste geht weiter – ich glaube, ich könnte ein Buch schreiben. Sicher, UWP/WinRT sind theoretisch cool. Aber wenn Sie anfangen zu verwenden, na ja..

Es ist schwer zu sagen, ob es sich um Elektron handelt oder nicht, da die Website und die App sehr unterschiedlich aussehen. Aufgrund der Tatsache, dass die Dialoge fast genauso aussehen wie die Standarddialoge, können sie UWP-Apps sein.

Richtig, mein Punkt ist - die Leute geben UWP-Apps auf - die Vorteile werden durch die vielen damit verbundenen Probleme aufgewogen.

@jtorjo
(Nur um sicherzustellen, dass Sie sich dessen bewusst sind.)

Lassen Sie mich nicht mit der Zwischenablage beginnen – die funktioniert nur, wenn sich Ihre App im Vordergrund befindet.

Ich habe das gleiche (oder ein ähnliches) Problem während der Entwicklung einer meiner UWP-Apps erreicht, bei dem ich Daten in die Zwischenablage legen musste, und am Ende habe ich es über einen begleitenden Win32-Full-Trust-Prozess gelöst (der nur Win32s SetClipboardData aufruft ). Wenn Ihnen das Konzept eines begleitenden Win32-Full-Trust-Prozesses für Ihre UWP-App neu ist, finden Sie hier eine gute Einführung (der Autor hat zuvor bei Microsoft an der UWP gearbeitet).

@Felix-Dev

Ich habe das gleiche (oder ein ähnliches) Problem während der Entwicklung einer meiner UWP-Apps erreicht, bei dem ich Daten in die Zwischenablage legen musste, und am Ende habe ich es über einen begleitenden Win32-Full-Trust-Prozess gelöst (der nur Win32s SetClipboardData aufruft ). Wenn Ihnen das Konzept eines begleitenden Win32-Full-Trust-Prozesses für Ihre UWP-App neu ist, finden Sie hier eine gute Einführung (der Autor hat zuvor bei Microsoft an der UWP gearbeitet).

Danke für den Hinweis! Ich wusste über den Win32-Full-Trust-Prozess Bescheid. Ich habe diese Artikel wahrscheinlich mehrmals gelesen :) Ich habe tatsächlich mehrmals darüber nachgedacht, eine Win32-Begleit-App für den vollständigen Vertrauensprozess zu haben. Ich habe mich wegen der zusätzlichen Komplexität dagegen entschieden - ich habe bereits Probleme damit, Setup-Kits zu generieren, die tatsächlich ohne den MS Store funktionieren. Ich wollte das nur nicht mit in die Gleichung einbeziehen.

Sie erstellen also etwas Ähnliches wie Windows Explorer, das eine Vorschau von Videodateien in Ordnern anzeigt?

Das ist ein Teil eines Assistenten aus meiner App.

Das klingt nach einem Datei-Explorer mit zusätzlichen Schritten (⊙ˍ⊙)

Meine Idee war das Gegenteil von dem, was wir jetzt haben. Ich sage nicht, dass es perfekt ist, bei weitem nicht – aber alles ist besser als das, was jetzt passiert. Standardmäßig haben Sie also Zugriff auf alle nicht vertraulichen Dateien. Wenn Sie Zugang zu vertraulichen Dateien benötigen, müssen Sie zuerst nachfragen.

Im Grunde wird Ihre App am Ende wahrscheinlich auf das gleiche Problem stoßen wie jetzt, da Sie nie wissen würden, ob Dateien vertraulich sind. Was ist mit den Benutzern, die alles als vertraulich markieren? Sie haben also gerade das gleiche System wie jetzt erstellt, nur mit mehr Variationen, auf die Sie zugreifen können.

Zum Beispiel erhalte ich manchmal eine Ausnahme (eine COM-Ausnahme, um genau zu sein), und anstatt sie an der Fehlerstelle zu erhalten, erhalte ich sie tatsächlich in einem anderen Thread, und meistens ist sogar der Stack-Trace hat verloren. Herauszufinden, was passiert ist, ist sehr, sehr schmerzhaft.

Wenn das bei Ihnen oft vorkommt, ist das sehr ärgerlich. Für mich hatte jedoch fast jede Ausnahme, die bei mir auftrat (zB in der XCG) einen StackTrace zugeordnet und manchmal sogar nützliche Ausnahmemeldungen. Dazu kann ich nichts sagen, da es für mich nie wirklich ein Thema war.

Ein weiteres Problem ist das ganze Mantra "Lasst Informationen asynchron erhalten" - was ich sehr hasse. Ich beschäftige mich mit Rendering, das sofort erfolgen muss, aber das Laden von Bitmaps ist asynchron. Also musste ich nur dafür einen wirklich komplizierten Caching-Mechanismus bauen.

Manchmal ist Async etwas nervig, aber in den meisten Fällen haben Async-Methoden einen Grund, asynchron zu sein, da Sie die Benutzeroberfläche bei Vorgängen wie Netzwerk- oder Dateivorgängen nicht blockieren möchten. Allerdings können Sie die folgenden Methoden verwenden, um Ihre asynchrone Methode synchron auszuführen:

```c#
// Wird den Thread blockieren, bis MyAsyncMethod fertig ist
var myResult = MyAsyncMethod().Result;

// Dies wird auch beendet, wenn die Ausführung der Methode beendet ist.
// Beachten Sie, dass ConfigureAwait dazu führen kann, dass die Methode in einem anderen Kontext aufgerufen wird
var myResult2 = MyAsyncMethod().ConfigureAwait(false);
`` For ConfigureAwait` können Sie sich folgenden Artikel ansehen: https://devblogs.microsoft.com/dotnet/configureawait-faq/

Und lass uns nicht in Compile-Zeiten einsteigen. Und in letzter Zeit bekomme ich manchmal beim Erstellen eine "...dll wird im Release-Modus erstellt" (was im Grunde nicht sein kann, weil ich Debug erstelle). Die Problemumgehung besteht darin, einfach alle Lösungen zu bereinigen und neu zu erstellen (was mehr als 1 Minute dauert).

Die "...dll" ist im Release-Modus eingebaut ist seltsam. Vielleicht prüfen, ob die Projektdateien inkohärent sind? Was die Kompilierzeit angeht, ja, das ist ein bisschen nervig, obwohl ~1 Minute immer noch okay ist, WinUI dauert ungefähr 5-10 Minuten 😅

Und ja, Abstürze. VS stürzt alle 10-20 Läufe ab, warum.

Ja, das ist ziemlich ärgerlich, obwohl ich denke, dass dies nicht wirklich von UWP abhängt, sondern nur von Visual Studio im Allgemeinen (es ist aus gutem Grund immer noch ein 32-Bit-Prozess!).

Nun, ich wünschte, ich hätte einen Apple Store Vergleich gehabt - ich bin mir ziemlich sicher, dass ihre Top-Apps Millionen von Bewertungen haben. Die Idee ist, dass sich MS Store nie durchgesetzt hat - weil die Leute UWP/WinRT einfach aufgeben. Hätte ich win2d nicht gebraucht, hätte ich mindestens 20 mal aufgegeben.

Es scheint, dass Sie Win2D mit WPF verwenden können: https://github.com/Microsoft/Win2D/issues/660

Denken Sie nur daran - ich muss Windows bitten, als UWP-App in den Vollbildmodus zu wechseln. Das ist mehr als verrückt. Und um es noch dümmer zu machen, gilt das erst beim nächsten Lauf.

Es scheint möglich zu sein, Ihre UWP-App auch beim Start in den Vollbildmodus zu bringen: https://stackoverflow.com/questions/31758775/windows-10-universal-app-run-in-fullscreen-mode-by-default
(Obwohl ich nicht versucht habe, damit eine App einzureichen)

Ich habe mir die API "Grab a screenshot of the screen" angesehen - ich habe sie einfach aufgegeben, sie ist nutzlos. Ich wollte im Grunde eine coole Möglichkeit haben, die App basierend auf dem aktuellen Bildschirm zu starten (sozusagen einen Übergang in meine App) -> es ist nicht möglich, weil es eine Benutzerinteraktion erfordert (nämlich muss der Benutzer sagen - ja , ich möchte erlauben, einen Screenshot aufzunehmen, was das Ganze ruiniert)

Die meisten Benutzer möchten nicht, dass Apps ohne ihre Erlaubnis willkürlich Bilder von ihrem Bildschirm aufnehmen. Sie haben vielleicht kein Problem damit, aber ich habe sicherlich und viele andere auch.

Lassen Sie mich nicht mit der Zwischenablage beginnen – die funktioniert nur, wenn sich Ihre App im Vordergrund befindet. Und um es noch lustiger zu machen, dachte Microsoft: "Wir geben Ihnen beim Debuggen jederzeit Zugriff auf die Zwischenablage", aber in der Veröffentlichung erhalten Sie eine nette Ausnahme "Zugriff verweigert". Weißt du, wie viele Stunden ich gebraucht habe, um endlich herauszufinden, warum meine App im Release nicht gestartet wurde (während im Debug alles nur Dandy war)

Ja, Sie erhalten eine Ausnahme, aber die Tatsache, dass Ihre App nicht darauf zugreifen kann, wenn sie nicht im Fokus ist, wird in der Dokumentation erwähnt:

https://docs.microsoft.com/en-us/uwp/api/windows.applicationmodel.datatransfer.clipboard

Aber warum benötigen Sie Zugriff auf die Zwischenablage, wenn der Benutzer Ihre App nicht verwendet? Wenn Sie versuchen, die Zwischenablage einzurichten, während der Benutzer Ihre App nicht verwendet, wird der Benutzer irritiert, wenn Sie beim Kopieren/Einfügen stören. Und wenn Sie die Zwischenablage lesen, wenn der Benutzer Ihre App nicht dazu auffordert, spionieren Sie ihn aus. Sofern dies nicht Ihr Ziel ist (in diesem Fall sollten Sie auf keinen Fall UWP verwenden), gibt es nur sehr wenige Gründe, die Zwischenablage auszulesen, während Ihre App nicht im Fokus ist (wenn überhaupt).

Richtig, mein Punkt ist - die Leute geben UWP-Apps auf - die Vorteile werden durch die vielen damit verbundenen Probleme aufgewogen.

Vielleicht, aber auch dadurch, dass es einfacher ist, eine Website zu schreiben und in Electron zu packen und an Mac, Linux und Windows auszuliefern, anstatt separate Apps für alle Plattformen zu schreiben.

Das klingt nach einem Datei-Explorer mit zusätzlichen Schritten (⊙ˍ⊙)

Es ist nicht. Weit davon entfernt.

Im Grunde wird Ihre App am Ende wahrscheinlich auf das gleiche Problem stoßen wie jetzt, da Sie nie wissen würden, ob Dateien vertraulich sind. Was ist mit den Benutzern, die alles als vertraulich markieren? Sie haben also gerade das gleiche System wie jetzt erstellt, nur mit mehr Variationen, auf die Sie zugreifen können.

Ich sage nicht, dass meine Lösung die richtige ist. Natürlich würde ich es vorziehen, überhaupt nicht in einer Sandbox zu sein, ich sage nur, dass die aktuelle Implementierung sehr schlecht ist.

Manchmal ist Async etwas nervig, aber in den meisten Fällen haben Async-Methoden einen Grund, asynchron zu sein, da Sie die Benutzeroberfläche bei Vorgängen wie Netzwerk- oder Dateivorgängen nicht blockieren möchten. Allerdings können Sie die folgenden Methoden verwenden, um Ihre asynchrone Methode synchron auszuführen:

Das ist falsch. Dies setzt einfach voraus, dass ich immer vom UI-Thread aus anrufe. Ich meine, das ist sicher für einfache Dinge in Ordnung, aber ich kann meine eigenen Threads erstellen und ich kann auch meine eigenen Aufgaben erstellen und dort Dinge erledigen.

Alles asynchron zu haben, zwingt mich nur dazu, immer await aufzurufen und Funktionen asynchron zu markieren.

[...] Für ConfigureAwait kannst du dir folgenden Artikel ansehen: https://devblogs.microsoft.com/dotnet/configureawait-faq/

Danke, ich kenne mich damit aus. Ein weiteres Problem, auf das ich gestoßen bin, war das Laden einer Bitmap (asynchron), genau wie Sie es vorgeschlagen haben. Hin und wieder hatte ich wahnsinnige Wartezeiten, wie 5-6 Sekunden, um eine Bitmap zu laden.
Am Ende habe ich Workarounds gemacht.

Die "...dll" ist im Release-Modus eingebaut ist seltsam. Vielleicht prüfen, ob die Projektdateien inkohärent sind? Was die Kompilierzeit angeht, ja, das ist ein bisschen nervig, obwohl ~1 Minute immer noch okay ist, WinUI dauert ungefähr 5-10 Minuten 😅

Ja, darüber will ich gar nicht nachdenken :) Ich bin mir nicht sicher, was Sie damit meinen, dass Projektdateien inkohärent sind.

Und ja, Abstürze. VS stürzt alle 10-20 Läufe ab, warum.

Ja, das ist ziemlich ärgerlich, obwohl ich denke, dass dies nicht wirklich von UWP abhängt, sondern nur von Visual Studio im Allgemeinen (es ist aus gutem Grund immer noch ein 32-Bit-Prozess!).

Ich glaube, es hängt mit UWP zusammen. Das ist mir beim Umgang mit WPF nie passiert - ich hatte 28 Projekte und es stürzte nie ab. In UWP habe ich 15 Projekte (die ich von WPF portiert habe) und es stürzt ab. Und wenn ich in der Ereignisanzeige nachschaue, gibt es etwas über das Abstürzen der Sandbox - ich erinnere mich nicht genau.

Es scheint, dass Sie Win2D mit WPF verwenden können: microsoft/Win2D#660

Das war mein erster Versuch. Es ist ein absolutes No-Go. Ich hatte so viele Probleme, dass ich aufgab. Der Code, der mit win2d umgeht, ist ziemlich komplex, daher dachte ich, es würde viel länger dauern, ihn auf WPF zu schreiben, als UWP direkt zu verwenden.

So sehr ich das UWP-Setup auch hasse, ich hatte Recht. Ich hätte es nie richtig hinbekommen. Und ich nehme an, Sie kennen https://github.com/microsoft/Win2D/issues/731

Denken Sie nur daran - ich muss Windows bitten, als UWP-App in den Vollbildmodus zu wechseln. Das ist mehr als verrückt. Und um es noch dümmer zu machen, gilt das erst beim nächsten Lauf.

Es scheint möglich zu sein, Ihre UWP-App auch beim Start in den Vollbildmodus zu bringen: https://stackoverflow.com/questions/31758775/windows-10-universal-app-run-in-fullscreen-mode-by-default

Es tut mir leid, ich meinte "maximal gehen" - sorry dafür.

Ja, Sie erhalten eine Ausnahme, aber die Tatsache, dass Ihre App nicht darauf zugreifen kann, wenn sie nicht im Fokus ist, wird in der Dokumentation erwähnt:

Das Problem ist - wir haben ein anderes Verhalten in Debug als in Release. Es sollte konsistent sein.

https://docs.microsoft.com/en-us/uwp/api/windows.applicationmodel.datatransfer.clipboard

Aber warum benötigen Sie Zugriff auf die Zwischenablage, wenn der Benutzer Ihre App nicht verwendet? […]

Das Lustige ist, dass ich beim Start etwas in die Zwischenablage kopieren wollte. Dies war jedoch im Konstruktor von MainPage, also war ich anscheinend noch nicht im Vordergrund. Funktionierte pfirsich im Debug, stürzte im Release ab -- und damit meine ich genau beim Start, kein Logging, kein nichts.

Richtig, mein Punkt ist - die Leute geben UWP-Apps auf - die Vorteile werden durch die vielen damit verbundenen Probleme aufgewogen.

Vielleicht, aber auch dadurch, dass es einfacher ist, eine Website zu schreiben und in Electron zu packen und an Mac, Linux und Windows auszuliefern, anstatt separate Apps für alle Plattformen zu schreiben.

Wenn es um Plattformunabhängigkeit geht, ist das ein ganz neues Thema – was ich meinte, ist die Tatsache, dass viele Probleme, auf die Menschen bei der Entwicklung von UWP-Apps stoßen, einfach nicht existieren sollten. Der Wechsel von WPF zu UWP war eine sehr schlechte Erfahrung.

@chingucoding

Aber warum benötigen Sie Zugriff auf die Zwischenablage, wenn der Benutzer Ihre App nicht verwendet? Wenn Sie versuchen, die Zwischenablage einzurichten, während der Benutzer Ihre App nicht verwendet, wird der Benutzer irritiert, wenn Sie beim Kopieren/Einfügen stören. Und wenn Sie die Zwischenablage lesen, wenn der Benutzer Ihre App nicht dazu auffordert, spionieren Sie ihn aus. Sofern dies nicht Ihr Ziel ist (in diesem Fall sollten Sie auf keinen Fall UWP verwenden), gibt es nur sehr wenige Gründe, die Zwischenablage auszulesen, während Ihre App nicht im Fokus ist (wenn überhaupt).

In meinem Fall zeigt meine App von Zeit zu Zeit eine Benachrichtigung an, wenn ein Ereignis eintritt, auf das die App achtet. Die Toast-Benachrichtigung kann Informationen enthalten, die der Benutzer weiter verarbeiten/in einem anderen Kontext verwenden möchte, daher stelle ich eine Aktionsschaltfläche [in die Zwischenablage kopieren] bereit, die einige der angezeigten Informationen kopiert. Da jederzeit eine Benachrichtigung eintreffen kann und die App zu diesem Zeitpunkt möglicherweise im Hintergrund ist, muss ich in diesem Fall einen Win32-Hilfsprozess verwenden.

Die Verwendung von Win32 außerhalb der UWP-Sandbox liegt nicht immer daran, dass der Entwickler etwas erreichen möchte, ohne dass der Benutzer davon erfährt. Obwohl die Sandbox für uns Benutzer im Allgemeinen einen Wert bietet, müssen Sie sich auf jeden Fall als Entwickler damit auseinandersetzen, auch wenn Sie kein bösartiger Entwickler sind, der nichts dagegen hat, den Benutzer auszuspionieren oder nicht die Absicht hat, danach zu fragen Zustimmung des Benutzers, bevor er etwas an seinem System ändert.

Die Tatsache , dass Sie eine Win32 - Voll Vertrauen Prozess , der neben Ihrer Anwendung verwenden können , zeigt an, dass MS sich dieses Dilemmas bewusst ist und gibt uns die Werkzeuge Devs UWP zu nutzen und noch in der Lage sein , die Freiheit von Win32 zu einem guten Teil zu genießen.

Es ist nicht. Weit davon entfernt.

Kann man die App jetzt herunterladen? Wenn ja wo finde ich es? 😅

Natürlich würde ich es vorziehen, überhaupt nicht in einer Sandbox zu sein, ich sage nur, dass die aktuelle Implementierung sehr schlecht ist.

Ich denke, wenn Sie die Sandbox nicht mögen, ist der Wechsel zu einer WPF-Alternative möglicherweise die bessere Wahl, anstatt nur zu versuchen, Ihre Apps in UWP zu entwickeln, was Sie für "unmöglich" oder "wahnsinnig schwer" halten Apps entwickeln für. Ich denke nicht, dass die WPF-Alternativen im Vergleich zu Win2D so schlecht sind, dass Sie all Ihre Kämpfe durchmachen würden. Aber das ist nur meine Meinung dazu.

Außerdem ist die aktuelle Implementierung "schlecht" für Leute, die es gewohnt sind, keine Einschränkungen in Bezug auf Dateien zu haben. Da ich einen Webentwicklungshintergrund habe, bin ich damit sehr gut. Ich kann ihren Platz sehen, zumal das Web auch Einschränkungen hat, deren Zweck es ist, Benutzer zu schützen.

Ich bin mir nicht sicher, was Sie mit inkohärenten Projektdateien meinen.

Vielleicht sind die Projektdateien für das Debuggen falsch und einige DLLs werden in der Veröffentlichung generiert, obwohl ich bezweifle, dass dies passieren würde, wenn Sie Visual Studio nur damit umgehen lassen.

Ich glaube, es hängt mit UWP zusammen. Das ist mir beim Umgang mit WPF nie passiert - ich hatte 28 Projekte und es stürzte nie ab. In UWP habe ich 15 Projekte (die ich von WPF portiert habe) und es stürzt ab. Und wenn ich in der Ereignisanzeige nachschaue, gibt es etwas über das Abstürzen der Sandbox - ich erinnere mich nicht genau.

Die Zuverlässigkeit von Visual Studio hängt für mich stark von der Projektgröße ab. Kleine/mittlere UWP/NetCore/NetFramework funktionieren immer einwandfrei. Große Projekte führen dazu, dass Visual Studio nicht mehr reagiert, hängen bleibt oder einfach abstürzt. Aber das ist nur meine Erfahrung.

Es tut mir leid, ich meinte "maximal gehen" - sorry dafür.

In diesem Fall wird die Änderung nur beim nächsten Start angewendet, da Sie den Wert dafür festlegen, NACHDEM Ihre App gestartet wurde. Ich weiß nicht, was du mit "ich muss Windows fragen" meinst. Beziehst du dich auf die Tatsache, dass du es in Code setzen musst?

Es gibt auch eine Möglichkeit, die bevorzugte Größe einzustellen, was dazu führen sollte, dass die App den gesamten Platz auf dem Bildschirm einnimmt, auf dem sie sich befindet (ähnlich wie maximiert), obwohl sie nicht ganz so gut ist wie echte maximierte:
https://stackoverflow.com/questions/35247320/how-to-maximize-a-uwp-window-not-fullscreen?rq=1

Das ist falsch. Dies setzt einfach voraus, dass ich immer vom UI-Thread aus anrufe. Ich meine, das ist sicher für einfache Dinge in Ordnung, aber ich kann meine eigenen Threads erstellen und ich kann auch meine eigenen Aufgaben erstellen und dort Dinge erledigen.

Wenn Sie bereits eigene Threads verwenden, sollte die Verwendung von await kein Problem für Sie sein. Auch wenn Sie separate Threads verwenden, werden Ereignishandler immer im UI-Thread ausgeführt. Wenn Sie also dort umfangreiche Berechnungen durchführen, reagiert die App nicht mehr.

So sehr ich das UWP-Setup auch hasse, ich hatte Recht. Ich hätte es nie richtig hinbekommen. Und ich nehme an, Sie kennen Microsoft/Win2D#731

Das war mir nicht bewusst, ich dachte, dass das Problem, das ich von 2018 erwähnt habe, jetzt gut gelöst wäre.

Das Problem ist - wir haben ein anderes Verhalten in Debug als in Release. Es sollte konsistent sein.

Hm das ist sehr seltsam. Das Verhalten sollte konsistent sein.

Das Lustige ist, dass ich beim Start etwas in die Zwischenablage kopieren wollte.

Sie erwähnen diesen Anwendungsfall auch in der Dokumentation, und Sie sollten warten, bis CoreWindow.Activated kopiert wurde. Warum sollten Sie jedoch etwas in die Zwischenablage kopieren, wenn der Benutzer Ihre App gerade gestartet hat? Etwas Ähnliches wie das, was @Felix-Dev erreichen/erreicht haben möchte?

@Felix-Dev Vielen Dank für Ihre Antwort. An dieses Szenario habe ich nicht gedacht. In diesem Fall müssen Sie auf die Zwischenablage zugreifen, was die Benutzererfahrung definitiv verbessert. Ich vermute, dass dies funktioniert hätte, da Ihr Toast "Fokus hat". Aber ich denke, es ist nicht der Fall.

Obwohl die Sandbox für uns Benutzer im Allgemeinen einen Wert bietet, müssen Sie sich auf jeden Fall als Entwickler damit auseinandersetzen, auch wenn Sie kein bösartiger Entwickler sind, der nichts dagegen hat, den Benutzer auszuspionieren oder nicht die Absicht hat, danach zu fragen Zustimmung des Benutzers, bevor er etwas an seinem System ändert.

Ja, wir müssen damit umgehen, aber viele Apps werden nicht durch die Sandbox so eingeschränkt, dass es sehr schwierig wäre, einen Workaround zu finden. Und eine Sache, die Sie nicht vergessen sollten, ist, dass es noch 2 andere Optionen gibt, wenn UWP für Sie nicht funktioniert.

Zu Ihrem letzten Punkt: Ja, die Tatsache, dass Sie Win32-Prozesse verwenden können, ist ein Hinweis darauf, dass es Fälle gibt, in denen UWP Sie einschränkt.
Vielleicht war dies die einfachste/schnellste Problemumgehung, oder vielleicht ist es tatsächlich beabsichtigt.

Es ist nicht. Weit davon entfernt.

Kann man die App jetzt herunterladen? Wenn ja wo finde ich es? 😅

Hier -> https://photo-awe.com

Ich denke, wenn Sie die Sandbox nicht mögen, ist der Wechsel zu einer WPF-Alternative möglicherweise die bessere Wahl, anstatt nur zu versuchen, Ihre Apps in UWP zu entwickeln, was Sie für "unmöglich" oder "wahnsinnig schwer" halten Apps entwickeln für. Ich denke nicht, dass die WPF-Alternativen im Vergleich zu Win2D so schlecht sind, dass Sie all Ihre Kämpfe durchmachen würden. Aber das ist nur meine Meinung dazu.

Dies war eine WPF-Anwendung. Aufgrund der Natur der Videobearbeitung bin ich jedoch in Bezug auf die Geschwindigkeit lange an die Grenzen von WPF gestoßen (im Wesentlichen beim Umgang mit DrawingVisual ). Glauben Sie mir, ich hätte das nicht getan, wenn ich die Wahl gehabt hätte.

Außerdem ist die aktuelle Implementierung "schlecht" für Leute, die es gewohnt sind, keine Einschränkungen in Bezug auf Dateien zu haben. Da ich einen Webentwicklungshintergrund habe, bin ich damit sehr gut. Ich kann ihren Platz sehen, zumal das Web auch Einschränkungen hat, deren Zweck es ist, Benutzer zu schützen.

Ich hätte schwören können, dass du aus einem Web-Hintergrund kommst :)

Vielleicht sind die Projektdateien für das Debuggen falsch und einige DLLs werden in der Veröffentlichung generiert, obwohl ich bezweifle, dass dies passieren würde, wenn Sie Visual Studio nur damit umgehen lassen.

Das ist nicht der Fall, aber ich habe es doppelt überprüft - nicht der Fall.

Die Zuverlässigkeit von Visual Studio hängt für mich stark von der Projektgröße ab. Kleine/mittlere UWP/NetCore/NetFramework funktionieren immer einwandfrei. Große Projekte führen dazu, dass Visual Studio nicht mehr reagiert, hängen bleibt oder einfach abstürzt. Aber das ist nur meine Erfahrung.

Ja, damit habe ich mich in der Vergangenheit beschäftigt. Scheint bei den neuesten Versionen von VS (2017,2019) nicht der Fall zu sein. Wie auch immer, lange Rede kurzer Sinn, das ist mir gerade auf UWP passiert. Es kann damit zu tun haben, dass ich win2d verwende, und ich habe das Gefühl, dass es sich um ein ziemlich kompliziertes Tier handelt.

In diesem Fall wird die Änderung nur beim nächsten Start angewendet, da Sie den Wert dafür festlegen, NACHDEM Ihre App gestartet wurde. Ich weiß nicht, was du mit "ich muss Windows fragen" meinst. Beziehst du dich auf die Tatsache, dass du es in Code setzen musst?

In WPF stelle ich einfach die Fenstergröße so ein, wie ich sie haben möchte. Hier gibt es eine API, die Sie aufrufen müssen -> ApplicationView.PreferredLaunchViewSize - die, wie die Dokumentation sagt, "funktioniert, außer in Fällen, in denen das System die Fenstergröße direkt verwaltet". - und ja, es funktioniert nur beim nächsten App-Start.

Es gibt auch eine Möglichkeit, die bevorzugte Größe einzustellen, was dazu führen sollte, dass die App den gesamten Platz auf dem Bildschirm einnimmt, auf dem sie sich befindet (ähnlich wie maximiert), obwohl sie nicht ganz so gut ist wie echte maximierte:
https://stackoverflow.com/questions/35247320/how-to-maximize-a-uwp-window-not-fullscreen?rq=1

Ich verwende einen anderen Code, der tatsächlich richtig funktioniert

var view = DisplayInformation.GetForCurrentView();
var resolution = new Size(view.ScreenWidthInRawPixels, view.ScreenHeightInRawPixels);
var scale = view.ResolutionScale == ResolutionScale.Invalid ? 1 : view.RawPixelsPerViewPixel;
var bounds = new Size(resolution.Width / scale, resolution.Height / scale);

ApplicationView.PreferredLaunchViewSize = new Size(bounds.Width, bounds.Height);
ApplicationView.PreferredLaunchWindowingMode = ApplicationViewWindowingMode.PreferredLaunchViewSize;

Wenn Sie bereits eigene Threads verwenden, sollte die Verwendung von await kein Problem für Sie sein. Auch wenn Sie separate Threads verwenden, werden Ereignishandler immer im UI-Thread ausgeführt. Wenn Sie also dort umfangreiche Berechnungen durchführen, reagiert die App nicht mehr.

Offensichtlich werden die Ereignishandler im UI-Thread ausgeführt. Ich habe mich irgendwie daran gewöhnt, ich musste einiges an meiner App ändern - nur asynchrone Funktionen hinzufügen ... Was mich immer noch wirklich stört, ist, dass es für mich so aussieht, als hätten einige APIs dies übernommen bis zum Extrem, nur Async()-Versionen zu haben, wo es keinen Sinn macht.

Das war mir nicht bewusst, ich dachte, dass das Problem, das ich von 2018 erwähnt habe, jetzt gut gelöst wäre.

Hat es nicht - zumindest habe ich das letzte Mal nachgesehen.

Das Problem ist - wir haben ein anderes Verhalten in Debug als in Release. Es sollte konsistent sein.

Hm das ist sehr seltsam. Das Verhalten sollte konsistent sein.

Ja, das hat mich wirklich genervt. Und klar, dass ich bei Nicht-UWP-Apps wahnsinnig lange mit der Zwischenablage gearbeitet habe, ich dachte nicht, dass wir diese Einschränkungen haben würden, also ja, ich habe nicht gelesen, dass ich auf CoreWindow.Activated warten muss. Allerdings ist es unglaublich mühsam, all diese Details zu lernen. Es ist, als müsste ich eine ganz neue Sprache lernen. Anstatt ein nahtloser Prozess zu sein, scheint es, dass ich jede Woche etwas erfahre, das mich einfach umhaut.

Sie erwähnen diesen Anwendungsfall auch in der Dokumentation, und Sie sollten warten, bis CoreWindow.Activated kopiert wurde. Warum sollten Sie jedoch etwas in die Zwischenablage kopieren, wenn der Benutzer Ihre App gerade gestartet hat? Etwas Ähnliches wie das, was @Felix-Dev erreichen/erreicht haben möchte?

Zu diesem Zeitpunkt testete ich meine App zu Beginn und wollte sie nur einem Kollegen für weitere interne Tests geben. Allerdings müsste er einige Einstellungen anpassen. Und die Einstellungen wurden im LocalFolder der Anwendung gespeichert. Dies ist für jeden Benutzer anders, also war meine Einstellung - lass es mich einfach halten und in die Zwischenablage kopieren. Wenn er dann die App startet, geht er dann zu "Dieser PC", fügt den Ort ein und bearbeitet dort eine Einstellungsdatei (jetzt weiß ich, wie ich die App einfach im Explorer hätte öffnen können, aber zu diesem Zeitpunkt habe ich nicht). Was schließlich zum Absturz führte und ich einige gute Stunden lang nachforschte und fluchte.

Hier -> https://photo-awe.com

Vielen Dank!

Dies war eine WPF-Anwendung. Aufgrund der Art der Videobearbeitung bin ich jedoch in Bezug auf die Geschwindigkeit (im Wesentlichen beim Umgang mit DrawingVisual) lange an die Grenzen von WPF gestoßen. Glauben Sie mir, ich hätte das nicht getan, wenn ich die Wahl gehabt hätte.

Wusste nicht, dass WPF im Vergleich zu UWP einen so großen Leistungseinbruch hat.

Das ist nicht der Fall, aber ich habe es doppelt überprüft - nicht der Fall.

Das ist seltsam. Ich hätte erwartet, dass da was nicht stimmt. Warum sollte VS über Release-DLLs sprechen, wenn Sie Debuggen ausführen.

In WPF stelle ich einfach die Fenstergröße so ein, wie ich sie haben möchte. Hier gibt es eine API, die Sie aufrufen müssen - ApplicationView.PreferredLaunchViewSize - die, wie die Dokumentation sagt, "funktioniert, außer in Fällen, in denen das System die Fenstergröße direkt verwaltet".

Aber ist der Code, den Sie verwenden, nicht auch eine API zum Einstellen der Fenstergröße?

• und ja, es funktioniert nur für den nächsten App-Start.

Kein Wunder, wenn es "PreferredLaunchViewSize" heißt 😅
Nur ein bisschen umständlich, dass es nach dem Start keine Möglichkeit gibt, dies einzustellen.

Ja, damit habe ich mich in der Vergangenheit beschäftigt. Scheint bei den neuesten Versionen von VS (2017,2019) nicht der Fall zu sein. Wie auch immer, lange Rede kurzer Sinn, das ist mir gerade auf UWP passiert.

Es freut mich zu hören, dass es nicht so schlimm ist wie bei früheren Versionen von VS.

Es kann damit zu tun haben, dass ich win2d verwende, und ich habe das Gefühl, dass es sich um ein ziemlich kompliziertes Tier handelt.

Ich verlasse mich nicht sehr auf den Designer, da er bei Vorlagenbindungen fehlschlägt. Haben Sie Blend für Visual Studio ausprobiert? Ist das in Bezug auf den Designer zuverlässiger?

Ja, das hat mich wirklich genervt. Und klar, dass ich bei Nicht-UWP-Apps wahnsinnig lange mit der Zwischenablage gearbeitet habe, ich dachte nicht, dass wir diese Einschränkungen haben würden, also ja, ich habe nicht gelesen, dass ich auf CoreWindow.Activated warten muss. Allerdings ist es unglaublich mühsam, all diese Details zu lernen. Es ist, als müsste ich eine ganz neue Sprache lernen. Anstatt ein nahtloser Prozess zu sein, scheint es, dass ich jede Woche etwas erfahre, das mich einfach umhaut.

Ja kann ich mir vorstellen. Etwas, das gut sein könnte, ist eine Übergangsanleitung von WPF zu UWP. Wenn dies existieren würde, würde das neuen UWP- und ehemaligen WPF-Entwicklern definitiv viel Zeit sparen. Und dies wäre nicht das erste Mal, dass es einen Übergangsleitfaden gibt. Es gibt bereits einen Java to C# Guide, der für Java-Entwickler sehr hilfreich ist.

Zu diesem Zeitpunkt testete ich meine App zu Beginn und wollte sie nur einem Kollegen für weitere interne Tests geben. Allerdings müsste er einige Einstellungen anpassen. Und die Einstellungen wurden im LocalFolder der Anwendung gespeichert. Dies ist für jeden Benutzer anders, also war meine Einstellung - lass es mich einfach halten und in die Zwischenablage kopieren. Wenn er dann die App startet, geht er dann zu "Dieser PC", fügt den Ort ein und bearbeitet dort eine Einstellungsdatei (jetzt weiß ich, wie ich die App einfach im Explorer hätte öffnen können, aber zu diesem Zeitpunkt habe ich nicht). Was schließlich zum Absturz führte und ich einige gute Stunden lang nachforschte und fluchte.

Ach ich verstehe. Wenn man nicht daran denkt, den Ordner zu öffnen, ist das Kopieren des Ordnerpfads in die Zwischenablage eine Lösung. Für Testzwecke ist dies recht schlau.

Wusste nicht, dass WPF im Vergleich zu UWP einen so großen Leistungseinbruch hat.

WPF wurde nicht für DirectX optimiert - wenn Pixel-Shader und -Masken ins Spiel kommen, ist es am Ende sehr langsam. Durch die Portierung auf UWP/win2d wurde die App 3-4 Mal schneller. Das ist wahnsinnig auffällig.

Das ist seltsam. Ich hätte erwartet, dass da was nicht stimmt. Warum sollte VS über Release-DLLs sprechen, wenn Sie Debuggen ausführen.

Ja, genau mein Punkt.

Aber ist der Code, den Sie verwenden, nicht auch eine API zum Einstellen der Fenstergröße?

Was ich meine, Sie verwenden Bevorzugte...Größe, aber Sie können nicht garantieren, dass dies der Fall ist. Wie bei der Verwendung von WPF wird Ihnen beim Festlegen von Position/Größe garantiert, dass es tatsächlich passiert.

Kein Wunder, wenn es "PreferredLaunchViewSize" heißt 😅
Nur ein bisschen umständlich, dass es nach dem Start keine Möglichkeit gibt, dies einzustellen.

Das ist mehr als unbequem - es ist wahnsinnig unbequem. Grundsätzlich kann ich die Größe meiner App nicht ändern, sobald sie gestartet wurde. Und ja, ich möchte, dass meine App verschiedene "Betriebsmodi" hat (wie Basic/Advanced) - basierend darauf würde ich mehr oder weniger Platz beanspruchen - ich kann es nicht. Glaubst du, dass der Benutzer mit "Änderungen werden erst nach Neustart erfolgen" einverstanden ist?

Ich verlasse mich nicht sehr auf den Designer, da er bei Vorlagenbindungen fehlschlägt. Haben Sie Blend für Visual Studio ausprobiert? Ist das in Bezug auf den Designer zuverlässiger?

Ich hätte genauer sein sollen - das VS stürzt beim Bearbeiten von xaml nicht ab - es stürzt beim Starten der App ab; Grundsätzlich gehe ich davon aus, dass dies genau bei der Bereitstellung geschieht, da Sie nur das große "x" in der (uwp) App für etwa 10 Sekunden sehen und an diesem Punkt weiß ich, dass es hängt. An diesem Punkt kann ich weitere 45-60 Sekunden warten und sehen, dass VS abstürzt, oder VS einfach über den Task-Manager schließen.

Ja kann ich mir vorstellen. Etwas, das gut sein könnte, ist eine Übergangsanleitung von WPF zu UWP.

Ja, das wäre sehr hilfreich.

Ach ich verstehe. Wenn man nicht daran denkt, den Ordner zu öffnen, ist das Kopieren des Ordnerpfads in die Zwischenablage eine Lösung. Für Testzwecke ist dies recht schlau.

Danke ;) Nun, es wäre schlau gewesen, wenn es tatsächlich funktioniert hätte :)

@chingucoding

Manchmal ist Async etwas nervig, aber in den meisten Fällen haben Async-Methoden einen Grund, asynchron zu sein, da Sie die Benutzeroberfläche bei Vorgängen wie Netzwerk- oder Dateivorgängen nicht blockieren möchten. Allerdings können Sie die folgenden Methoden verwenden, um Ihre asynchrone Methode synchron auszuführen

Lassen Sie mich Ihnen noch einen weiteren Grund nennen, warum ich Async hasse - das ist mir jetzt gerade passiert (im Grunde ist es ein Fehlerbericht eines Benutzers). Anfangs konnte ich es nicht für mein Leben herausfinden.

Lange Rede, kurzer Sinn - auf Knopfdruck öffne ich eine Dateiauswahl. Was, Sie haben es erraten, asynchron ist.

Der Benutzer hat also doppelt darauf geklickt (mit einer Pause von etwa 100 ms zwischen den Klicks). Sicherlich hat dies 2 Dateiauswahl geöffnet.

Nun, klar kann ich dies beheben, aber dies würde nie passieren, wenn die anfängliche Funktion synchron wäre (und dies wird natürlich in WPF nie passieren).

Das ist mehr als unbequem - es ist wahnsinnig unbequem. Grundsätzlich kann ich die Größe meiner App nicht ändern, sobald sie gestartet wurde. Und ja, ich möchte, dass meine App verschiedene "Betriebsmodi" hat (wie Basic/Advanced) - basierend darauf würde ich mehr oder weniger Platz beanspruchen - ich kann es nicht. Glaubst du, dass der Benutzer mit "Änderungen werden erst nach Neustart erfolgen" einverstanden ist?

Nun, "wahnsinnig unbequem" mag für Apps sein, die bestimmte Größen erzwingen müssen, aber in den meisten Fällen müssen Apps die Größe nicht selbst ändern. Wie sollte eine App auswählen, welche Größe aktuell für den Anwendungsfall der Benutzer geeignet ist? Wenn der Benutzer es kleiner oder größer machen muss, dann ist der Benutzer der erste, der dies bemerkt. Zumal er am besten weiß, wo andere offene Fenster sind und wo Platz vorhanden wäre, um die Sichtbarkeit anderer Fenster nicht zu blockieren.

Wenn Sie einen Basis- und einen erweiterten Modus haben, können Sie die bevorzugte Mindestgröße ändern, wenn die App definitiv nicht funktioniert, wenn sie zu klein ist. Aber meiner Meinung nach wäre es für mich sehr irritierend, wenn Programme anfangen würden, ihre Größe selbst zu ändern (und zum Glück tut dies bisher kein Programm).

Ich kann es nicht. Glaubst du, dass der Benutzer mit "Änderungen werden erst nach Neustart erfolgen" einverstanden ist?

Wenn die Größenänderung so wichtig ist, kann ein Benutzer dies selbst tun. Dieses "Änderungen werden erst nach Neustart erfolgen" ist jedoch keine Seltenheit, daher meiner Meinung nach teilweise akzeptabel.

Der Benutzer hat also doppelt darauf geklickt (mit einer Pause von etwa 100 ms zwischen den Klicks). Sicherlich hat dies 2 Dateiauswahl geöffnet.

Warum genau wurde die Dateiauswahl zweimal geöffnet? Hat der Ereignishandler zweimal ausgelöst? Dies ist kein asynchrones Problem, sondern die Tatsache, dass der Ereignishandler die Benutzeroberfläche nicht daran gehindert hat, zusätzliche Ereignisse von der jeweiligen Schaltfläche zu empfangen.

Lange Rede, kurzer Sinn - auf Knopfdruck öffne ich eine Dateiauswahl. Was, Sie haben es erraten, asynchron ist.

Ja, es ist asynchron, weil Sie nicht Ihren gesamten Thread blockieren möchten, während der Benutzer durch sein Laufwerk navigiert und den Ordner auswählt. Der Aufruf ist beendet, wenn der Benutzer mit der Auswahl einer Datei/einem Ordners fertig ist und Sie als Ergebnis die ausgewählte Datei erhalten.

Meiner Meinung nach ist es besser, den Thread bei solchen Operationen nicht zu blockieren, da man nie weiß, wie lange sie tatsächlich dauern. Wenn Sie den UI-Thread deswegen blockieren, reagiert Ihre App nicht mehr, solange eine Dateiauswahl geöffnet ist, was IMO keine gute UX ist.

Lassen Sie mich zunächst respektvoll sagen: Wir werden uns nie auf irgendetwas einigen .

Offensichtlich denken Sie aus der Web-Perspektive und sehen einfach nichts als "Desktop". Ich weiß, Sie meinen es gut, aber Sie denken einfach nicht an "Desktop", bis Sie etwas Kompliziertes entwickelt haben - wenn es um Desktop geht. Und ich glaube, das hast du nicht.

Nun, "wahnsinnig unbequem" mag für Apps sein, die bestimmte Größen erzwingen müssen, aber in den meisten Fällen müssen Apps die Größe nicht selbst ändern. Wie sollte eine App auswählen, welche Größe aktuell für den Anwendungsfall der Benutzer geeignet ist? Wenn der Benutzer es kleiner oder größer machen muss, als der Benutzer

Fragst du das ernsthaft? Soll eine Anwendung dem Benutzer nicht helfen? Und wenn der Benutzer mit der Größe der App nicht einverstanden ist, kann er die Größe ändern. Aber die App sollte in der Lage sein, basierend auf dem, was sie erreichen soll, sagen zu können, dass dies die Größe ist, in der ich laufen sollte. Nehmen wir an, Photoshop - wird immer den Vollbildmodus bevorzugen, da es dem Benutzer viele Informationen anzeigen kann.

Wenn Sie einen Basis- und einen erweiterten Modus haben, können Sie die bevorzugte Mindestgröße ändern, wenn die App definitiv nicht funktioniert, wenn sie zu klein ist. Aber meiner Meinung nach wäre es für mich sehr irritierend, wenn Programme anfangen würden, ihre Größe selbst zu ändern (und zum Glück tut dies bisher kein Programm).

Wenn ja, hast du nicht einmal daran gedacht. Assistenten werden manchmal in kleineren Größen ausgeführt, und wenn der Assistent beendet ist, wird die App möglicherweise im Vollbildmodus angezeigt.

Ich kann es nicht. Glaubst du, dass der Benutzer mit "Änderungen werden erst nach Neustart erfolgen" einverstanden ist?

Wenn die Größenänderung so wichtig ist, kann ein Benutzer dies selbst tun. Dieses "Änderungen werden erst nach Neustart erfolgen" ist jedoch keine Seltenheit, daher meiner Meinung nach teilweise akzeptabel.

Und habe ein schlechtes Starterlebnis, weil ich ein Fenster zeige, das nur eine bestimmte Größe gut aussieht - und Windows sagt nur "Oh, aber ich zeige die App wie ich will".

Warum genau wurde die Dateiauswahl zweimal geöffnet? Hat der Ereignishandler zweimal ausgelöst? Dies ist kein asynchrones Problem, sondern die Tatsache, dass der Ereignishandler die Benutzeroberfläche nicht daran gehindert hat, zusätzliche Ereignisse von der jeweiligen Schaltfläche zu empfangen.

Machst du das ehrlich? Zeigen Sie mir, wie ein Code geschnippelt wurde, wo Sie dies bewusst getan haben.

Meiner Meinung nach ist es besser, den Thread bei solchen Operationen nicht zu blockieren, da man nie weiß, wie lange sie tatsächlich dauern. Wenn Sie den UI-Thread deswegen blockieren, reagiert Ihre App nicht mehr, solange eine Dateiauswahl geöffnet ist, was IMO keine gute UX ist.

Wie geht WPF damit um? Es geht richtig damit um. Die Benutzeroberfläche blockiert nicht, aber die App blockiert bei diesem Aufruf - also würde das oben genannte in WPF nie passieren

Lassen Sie mich zunächst respektvoll sagen: Wir werden uns nie auf irgendetwas einigen.

Wenn dies Ihre Meinung zu dieser Diskussion ist, tut es mir leid.

Offensichtlich denken Sie aus der Web-Perspektive und sehen einfach nichts als "Desktop". Ich weiß, Sie meinen es gut, aber Sie denken einfach nicht an "Desktop", bis Sie etwas Kompliziertes entwickelt haben - wenn es um Desktop geht. Und ich glaube, das hast du nicht.

Ich denke, eine genauere Beschreibung wäre: Ich komme aus einem Hintergrund, in dem Entwickler keinen Zugriff auf alles haben, und Sie kommen aus einem Hintergrund, in dem Entwickler Zugriff auf jede Betriebssystemressource haben.

Wenn ja, hast du nicht einmal daran gedacht. Assistenten werden manchmal in kleineren Größen ausgeführt, und wenn der Assistent beendet ist, wird die App möglicherweise im Vollbildmodus angezeigt.

Ja, Assistenten laufen in kleineren Größen, ABER die meisten Assistenten (einschließlich des Visual Studio 2019 Startup "Wizard") schließen sich selbst und starten dann das eigentliche Programm. Sie "verwandeln" sich nicht in die eigentliche Anwendung.

Es ist erwähnenswert, dass einige Assistenten auch keine neuen Fenster sind, sondern nur Popups, wobei die eigentliche Anwendung im Hintergrund läuft.

Und habe ein schlechtes Starterlebnis, weil ich ein Fenster zeige, das nur eine bestimmte Größe gut aussieht - und Windows sagt nur "Oh, aber ich zeige die App wie ich will".

Sie lassen es so aussehen, als würde Windows Ihren Code die ganze Zeit einfach ignorieren, während es klar ist, wann es dies ignoriert (aus der Dokumentation von "PreferredLaunchViewSize"):

Diese Eigenschaft hat nur Auswirkungen, wenn die App auf einem Desktop-Gerät gestartet wird, das sich nicht im Tablet-Modus befindet.

Es funktioniert also nur auf dem Desktop im Nicht-Tablet-Modus. Aber ist es auf anderen Geräten sinnvoll, Größen anzufordern? Erwarten Sie, dass Ihre App auf X-Box oder Holo Lens läuft, und haben Sie für solche Geräte optimiert? Wenn nicht, sollte Sie diese Einschränkung nicht so sehr stören.

Machst du das ehrlich? Zeigen Sie mir, wie ein Code geschnippelt wurde, wo Sie dies bewusst getan haben.

Nein, bin ich nicht, ich wollte nur darauf hinweisen, dass Sie "async" für etwas verantwortlich machen, das nicht damit zusammenhängt. Wenn der Benutzer zweimal auf eine Schaltfläche klickt, wird das angeklickte Ereignis zweimal ausgelöst.

Wie geht WPF damit um? Es geht richtig damit um. Die Benutzeroberfläche blockiert nicht, aber die App blockiert bei diesem Aufruf - also würde das oben genannte in WPF nie passieren

Ich bin mir ziemlich sicher, dass Sie den UI-Thread in WPF blockieren, wenn Sie Code im UI-Thread ausführen und die Fertigstellung Zeit in Anspruch nimmt.

Hallo, ich bin der Entwicklungsleiter für das Windows SDK und die Windows-Runtime-Infrastruktur im Windows-Betriebssystemteam.

Dies ist eine großartige Diskussion mit vielen Details und Gesprächen. Jemand hat dieses Gespräch vor ein paar Tagen gebracht, und ich freue mich darauf, es durchzulesen, aber es kann noch ein paar Tage dauern, bis ich dazu komme. Ich werde das Ganze jedoch lesen und versuchen, Ihnen detailliertere Antworten zu geben oder nachzuverfolgen, so gut ich kann.

Dies ist wahrscheinlich nicht der beste Ort für allgemeine Winrt-Probleme. Sie können Probleme entweder in den Microsoft-Entwicklerforen melden oder speziell bei Problemen mit der Windows-Runtime ein Problem unter https://github.com/microsoft/xlang öffnen

Danke nochmal für die rege Diskussion. Ich werde bald wieder zu diesem Thema posten.

Ben Kuhn
Microsoft

Hallo Ben,

Hallo, ich bin der Entwicklungsleiter für das Windows SDK und die Windows-Runtime-Infrastruktur im Windows-Betriebssystemteam.

Dies ist eine großartige Diskussion mit vielen Details und Gesprächen. Jemand hat dieses Gespräch vor ein paar Tagen gebracht, und ich freue mich darauf, es durchzulesen, aber es kann noch ein paar Tage dauern, bis ich dazu komme. Ich werde das Ganze jedoch lesen und versuchen, Ihnen detailliertere Antworten zu geben oder nachzuverfolgen, so gut ich kann.

Super - freue mich auf deine Antwort(en)!

Da ich der Originalposter bin, lassen Sie es mich bitte wissen, wenn Sie Fragen haben / etwas unklar ist, und ich werde mein Bestes tun, um dies zu klären.

Dies ist wahrscheinlich nicht der beste Ort für allgemeine Winrt-Probleme. Sie können Probleme entweder in den Microsoft-Entwicklerforen melden oder speziell bei Problemen mit der Windows-Runtime ein Problem unter https://github.com/microsoft/xlang öffnen

Zugegeben, es ist nicht der beste Ort, das Problem ist, dass die Leute nicht wissen, wo sie posten sollen.

Wenn Sie sagen, wir sollten auf https://github.com/microsoft/xlang posten, werde ich von nun an definitiv dort posten.

Am besten,
John

Lassen Sie mich zunächst ein paar Dinge hervorheben, auf die ich nicht eingehen werde.

• Am Ende des Threads wird viel über Windowing, Fensterposition usw. diskutiert. Das ist für WinUI wahrscheinlich immer noch ein wenig Off-Topic, aber näher dran. Ich möchte die WinUI-Leute das Feedback zu Fensterposition, Vollbild usw. analysieren lassen und bei der Umleitung helfen. @StephenLPeters , kannst du dabei helfen?

• Ich werde VS-Feedback nicht anfassen. Es gibt ein gesundes Forum, um über VS-Qualität und -Leistung zu diskutieren. Obwohl ich die Diskussion zur Kenntnis genommen habe, ist die Geschichte zur Entwicklung von Windows-Apps aus Visual Studio etwas komplexer und verworrener geworden.

• WPF. Ich habe eine Hassliebe zu WPF. Es ist nützlich und meistens gut. Als ich den Kommentar zu verschachtelten Klicks in der Dateiauswahl las, musste ich jedoch lachen. Denn es gibt einige Macken in WPF, die mir echte Kopfschmerzen bereitet haben. Wie die Tatsache, dass beim Ziehen in WPF die Ziehnachrichten manchmal in einer verschachtelten Nachricht doppelt verteilt werden, sodass Sie tatsächlich ein modales Ziehen innerhalb eines modalen Ziehens ausführen. Normalerweise merkt man es nie. In der Regel. Aber ich mag WPF immer noch. 😉

Zweitens @verelpode : Das hat mich zum Lachen gebracht. Stört es mich, wenn ich an diesem festhalte?
"Ich glaube, dass Sie mit der direkten Wahrheit nicht umgehen können, deshalb werde ich Sie mit dicken, flauschigen Baumwollhandschuhen anfassen und Sie in Luftpolsterfolie verpacken."

Ok, nun zu echten Themen.

WinRT vs. UWP vs. .NET – einige Hintergründe

Die Windows-Runtime ist wirklich zwei Dinge in einem, verpackt in einem anderen und wirklich missverstanden.

Das Windows-Runtime-Typsystem ist in gewisser Weise COM V2. Es ist der spirituelle nächste Schritt in der Entwicklung vom Auslösen von Interrupts über das Aufrufen von Win32 bis zum Aufrufen von COM-APIs. Das Typsystem ist in COM in gewisser Weise etwas weniger ausdrucksstark, aber in den meisten Fällen eine wesentliche Obermenge. Es wurde ursprünglich entwickelt, um genau ein Problem zu lösen: Wie können wir Entwicklern, die .NET oder andere Sprachen verwenden, den Aufruf von WinRT-APIs erleichtern, ohne darauf warten zu müssen, dass VS schöne Wrapper im .NET-Framework erstellt.

Dann gibt es die API-Bibliothek. Wir haben hier tolle Sachen gemacht, aber auch dumme Sachen. Wir haben uns vielleicht ein bisschen mit einigen der asynchronen Sachen hinreißen lassen. Wenn Sie mit C++ /WinRT programmieren, können Sie dies erheblich abschwächen. Wenn Sie sich nicht im UI-Thread befinden, greifen Sie einfach auf das Ergebnis zu und es wird synchron blockiert und abgeschlossen. .NET macht dies jetzt vielleicht auch einfacher, aber ich schreibe heutzutage weniger .NET-Code und bin mir über den aktuellen Stand der Dinge weniger sicher. Wir haben auch ein paar andere Dinge gemacht, die nicht wie geplant funktioniert haben. Ich werde sie nicht alle auflisten. Wir haben jedoch einige Verbesserungen vorgenommen.

Das UWP-Anwendungsmodell sprang mit beiden Beinen in den Winrt. Das bedeutete, dass wir einmal Betriebssystem-APIs schreiben und den Zugriff von JS-basierten Apps, .NET-Apps und nativen Apps einfach machen konnten. Das allein war schon gut. Das Entfernen aller anderen Win32-APIs war nicht so gut. Wir haben noch einige Dokumentationsarbeiten zu erledigen, aber es gibt weit mehr klassische Win32-APIs, die jetzt in Store-Apps verwendet werden können. Lange Rede, kurzer Sinn, wir haben eine völlig neue App-Plattform mit einer kleinen Benutzerbasis auf neuen Geräten erstellt, Sie haben Ihren vorhandenen Code nicht mitgebracht, und es sind nicht viele Leute aufgetaucht. Wir wissen. Deshalb reparieren wir es Stück für Stück. Auch wir haben vieles richtig gemacht und arbeiten uns langsam aber stetig an einem Best-of-Beide-World-Ansatz vor. Ein deklaratives Installationssystem ist in vielerlei Hinsicht eine wunderbare Sache.

In diesem Thread wurde auch die Codeportabilität zwischen UWP-Apps und Desktop-Apps angesprochen. Da das UWP-Modell so stark divergierte, gibt es eine Reihe von Schwachstellen. Wir gehen sie so schnell wie möglich an. Manche brauchen Zeit oder erfordern „große Pausen“. Beispielsweise verwenden wir unterschiedliche Namen für die CRT-DLLs. Wir haben eine Abschwächung, das VC-Forwarder-Paket, zusammengestellt, aber die eigentliche Lösung wird darin bestehen, die Unterscheidung in einer zukünftigen Version des CRT zu entfernen, was von Natur aus eine Umbenennung der Dateien und eine wesentliche Änderung erfordert. Wir tun dies absichtlich selten, weil es störend ist.

WinRT selbst verlagert seine Tools zunehmend auf Open Source, und obwohl nicht bekannt, ist der Großteil von WinRT für Desktop-Apps verfügbar. XAML war die große Lücke. XAML Islands waren ein Schritt in die richtige Richtung, aber ich freue mich viel mehr über WinUI.

Feedback zu bestimmten APIs

Bei einigen davon bitte ich Sie, Feedback zu geben, wenn dies Ihr Problem ist. Ich helfe dabei, das Problem an das richtige Team weiterzuleiten. Verschiedene Teams in Windows sind jeweils für ihre eigenen APIs verantwortlich, und am effektivsten ist es, wenn Sie die Datei im Feedback-Hub einreichen. Dies verbindet das Feedback mit einem echten Menschen und einer Geschichte. Es ermöglicht Ihnen auch, das Feedback zu verfolgen. Sie können sich gegenseitig ein wenig helfen, indem Sie das Feedback der anderen nach Bedarf ergänzen. Versuchen Sie, eine geeignete Kategorie auszuwählen. Wenn nicht klar, können Sie "Entwickler-Feedback" -> API-Feedback verwenden

Dateisystem-APIs für moderne Apps sind schmerzhaft und unerwartet langsam

https://docs.microsoft.com/answers/questions/608/please-either-allow-systemio-all-over-hdd-or-drast.html
Wir haben dieses Feedback sowohl von Kunden als auch von unseren eigenen Teams, die Anwendungen erstellen, gehört. Ich wünschte, ich hätte mehr, was ich zu diesem Zeitpunkt teilen kann. Im Moment kann ich leider nur sagen "wir wissen".

Die BroadSystemAccess-API / -Fähigkeit ist in der implementierten Form nicht praktikabel.

https://docs.microsoft.com/answers/questions/6483/is-uwp-the-right-development-tool-for-my-project.html
Bitte senden Sie ein Feedback-Hub-Element und senden Sie mir den Link. Ich werde es persönlich bewerben und dem richtigen Besitzer übergeben. Eine Abfallrate von 80 % ist nicht gut. Ich verstehe den Punkt, dass es auch eine rote Flagge für Benutzer ist. WENN die Datei-APIs schnell genug wären, klingt es so, als würde die zukünftige Zugriffsliste zumindest einen Teil der Schmerzen lindern, aber möglicherweise nicht so "glatt" wie das, was Sie jetzt haben. Aber dann befinden Sie sich zwischen einem Felsen und einem harten Ort. Um so magisch zu sein, wie Sie es jetzt tun, müssen Sie den Benutzer alles sehen lassen. Ihre Passwort-Tabelle, ihren Mail-Ordner, ihren Browser-Cache usw. Sie mögen vertrauenswürdig sein, aber Ihre App sollte Benutzer dazu bringen, innezuhalten und darüber nachzudenken, wie sehr sie Ihnen vertrauen, bevor sie ihre Welt übergeben.

Ich verstehe, dass die Idee, die App zu schließen und neu zu starten, ein unangenehmer Schritt ist. Dies scheint die Art von Dingen zu sein, die zumindest beim ersten Start aussortiert werden sollten. Bitte reichen Sie ein separates Feedback-Element ein. Gleiches Angebot. Ich werde fördern und liefern.

In Bezug darauf, ob zukünftige Zugriffslisten auf Unterordner zugreifen können, habe ich ein Dokumentationsproblem für die Seite erstellt. https://github.com/MicrosoftDocs/windows-uwp/issues/2322. Es ist erwähnenswert, dass Sie, da sich die Dokumentseiten auf github befinden, auch Probleme in Dokumenten melden oder Änderungen am Inhalt vorschlagen können.

Das Ziehen von Dateien in Apps erlaubt keinen Schreibzugriff: Gleiches Angebot zum Feedback-Hub. Bitte Datei, und ich werde entsprechend routen.

Erstellen von Apps zum Seitenladen außerhalb des MS Store

Die Erkenntnis, die ich hier mitbekommen habe, ist, dass ein Großteil des Problems ein Dokumentproblem ist, aber es berührt einen anderen wichtigen Aspekt. Da einige unserer Tools auf Github-Projekte und Open Source verschoben wurden, ist auch die Dokumentation mitgezogen, und das macht es schwieriger, die Windows-Dokumentation als One-Stop-Shop für alles zu verwenden. Ich werde dieses Problem intern sowohl im Hinblick auf das spezifische Problem im Zusammenhang mit der .appinstaller-Datei ansprechen als auch allgemein mit unserem Content-Team darüber diskutieren, wie dieses Problem besser gelöst werden kann.

Sie haben auch ein spezielles Problem festgestellt, dass zum Debuggen über den Server geleitet werden muss. Das sollten Sie als Problem gegen das vorhandene Github-Projekt einreichen.

Neue Zertifikatsausstellung & Privater Vertrieb

Dies ist ein bisschen näher bei mir (mein größeres Team kümmert sich auch um Aspekte der Anwendungsinstallation. Ich würde mich immer noch über ein Feedback-Hub-Problem zu diesem Thema freuen, von dem aus ich arbeiten kann.

Das WinRT-Typsystem beeinflusst die Fähigkeit, großartige APIs und Bibliotheken bereitzustellen

Die Unfähigkeit, den Typnamen zu überladen, ist beabsichtigt. Solange wir nicht überdenken, wie Javascript-Anwendungen (wie wäre es mit Node / V8? Wäre das interessant?) Apps auf WinRT-APIs zugreifen, werden wir nicht bereit sein, dies noch einmal zu überdenken. Das andere Thema zu Eigenschaften und NaN ist in einem separaten Thema, das einige gute Diskussionen bietet, daher werde ich in dieser Antwort nicht darauf eingehen.

Der Feedback-Hub sollte beim Verlassen auffordern, um ein versehentliches Löschen von Inhalten zu verhindern

Ja, das gebe ich +1. Bitte archivieren. Es gibt eine Kategorie im Feedback-Hub unter Apps für… Feedback-Hub. Das ist so meta.

Asynchrone APIs sind immer noch außer Kontrolle und scheinen für Dinge, die nicht asynchron sein sollten, umständlich zu sein

Ja. Auch intern wird dies weiterhin kontrovers diskutiert. Es gibt eine feine Balance zwischen Kinderbetreuung und Förderung von gutem Benehmen, die wir noch nicht ganz erreicht haben. Bitte senden Sie weiterhin Feedback zu bestimmten APIs, die Sie gerne synchron sehen würden.

Es gibt keine guten Audio-APIs auf WinRT

Ich bin kein Audio-Experte. Fühlen Sie sich frei, im Feedback-Hub einzureichen, aber ich werde hier auch eine Rettungsleine anrufen und ein bisschen herumfragen.

Schmerzen in der Zwischenablage

Ich muss hier mit einer Mae Culpa beginnen. Unser Modell für den Zugriff auf die Zwischenablage wurde in der Win8-Ära entwickelt, als wir den Benutzer super schützen mussten. Das meiste habe ich codiert. Es gibt gute Gründe, die Zwischenablage zu schützen. Benutzer legen alle möglichen sensiblen Daten in die Zwischenablage, während eine App, die die Zwischenablage überschreiben kann, auch Schaden anrichten könnte, indem sie versucht, Schwachstellen in anderen Apps auszunutzen, die möglicherweise mehr Zugriff haben. Die Win32-Zwischenablage-APIs ermöglichen auch einige ziemlich mächtige Verhaltensweisen, die missbraucht werden könnten. Daher schränkt die Zwischenablage den Zugriff ein, es sei denn, Ihre App befindet sich im Vordergrund oder ist an einen Debugger angehängt, und schränkt das ein, was Sie in die Zwischenablage einfügen können (auf eine Weise, die Sie nie bemerken sollten, es sei denn, Sie versuchen es wirklich).

Das heißt, eine Benachrichtigung, mit der interagiert wird, scheint den Zugriff auf die Zwischenablage zu gewähren. Dies würde eine besondere Behandlung erfordern, da Windows und Vordergrund gezählt werden, denke ich, aber es scheint nicht übertrieben zu sein. Bitte unter API-Feedback einreichen und ich werde dieses Problem auch in die Fehlerdatenbank aufnehmen.

Einpacken

Ich hoffe, das ist hilfreich. Ich werde den Thread verfolgen und die oben genannten Probleme wie angegeben weiterverfolgen, wenn Sie sie eingereicht bekommen.

Aus Respekt vor dem WinUI-Team, das bereits viel in der Hand hat, lassen Sie diesen Thread bitte ausklingen und konzentrieren Sie sich nur auf die in diesem Thread angesprochenen WinUI- und Windowing-Aspekte. Da dieser so lang und mäandernd ist, kann es hilfreich sein, sie in separate, kleinere Themen aufzuteilen. Ich lasse dies für ein paar Tage offen, damit Sie alle Feedback einreichen und Kommentare mit Links einfügen können, dann schließe ich diesen Thread.

Wenn Sie mehr in die Diskussionen über das WinRT-Typsystem eintauchen möchten, ist das xlang-Projekt ein guter Ausgangspunkt. Für bestimmte Windows-API-Verhalten ist der Feedback-Hub die bessere Wahl. Es hat jetzt auch ein Kommentarsystem, also hoffentlich hilft das.

Nochmals vielen Dank für die tolle Diskussion und das ausführliche Feedback zu so vielen Themen.

Ben Kuhn
Microsoft

Ihre App würde nicht geschlossen, wenn Sie Dateiauswahl(er) präsentieren, mit denen der Benutzer auswählen kann, worauf er Ihrer App Zugriff gewähren möchte.

Ich kann nicht genug betonen, wie wichtig dies als Benutzer ist. Ich möchte keiner App Zugriff auf alles gewähren, aber wenn Sie nach einem seltsamen Ort fragen, _und das macht Sinn_, werde ich den Zugriff gewähren.

@BenJKuhn Danke für die ausführliche Antwort. Sehr sehr geschätzt!

• WPF. Ich habe eine Hassliebe zu WPF. Es ist nützlich und meistens gut. Als ich den Kommentar zu verschachtelten Klicks in der Dateiauswahl las, musste ich jedoch lachen. Denn es gibt einige Macken in WPF, die mir echte Kopfschmerzen bereitet haben. Wie die Tatsache, dass beim Ziehen in WPF die Ziehnachrichten manchmal in einer verschachtelten Nachricht doppelt verteilt werden, sodass Sie tatsächlich ein modales Ziehen innerhalb eines modalen Ziehens ausführen. Normalerweise merkt man es nie. In der Regel. Aber ich mag WPF immer noch. 😉

Ich bin völlig einverstanden. Ich bin kein Befürworter von WPF, ich bin vor langer Zeit an die Grenzen von WPF gestoßen. Aus diesem Grund bin ich zu UWP gewechselt. In Bezug auf die Stabilität scheint WPF viel stabiler zu sein.

WinRT vs. UWP vs. .NET – einige Hintergründe

Dann gibt es die API-Bibliothek. Wir haben hier tolle Sachen gemacht, aber auch dumme Sachen. Wir haben uns vielleicht ein bisschen mit einigen der asynchronen Sachen hinreißen lassen.

Können Sie laut sagen :)

Die Code-Portabilität zwischen UWP-Apps und Desktop-Apps wurde in diesem Thread ebenfalls angesprochen [...], aber die eigentliche Lösung wird darin bestehen, die Unterscheidung in einer zukünftigen Version der CRT zu entfernen, was von Natur aus eine Umbenennung der Dateien und eine große grundlegende Änderung erfordert .

Irgendeine ETA? .Net 5?

Dateisystem-APIs für moderne Apps sind schmerzhaft und unerwartet langsam

https://docs.microsoft.com/answers/questions/608/please-either-allow-systemio-all-over-hdd-or-drast.html
Wir haben dieses Feedback sowohl von Kunden als auch von unseren eigenen Teams, die Anwendungen erstellen, gehört. Ich wünschte, ich hätte mehr, was ich zu diesem Zeitpunkt teilen kann. Im Moment kann ich leider nur sagen "wir wissen".

Bisher habe ich einen Workaround - alles andere als ideal, aber im Moment geht es mir gut - https://github.com/microsoft/microsoft-ui-xaml/issues/1465#issuecomment -575987737

Die BroadSystemAccess-API / -Fähigkeit ist in der implementierten Form nicht praktikabel.

https://docs.microsoft.com/answers/questions/6483/is-uwp-the-right-development-tool-for-my-project.html
Bitte senden Sie ein Feedback-Hub-Element und senden Sie mir den Link. Ich werde es persönlich bewerben und dem richtigen Besitzer übergeben. Eine Abfallrate von 80 % ist nicht gut. ich verstehe

Werde ich machen, ich hoffe ich komme am Wochenende dazu.

der Punkt, dass es auch eine rote Flagge für Benutzer ist. WENN die Datei-APIs schnell genug wären, klingt es so, als würde die zukünftige Zugriffsliste zumindest einige der Probleme abschwächen

Ja, wenn die StorageFile/Folder-API so schnell wie System.IO (oder zumindest vergleichbar) wäre, würde sie dies abschwächen. Es ist nicht aus Mangel an Versuchen - ich habe alles getan, was in den Dokumenten beschrieben ist.

Schmerzen, aber möglicherweise nicht so "glatt" wie das, was Sie jetzt haben. Aber dann befinden Sie sich zwischen einem Felsen und einem harten Ort. Um so magisch zu sein, wie Sie es jetzt tun, müssen Sie den Benutzer alles sehen lassen. Ihre Passwort-Tabelle, ihren Mail-Ordner, ihren Browser-Cache usw. Sie mögen vertrauenswürdig sein, aber Ihre App sollte Benutzer dazu bringen, innezuhalten und darüber nachzudenken, wie sehr sie Ihnen vertrauen, bevor sie ihre Welt übergeben.

Ich verstehe das alles total. Und ich stimme dir zu. Mein Schmerzpunkt ist die aktuelle Umsetzung von all dem. Ich habe bereits den größten Teil der Benutzeroberfläche umgeschrieben, die sich damit befasst (mehrmals).

Hier meine Verbesserungsvorschläge:

• "Ordner auswählen" könnte etwas hilfreicher sein - ich könnte die Dateien angeben, die mich interessieren, und es könnte dem Benutzer die Ordner hervorheben, die sie enthalten
• Zwischenablage - Wenn der Benutzer einige Dateien / Ordner in die Zwischenablage legt und dann zu meiner App zurückkehrt, sollte ich automatisch darauf zugreifen (vielleicht können Sie eine Funktion "ClipboardFilesAndFolders" hinzufügen).
• Drag-and-Drop von Dateien/Ordnern - das sollte mir automatisch Zugriff auf diese Dateien geben (warum sollte der Benutzer sie sonst in meiner App ablegen?)

Ich verstehe, dass die Idee, die App zu schließen und neu zu starten, ein unangenehmer Schritt ist. Dies scheint die Art von Dingen zu sein, die zumindest beim ersten Start aussortiert werden sollten. Bitte reichen Sie ein separates Feedback-Element ein. Gleiches Angebot. Ich werde fördern und liefern.

Verstanden, danke - übers Wochenende.

Das Ziehen von Dateien in Apps erlaubt keinen Schreibzugriff: Gleiches Angebot zum Feedback-Hub. Bitte Datei, und ich werde entsprechend routen.

Richtig, wird reichen - die Sache mit dem Ziehen von Dateien in Apps. Ich habe es noch nicht wirklich probiert:

1. Funktioniert es mit Dateien und Ordnern?
2. bekomme ich Zugriff auf den .Path?
3. Ist es hartnäckig (ich nehme an, nicht)?
4. Muss ich mich an StorageFile/Folder festhalten oder es später aus .Path neu erstellen (vorausgesetzt, die Antwort auf 2. lautet JA)?

Erstellen von Apps zum Seitenladen außerhalb des MS Store

Die Erkenntnis, die ich hier mitbekommen habe, ist, dass ein Großteil des Problems ein Dokumentproblem ist, aber es berührt einen anderen wichtigen Aspekt. Da einige unserer Tools auf Github-Projekte und Open Source verschoben wurden, ist auch die Dokumentation mitgezogen, und das macht es schwieriger, die Windows-Dokumentation als One-Stop-Shop für alles zu verwenden. Ich werde dieses Problem intern sowohl im Hinblick auf das spezifische Problem im Zusammenhang mit der .appinstaller-Datei ansprechen als auch allgemein mit unserem Content-Team darüber diskutieren, wie dieses Problem besser gelöst werden kann.

Ja, das wäre toll!

Persönlich habe ich es für meine App herausgefunden. Es hält mich davon ab, andere fortgeschrittene Dinge zu tun, die ich gerne tun würde (wie eine Win32-App zum Starten zu haben, da ich Angst habe, wie sich die gesamte .appinstaller-Datei ändern müsste).

Für mich sollte dies jedoch ein Teil des Visual Studio-Prozesses "Veröffentlichen" sein. Sie sollten einen .appinstaller für mich erstellen (da es alles andere als trivial ist, all diese Abhängigkeitsnamen richtig zu machen, und alle Aktualisierungen der Abhängigkeiten -> hier geht es wieder). Es sollte auch eine readme.txt-Datei erstellen, in der es erklären sollte, was ich auf meinen Server hochladen muss, und mir auch sagen, dass ich den .appinstaller nicht lokal verwenden kann, er muss vom Server heruntergeladen werden (beim Testen )

Sie haben auch ein spezielles Problem festgestellt, dass zum Debuggen über den Server geleitet werden muss. Das sollten Sie als Problem gegen das vorhandene Github-Projekt einreichen.

Ich kann mich nicht erinnern, was das für ein Problem war :)

Der Feedback-Hub sollte beim Verlassen auffordern, um ein versehentliches Löschen von Inhalten zu verhindern

Ja, das gebe ich +1. Bitte archivieren. Es gibt eine Kategorie im Feedback-Hub unter Apps für… Feedback-Hub. Das ist so meta.

Rechts :)

Asynchrone APIs sind immer noch außer Kontrolle und scheinen für Dinge, die nicht asynchron sein sollten, umständlich zu sein

Ja. Auch intern wird dies weiterhin kontrovers diskutiert. Es gibt eine feine Balance zwischen Kinderbetreuung und Förderung von gutem Benehmen, die wir noch nicht ganz erreicht haben. Bitte senden Sie weiterhin Feedback zu bestimmten APIs, die Sie gerne synchron sehen würden.

Hehe, das ist eine lange Liste ;)

1. Es beginnt mit grundlegenden Eigenschaften von StorageFolder/File; StorageFile.GetFileFromPathAsync (+ ähnlich für Ordner).
2. Laden von Miniaturansichten (StorageFile.GetThumbnailAsync
3. Laden von Bitmaps. Dies ist besonders schmerzhaft, da es in andere Bibliotheken (wie win2d) übertragen wurde und ich wahnsinnige Schwellenwerte erreicht habe - wie das Laden einer einfachen Bitmap (die <20 ms dauern sollte), um etwa 5 Sekunden zu dauern. Offensichtlich gibt es hinter den Kulissen einige Sperren, aber niemand weiß was/warum/wann. Und ja, mein Laptop ist eine Rakete.

Ich habe viele andere APIs nicht im Auge behalten, eine schnelle Suche in meinem Projekt zeigt 326 Verwendungen - ich habe das stark reduziert, da viele Dinge auf meiner Seite synchron sein müssen.

Die oben genannten sind meine wichtigsten Top-Schmerzen, von der Spitze meines Kopfes. Von nun an erstelle ich ein Dokument und füge es hinzu :)

Es gibt keine guten Audio-APIs auf WinRT

Ich bin kein Audio-Experte. Fühlen Sie sich frei, im Feedback-Hub einzureichen, aber ich werde hier auch eine Rettungsleine anrufen und ein bisschen herumfragen.

Ich bin mir nicht sicher, ob/wie das jemals gelöst wird. Am einfachsten wäre es, die Anforderungen zu lockern oder so, damit naudio (https://github.com/naudio/NAudio) ordnungsgemäß auf UWP portiert werden kann. Um es klar zu sagen, es kann out of the box zu UWP kompiliert werden, aber es ist nutzlos, da die meisten nützlichen Dinge #ifdef-ed out sind.

Um es klar zu sagen, ich beschwere mich nicht über die Sound-API auf UWP - was völlig in Ordnung ist, aber ich brauche mehr. Nämlich die Fähigkeit, Schallwellen und dergleichen zu interpretieren (was das Naudio ermöglicht).

Ich habe eine Naudio-Portierung durchgeführt, bei der ich so ziemlich alle #ifdefs entfernt habe - es funktioniert, aber meine App wird es nie in den MS Store schaffen - und damit bin ich einverstanden.

Schmerzen in der Zwischenablage

[...] Eine Benachrichtigung, mit der interagiert wird, scheint jedoch den Zugriff auf die Zwischenablage zu gewähren. Dies würde eine besondere Behandlung erfordern, da Windows und Vordergrund gezählt werden, denke ich, aber es scheint nicht übertrieben zu sein. Bitte unter API-Feedback einreichen und ich werde dieses Problem auch in die Fehlerdatenbank aufnehmen.

Klingt gut, geht.

Vielen Dank!

@jtorjo Wären Sie so freundlich, auch das Problem Nr. 1893 (Vorschlag: Dateisystemzugriff: Bieten Sie eine benutzerfreundliche Möglichkeit zum Anfordern der Berechtigung zum Zugriff auf bestimmte Dateispeicherorte) in Ihre Feedback-Hub-Elemente zum Dateisystem aufzunehmen (falls Sie dies getan haben) planen Sie das nicht bereits, ich denke, Sie haben das zugrunde liegende Problem oben aufgeführt). Ich fürchte, ich habe bereits eine Reihe anderer Elemente zu archivieren. Wenn Sie also dieses Thema behandeln könnten, wenn Sie das Dateisystem in Angriff nehmen, wäre das großartig :)

Natürlich würde ich es trotzdem einreichen, wenn es für Sie unbequem wäre, es zum Feedback Hub hinzuzufügen!

@Felix-Dev Ich werde mein Bestes geben! Sie auf dem Laufenden halten!

Das Ziehen von Dateien in Apps erlaubt keinen Schreibzugriff: Gleiches Angebot zum Feedback-Hub. Bitte Datei, und ich werde entsprechend routen.

Richtig, wird reichen - die Sache mit dem Ziehen von Dateien in Apps.

Dies sollte eigentlich der Hinweis zum Öffnen aus einem Shell-Kontextmenü sein. Entschuldigung für die Verwirrung.

@BenJKuhn Angesichts der

@Felix-Dev Für spezifische Vorschläge denke ich ehrlich gesagt, dass es am besten ist, sie an den Feedback-Hub zu senden, der als "Entwicklerplattform > API-Feedback" markiert ist.

Wenn man sich das jüngste Feedback ansieht, das unter diesem Filter abgelegt wurde, scheint es, als ob nicht sehr viel spezifisches Feedback hinzugefügt wurde. Ich habe nur 30 Artikel (höchstens) gesehen, die unter diesem Filter abgelegt sind. Allerdings haben Ingenieure dort kürzlich auf Feedback reagiert.

Ich fordere die Community auf, ihr API-Feedback über den Feedback Hub wie oben gekennzeichnet zu übermitteln, und wir werden sehen, wie es als Option zum Einreichen von API-Feedback floriert, sobald die Vorschläge besser werden.

Ich denke, @BenJKuhn wird mir zustimmen.

Ich habe gerade bemerkt, dass meine Antwort ziemlich lang geworden ist, also nimm dies als Vorwarnung 😅

@duke7553 Wir haben hier eine Situation, in der die Community zwei verschiedene Plattformen für ihr UWP-Plattform-Feedback verwenden sollte. Spezifische API-Anfragen wie (bitte fügen Sie Parameter x zu Methode y hinzu, oder fügen Sie eine Methode hinzu, um z auszuführen) sollten zumindest im Feedback Hub abgelegt werden (obwohl sie wahrscheinlich auch an einer zusätzlichen Stelle veröffentlicht werden sollten). Komplexere Probleme/Vorschläge (bis hin zum Kern der UWP)-Plattform sollten jedoch auf jeden Fall an einer anderen Stelle als dem Feedback-Hub in seiner aktuellen Form veröffentlicht werden. Es ist in Ordnung, eine kurze Zusammenfassung auf dem Feedback Hub zu veröffentlichen, aber für alles andere ist Feedback Hub derzeit einfach nicht die Plattform. Lesen Sie weiter unten, um mehr darüber zu erfahren.

In seinem aktuellen Zustand wird der Feedback Hub von den vielen aktiven Mitgliedern der Entwickler-Community aufgrund ihrer Meinung, die in diesem Repo und anderen Orten wie Twitter immer wieder geäußert wird, einfach nicht positiv bewertet. Themen, die hier herausgegriffen werden, sind zum Beispiel:

• Der (wahrgenommene) Mangel an Engagement der Windows-Entwicklerteams (ich habe mir gerade auch das kürzlich eingereichte API-Feedback angesehen und viele Probleme dort werden derzeit mit 0 Kommentaren und keiner offiziellen Antwort angezeigt, insbesondere in Bezug auf Probleme 2 Monate und älter).
• Das Engagement der Community für bestimmte Themen/Vorschläge ist relativ gering (Up-Stimmen, Kommentare).
• Die allgemeine Benutzeroberfläche/UX des Feedback-Hubs macht es wirklich ziemlich schwierig, ansprechende Feedback-Diskussionen mit dem Team und der Community zu führen. Einige Leute aus dem WinUI-Team gaben an, dass sie auch hier mit der Community einverstanden sind .
• Schließlich ist es auf Github jetzt viel einfacher, unterstützende Mediendateien wie Bilder oder GIFs zu einem Vorschlag hinzuzufügen, um ihn zu visualisieren. Ich lasse dieses Bild einfach hier, das direkt aus dem Feedback-Hub stammt, wenn ich ein Problem einreiche:
  

Ich habe Feedback Hub zuvor nicht verwendet, um entwicklungsplattformspezifische Probleme zu melden, und schaue es mir jetzt an, um zu sehen, wie Probleme dort von der Community aufgenommen werden (fast kein Community-Engagement!), den Windows-Entwicklerteams und der Gesamtstruktur, muss ich sagen Dieses einzelne WinUI-Repo ist dem Feedback Hub in grundsätzlich jedem Aspekt überlegen (einfache Angebotserstellung/Community-Engagement/Verfügbarkeit von MS-Entwicklern/...).

Es ist nicht einmal in der Nähe, ehrlich.

Vor allem, wenn es um gesellschaftliches Engagement geht. Ich kann nicht genug betonen, wie außergewöhnlich der Community-Input in diesem Repo hier war und so viele Probleme / Vorschläge massiv vorangetrieben und verbessert hat. All dieser großartige Community-Input wäre weg, wenn er allein im aktuellen Feedback-Hub abgelegt würde.

Und zu den Antworten des Entwicklerteams auf meine hier erstellten UWP-App-Modellprobleme möchte ich nur Folgendes sagen: In vielen Fällen wie diesem habe ich rechtzeitig Feedback mit dem Hinweis erhalten, dass ein Workitem intern erstellt wurde. Was kann ich mehr verlangen? Vergleichen Sie dies mit der Meinung vieler Entwickler, die glauben, dass ihre Probleme nirgendwo hinführen, wenn sie im Feedback-Hub abgelegt werden. Und ich kann sehen, woher sie kommen, indem ich mir gerade den Feedback Hub anschaue.

@BenJKuhn
Die Teams bei MS müssen ihre UWP-Feedback-Plattform ernsthaft verbessern, und bis ich diese Verbesserungen gesehen habe, werde ich dieses Repo auch hier immer verwenden, solange es das WinUI-Team erlaubt. Feedback Hub hat derzeit in den Augen vieler Windows-Entwickler einen Tiefpunkt und ein Post über Nacht wird diese Situation nicht plötzlich ändern. Es ist ein Anfang, aber es ist noch viel mehr erforderlich, um die negativen Eindrücke, die viele Entwickler erhalten, wenn sie über den Feedback Hub (oder andere MS-spezifische Entwickler-Feedback-Plattformen wie die zuvor geschlossene UserVoice für UWP) sprechen, grundlegend umkehren. Angesichts der vielen enttäuschenden Erfahrungen, die viele UWP/Windows-Entwickler im Umgang mit Feedback Hub oder anderen Feedback-Plattformen in der Vergangenheit gemacht haben, bin ich in dieser Angelegenheit fest davon überzeugt, dass die Windows-Entwicklungs- und Feedback-Teams in erster Linie verstärkt werden müssen, anstatt die Entwickler zu bitten, dass sie es tun zurück (ohne große - wenn überhaupt - sichtbare Verbesserungen zu zeigen). Ich weiß, dass dies eine ziemlich harte Ansicht ist, aber wenn Sie sich die vielen Antworten von Entwicklern in diesem Repo und vielen anderen Feedback-Plattformen im Laufe der Jahre ansehen, werden Sie leicht feststellen, dass in der Entwickler-Community echte Frustration herrscht.

Ich möchte hier jedoch nicht nur hart sein, da beide Seiten einander brauchen werden, um eine lebendige und fruchtbare Feedback-Plattform zu schaffen, die sowohl für Microsoft als auch für die Entwickler-Community hohe Zufriedenheitswerte bietet. Als Kompromiss habe ich in meinem obigen Beitrag vorgeschlagen, UWP-Probleme hier in diesem Repo zu posten, wo sie aktiv mit der Community diskutiert werden können, und eine kurze Zusammenfassung mit einem Link zum im Feedback-Hub enthaltenen Github-Thread zu posten. Neben all den Vorteilen, die dies für die oben aufgeführte Community hätte, wird der hinzugefügte Link auch den Windows Dev-Teams einen Einblick in die vielen verschiedenen Ansichten dieser Community geben und sogar viele kleine Ideen erfassen, die wahrscheinlich nie eingereicht werden im Feedback Hub, aber in vielen Kommentaren hier zu finden .

Ich beende diesen Beitrag mit einem Screenshot aus der Entwicklerplattform -> API-Feedback des Feedback Hubs:

PS: Ich werde diesen Beitrag nutzen, um dem WinUI-Team noch einmal meinen aufrichtigen Dank auszusprechen, dass es zugestimmt hat, sein Repository zu öffnen, um Probleme zu hosten, die überhaupt nichts mit WinUI zu tun haben, sondern darauf abzielen, grundlegende Probleme anzugehen, die Entwickler in der UWP sehen . Danke, WinUI-Team!

@BenJKuhn

Hier sind die Feedback-Hub-Probleme, die ich erstellt habe

Die BroadSystemAccess-API / -Fähigkeit ist in der implementierten Form nicht praktikabel. https://aka.ms/AA804aq

BroadSystemAccess API / sollte die App nicht neu starten, wenn der Benutzer einen breiten Systemzugriff erlaubt https://aka.ms/AA7zpe3

Zwischenablage sollte immer funktionieren. https://aka.ms/AA804ce

Dateisystemzugriff: Bieten Sie eine benutzerfreundliche Möglichkeit, die Berechtigung zum Zugriff auf bestimmte Dateispeicherorte anzufordern https://aka.ms/AA804cp (für @Felix-Dev )

Es gibt keine guten Audio-APIs auf WinRT https://aka.ms/AA804d0

Asynchrone APIs sind immer noch außer Kontrolle und scheinen für Dinge, die nicht asynchron sein sollten, umständlich zu sein https://aka.ms/AA804d3

Andere Dinge, die ich erstellt habe

Mehr Details - sollte mehr Zeichen zulassen https://aka.ms/AA7zws5

Wählen Sie eine Kategorie - machen Sie es einfacher https://aka.ms/AA804cd

Dinge, bei denen ich mir nicht sicher bin

Drag-and-Drop von Dateien/Ordnern - ich habe es nicht persönlich getestet. Ich bin nämlich nicht neugierig auf den Drag-and-Drop-Teil, der nicht sehr schwer zu implementieren ist. Ich bin gespannt, ob es tatsächlich funktioniert, wenn der Benutzer Dateien/Ordner auf einem UWP-Steuerelement ablegt. Habe ich schreibgeschützten Zugriff (was mir ausreichen würde)? Könnte ich diese Dateien/Ordner zu FutureAccessList hinzufügen?

Ich bin gespannt, ob dies jemand erfolgreich getestet / verwendet hat, da nicht so viele Informationen online sind.

Feedback-Hub

Feedback-Hub ist keine angenehme Erfahrung. Zum einen werden die von mir hinzugefügten Probleme eine Weile nicht in "Mein Feedback" angezeigt - ich muss die App schließen und neu starten. Es erinnert sich nicht an meine letzte Auswahl. Ich kann nicht zu viel Text schreiben, keine Möglichkeit zum Ablegen einer Datei und/oder Bilder in der Zwischenablage. Ich stimme also so ziemlich mit @Felix-Dev überein - es ist wirklich schwer zu verstehen, wo Probleme gepostet werden sollen (anders als ab jetzt in xlang).

@BenJKuhn Hier ist der Feedback-Hub-Link für das spezifische Problem mit der Toast-Benachrichtigung beim Zugriff auf die Zwischenablage, wenn der Benutzer damit interagiert: https://aka.ms/AA7zx69

Danke an alle für die tolle Diskussion. Ich habe jedes der Plattformprobleme, die Sie eingereicht haben, an die entsprechenden Teams weitergeleitet. Um die Erwartungen entsprechend zu formulieren, lassen Sie mich eine Analogie aus der Jobsuche ziehen: Es ist ein bisschen so, als ob Sie im Einstellungsprozess das Screening hinter sich lassen und direkt zum Vorstellungsgespräch kommen. Von hier aus liegt jedes Problem in den Händen des richtigen Teams, um es zu untersuchen und zu priorisieren.

Ich schätze die Bemühungen, die Sie unternommen haben, um diese Probleme zu melden, und werde sie weiterhin verfolgen, während die Teams sie überprüfen. Ich hoffe, dass Sie sich weiterhin bei den auftretenden Problemen mit uns austauschen, und ich werde mein Bestes tun, um Sie bei der Verbesserung der Anwendungsentwicklererfahrung unter Windows zu unterstützen.

Vielen Dank,

Ben Kuhn

@jtorjo könnten Sie den WACK- Bericht für den von Ihnen erstellten UWP-Port von NAudio teilen?

Diese Daten würden uns helfen zu beurteilen, welche Einschränkungen wir lockern müssen, damit NAudio die Store-Zertifizierung durchsteht.

@mikebattista Ich habe den WACK angehängt. Berücksichtigen Sie bitte nur die Naudio-Probleme.

Natürlich wäre es auch cool, die Probleme von log4net zu lösen, obwohl ich annehme, dass es mir gut gehen sollte, wenn ich log4net forking und diese Anrufe entferne. Es ist jedoch seltsam, dass sie auftauchen, da ich ziemlich sicher bin, dass wir nie wirklich angerufen werden. Trotzdem...

FindFirstFileExFromApp - dies sollte (und existiert tatsächlich) - es sollte definitiv nicht markiert werden.

Sie können die EnumChildWindows/EnumWindows ignorieren - ich kann sie #ifdef herausnehmen.

Validierungsergebnis.zip

Vielen Dank! Wir werden die unterstützten API-Fehler evaluieren. Ich habe mich an das Audioteam gewandt, um ihren Beitrag zur möglichen Lockerung aller Beschränkungen hier zu erhalten.

@mikebattista super , danke! Freue mich schon sehr darauf :)

@jtorjo zum Drag-and-Drop-Szenario:

1. Funktioniert es mit Dateien und Ordnern?
   Es sollte und tut es für viele Apps und Tests, wenn Sie etwas anderes finden, dann melden Sie bitte einen Fehler dazu.
2. bekomme ich Zugriff auf den .Path?
   Vielleicht - Wenn es einen echten Dateisystempfad zum Sichern des Speicherelements gibt, dann ja. (Dinge wie die Shell-Bibliotheken haben keinen echten Dateisystempfad)
3. Ist es hartnäckig (ich nehme an, nicht)?
   Nein, die App kann sie dauerhaft machen, indem sie sie zur Liste "Zukünftiger Zugriff" hinzufügt.
4. Muss ich mich an StorageFile/Folder festhalten oder es später aus .Path neu erstellen (vorausgesetzt, die Antwort auf 2. lautet JA)?
   Sie müssen es der Liste "Zukünftiger Zugriff" oder "Zuletzt verwendet" hinzufügen, andernfalls haben Sie NUR Zugriff über diese eine Objektinstanz. Wenn Sie diese Instanz freigeben, würde der Zugriff wegfallen.

In Bezug auf das Hinzufügen von Videodateien von beliebigen Speicherorten – das System erlaubt absichtlich keinen willkürlichen Zugriff, es ist jedoch immer noch möglich, dass eine App den üblichen Fall von Dateien verarbeitet, die an anderen Speicherorten platziert sind und die Benutzer die Bibliothek nicht aktualisiert haben, um sie aufzunehmen. Der Indexer- und der Speichererkennungsdienst enthalten beide Code, um das Laufwerk regelmäßig nach Details (Dateigrößen usw.) zu durchsuchen, und sie werden zum Auffinden von Foto- und Videodateien verwendet. Eine App kann die StorageLibrary-APIs verwenden, um festzustellen, ob solche Speicherorte gefunden wurden, die sich noch nicht in der Bibliothek befinden, und den Benutzer in diesem

'FindFirstFileExFromApp - dies sollte (und existiert tatsächlich) - es sollte definitiv nicht markiert werden.'
Stimme voll und ganz zu, dass alle *FromApp-APIs für die Verwendung in App-Container-Apps konzipiert und vorgesehen sind. Wenn also die Tools einen von ihnen melden, müssen wir diesen Fehler beheben.

@smaillet-ms Vielen Dank, dass Sie hier geantwortet haben. Wird daran gearbeitet, die Geschwindigkeit der Windows.Storage-APIs zu verbessern? Wir haben sehr lange auf eine Antwort gewartet. Ich wäre bereit, eine NDA zu unterzeichnen, um die verbesserten APIs in meinem App-Szenario zu verwenden.

Ich verwende derzeit die FromApp-Implementierung von FindFirstFile, aber es ist unmöglich, Elementminiaturansichten mit einer FromApp-API abzurufen.

Diese Geheimhaltungsstufe bezüglich der Arbeit, die zur Verbesserung der Windows-Runtime geleistet wird, steht im Gegensatz zu dem, was zuvor von Microsoft-Ingenieuren in dem Thread geteilt wurde.

Relevanter ignorierter Feedback-Link: https://aka.ms/AA6dgqz

Nur um hier hinzuzufügen, dass bestimmte Details möglicherweise hinter einer NDA geschützt sind, aber wenn intern an diesem Thema gearbeitet wird, würde es viele UWP-Entwickler beruhigen, wenn MS dies öffentlich bekannt geben würde (zusammen mit einem allgemeinen Ausblick, wann wir erwarten können, dass wir ihn sehen können) /mehr hören).

Es wurde eine Menge Arbeit geleistet, um die Leistung der Speicher-APIs in mehreren Versionen des Betriebssystems zu verbessern. Die Herausforderung an dieser Stelle für Entwickler besteht hauptsächlich darin, zu wissen, welche APIs wann verwendet werden sollen.

Es gibt viele Möglichkeiten, Dinge zu tun, und viele davon sind für eine bestimmte Anwendung völlig falsch. Leider gibt es keine "einzig richtige Antwort", da dies wirklich von der Anwendung abhängt und was sie mit den Informationen aus dem Dateisystem macht. Die *FromApp-APIs bieten derzeit die größte Leistung im Vergleich zu ihren Standard-Win32-Gegenstücken. Obwohl es, wie hier erwähnt, nicht alle zusätzlichen Shell-Daten wie Thumbnails usw. enthält (die tatsächlich teuer zu erwerben sind, wenn sie nicht in einem Cache verfügbar sind). Wenn Ihre App also Dateien von Interesse basierend auf Name/Pfad oder Erweiterung finden muss, kann sie dies mithilfe der *FromApp-APIs tun. Erstellen Sie dann eine StorageFile basierend auf dem Namen, um weitere Details abzurufen. Allerdings gibt es dabei doppelten Overhead, da die Zugriffsprüfungen in diesem Fall zweimal durchgeführt werden. Wenn Sie versuchen, nur eine Datei zu finden, ist dies oft kein Problem, aber eine Redundanz in größerem Umfang kann Kosten verursachen. Wenn Sie Storage WinRT Apis mit der Windows.Storage.Search.IndexerOption .OnlyUseIndexerAndOptimizeForIndexedProperties verwenden, erhalten Sie eine WIRKLICH schnelle Aufzählung, die bei Bedarf auf ein vollständig realisiertes Speicherelement darunter zurückgreift, das einen Perf-Treffer hat, aber niedriger ist als das Erstellen eines Elements von einem Pfad, da dieser zusätzliche Zugriffsprüfungen enthalten muss. Der Nachteil ist, dass es nicht funktioniert, wenn der Benutzer den Indexer für den betreffenden Standort deaktiviert hat.

Wenn Sie eine Benutzeroberfläche wie eine App vom Typ Fotos/Medien auffüllen, sind die BulkAccess-Klassen wahrscheinlich die beste Wahl, da sie auf Nutzungsszenarien in der Benutzeroberfläche mit Virtualisierung usw. ausgerichtet sind, sodass sie der Benutzeroberfläche schnell Daten bereitstellen und mehr Daten zuführen können nach Bedarf, während der Benutzer durch den Inhalt scrollt.

Wie gesagt, viele Kompromisse. Offensichtlich haben wir noch viel Arbeit zu tun, um herauszufinden, wie wir den Prozess der Bewertung der für eine bestimmte App am besten geeigneten App dokumentieren können. Wir evaluieren auch weiterhin Orte, an denen wir die größten allgemeinen Verbesserungen erzielen können, ohne bestehende Apps zu beschädigen.

WinRT ist eine große Oberfläche und nicht im Besitz eines einzelnen Teams bei MS. Jedes Team bewertet seine Prioritäten für jede Veröffentlichung und kann seine Pläne im Voraus veröffentlichen oder nicht. Persönlich würde ich gerne sehen, dass die Dinge dahin kommen, wo wir Zero Overhead in Bezug auf Win32-APIs in oder aus dem App-Container haben. Offensichtlich sind wir jetzt noch nicht an diesem Punkt und ich kann keine Versprechungen machen, dass wir das erreichen werden, Geschäftsprioritäten und Pläne für ein so großes Projekt wie Windows mit so vielen Endbenutzern wie wir haben, ist ein komplexer Prozess, der hart/hart ist Wahlmöglichkeiten auf allen Ebenen. (Ganz zu schweigen von diversen technischen Herausforderungen, die im Weg stehen können...)

@smaillet-ms

@jtorjo zum Drag-and-Drop-Szenario:

1. Funktioniert es mit Dateien und Ordnern?
   Es sollte und tut es für viele Apps und Tests, wenn Sie etwas anderes finden, dann melden Sie bitte einen Fehler dazu.
2. bekomme ich Zugriff auf den .Path?
   Vielleicht - Wenn es einen echten Dateisystempfad zum Sichern des Speicherelements gibt, dann ja. (Dinge wie die Shell-Bibliotheken haben keinen echten Dateisystempfad)
3. Ist es hartnäckig (ich nehme an, nicht)?
   Nein, die App kann sie dauerhaft machen, indem sie sie zur Liste "Zukünftiger Zugriff" hinzufügt.
4. Muss ich mich an StorageFile/Folder festhalten oder es später aus .Path neu erstellen (vorausgesetzt, die Antwort auf 2. lautet JA)?
   Sie müssen es der Liste "Zukünftiger Zugriff" oder "Zuletzt verwendet" hinzufügen, andernfalls haben Sie NUR Zugriff über diese eine Objektinstanz. Wenn Sie diese Instanz freigeben, würde der Zugriff wegfallen.

Hört sich gut an. Werde das irgendwann in meiner App implementieren.

[...] Der Indexer- und der Storage Sense-Dienst enthalten beide Code, um das Laufwerk regelmäßig nach Details (Dateigrößen usw.) zu durchsuchen, und sie werden zum Auffinden von Foto- und Videodateien verwendet. Eine App kann die StorageLibrary-APIs verwenden, um festzustellen, ob solche Speicherorte gefunden wurden, die sich noch nicht in der Bibliothek befinden, und den Benutzer in diesem

Ich habe nichts dagegen, aber dies scheint eine zusätzliche Komplikation für meine App zu sein. Haben Sie von jemandem gehört, der dies tatsächlich verwendet?

Im Moment muss ich tausend Möglichkeiten finden, mit allen möglichen Problemen umzugehen, wenn es um StorageFolder/File geht, und dies ist nur ein zusätzlicher. Es belastet mich, den Entwickler, einfach noch einmal.

'FindFirstFileExFromApp - dies sollte (und existiert tatsächlich) - es sollte definitiv nicht markiert werden.'
Stimme voll und ganz zu, dass alle *FromApp-APIs für die Verwendung in App-Container-Apps konzipiert und vorgesehen sind. Wenn also die Tools einen von ihnen melden, müssen wir diesen Fehler beheben.

Einverstanden.

@smaillet-ms

Es wurde eine Menge Arbeit geleistet, um die Leistung der Speicher-APIs in mehreren Versionen des Betriebssystems zu verbessern. Die Herausforderung an dieser Stelle für Entwickler besteht hauptsächlich darin, zu wissen, welche APIs wann verwendet werden sollen.

Es tut mir leid zu sagen, aber das klingt nicht sehr beruhigend.

In den WPF-Tagen würde ich einfach System.IO verwenden, alle gewünschten Datei- / Ordnerabfragen auf wahnsinnig einfache Weise durchführen und mir keine Gedanken über die Geschwindigkeit machen. Ich würde nur wissen - es funktioniert. 4000 Dateien, 10000 Dateien - es funktioniert einfach.

Es gibt viele Möglichkeiten, Dinge zu tun, und viele davon sind für eine bestimmte Anwendung völlig falsch.

Das sagt ziemlich viel - die APIs sollten gar nicht erst existieren.

Leider gibt es keine "einzig richtige Antwort", da dies wirklich von der Anwendung abhängt und was sie mit den Informationen aus dem Dateisystem macht. Die *FromApp-APIs bieten derzeit die größte Leistung im Vergleich zu ihren Standard-Win32-Gegenstücken.

Das stimmt mit Sicherheit. Während ich die *FromApp-API bereits in eine benutzerfreundliche Klasse (für mein eigenes Szenario) verpackt habe, sollte MS dies auch tun - präsentieren Sie dies in einer schönen und einfach zu verwendenden API - einem einfachen C#-Wrapper, der decken sehr wahrscheinlich 98% der Anwendungsfälle ab.

Ich würde es selbst machen, aber ich habe keine Zeit. Ich kann meine einfache Klasse gerne teilen und jemand kann sie von dort aus übernehmen.

Obwohl es, wie hier erwähnt, nicht alle zusätzlichen Shell-Daten wie Thumbnails usw. enthält (die tatsächlich teuer zu erwerben sind, wenn sie nicht in einem Cache verfügbar sind).

Einverstanden - Ich mache dies bereits separat (frage nach Thumbnails in einem anderen Thread) - Eine Abfrage-API dafür würde Wunder bewirken. Grundsätzlich würde ich nach Thumbnails in großen Mengen fragen. Und ich könnte ein IAsyncEnumerable bekommen.

Auch hier kann MS eine einfache API dafür erstellen, und vorerst einfach .GetThumbnailAsync für jede Datei ausführen. Dann geben Sie uns die API, und dann können Sie später ihre Geschwindigkeit verbessern.

Wenn Ihre App also Dateien von Interesse basierend auf Name/Pfad oder Erweiterung finden muss, kann sie dies mithilfe der *FromApp-APIs tun. Erstellen Sie dann eine StorageFile basierend auf dem Namen, um weitere Details abzurufen. Allerdings gibt es dabei doppelten Overhead, da die Zugriffsprüfungen in diesem Fall zweimal durchgeführt werden.

Auf der positiven Seite sind viele Informationen bereits in der *FromApp API vorhanden - Erstellungszeit, letzte Zugriffszeit, letzte Schreibzeit, Dateigröße.

Wenn Sie versuchen, nur eine Datei zu finden, ist dies oft kein Problem, aber eine Redundanz in größerem Umfang kann Kosten verursachen. Wenn Sie Storage WinRT Apis mit der Windows.Storage.Search.IndexerOption .OnlyUseIndexerAndOptimizeForIndexedProperties verwenden, erhalten Sie eine WIRKLICH schnelle Aufzählung, die bei Bedarf auf ein vollständig realisiertes Speicherelement darunter zurückgreift, das einen Perf-Treffer hat, aber niedriger ist als das Erstellen eines Elements von einem Pfad, da dieser zusätzliche Zugriffsprüfungen enthalten muss. Der Nachteil ist, dass es nicht funktioniert, wenn der Benutzer den Indexer für den betreffenden Standort deaktiviert hat.

Dies hat mehrere Nachteile - erstens war es in meinen Tests schneller als nicht indizierte Dateien, aber nicht so schnell. Ich denke, es war 3x-5x schneller, aber das ist immer noch etwa 10x-50x langsamer als *FromApp. Das ist Wahnsinnig langsam. Darüber hinaus kann ich meinen Benutzern nicht wirklich sagen, dass sie die Option "Alle Dateien müssen zusätzlich zu den Dateieigenschaften kontextindiziert werden" aktivieren sollen, es ist einfach seine Option. Und wahrscheinlich lassen viele Benutzer das einfach unmarkiert.

Tatsächlich sollte Windows die verwendeten Dateien automatisch herausfinden und diese Ordner indizieren - es wird sehr wahrscheinlich für Mediendateien (Video/Foto/Musik) und für Dokumente eine große Rolle spielen.

Wenn Sie eine Benutzeroberfläche wie eine App vom Typ Fotos/Medien auffüllen, sind die BulkAccess-Klassen wahrscheinlich die beste Wahl, da sie auf Nutzungsszenarien in der Benutzeroberfläche mit Virtualisierung usw. ausgerichtet sind, sodass sie der Benutzeroberfläche schnell Daten bereitstellen und mehr Daten zuführen können nach Bedarf, während der Benutzer durch den Inhalt scrollt.

Ehrlich gesagt war mir nicht einmal bewusst, dass dies existiert - ich schaue es mir gerade an, während wir sprechen.
Wenn ich das jedoch richtig verstehe, ist dies nur ein bisschen syntaktischer Zucker, da es unter den gleichen Leistungsproblemen wie IStorageQuery leidet.

Und diese Leistungsprobleme sind riesig. Sie sind so groß, dass im Grunde bei etwa 1000 Dateien die erste Datei nach 9-10 Sekunden abgerufen wird. Mit anderen Worten, sobald Sie mit der Aufzählung des Ergebnisses beginnen, wird es 9-10 Sekunden lang blockiert, bevor etwas unternommen wird. Ich gehe davon aus, dass dies bei der Verwendung von FileInformationFactory der Fall wäre, nur dass die Benutzeroberfläche während dieser Zeit reagiert.

WinRT ist eine große Oberfläche und nicht im Besitz eines einzelnen Teams bei MS. Jedes Team bewertet seine Prioritäten für jede Veröffentlichung und kann seine Pläne im Voraus veröffentlichen oder nicht. Persönlich würde ich gerne sehen, dass die Dinge dahin kommen, wo wir Zero Overhead in Bezug auf Win32-APIs in oder aus dem App-Container haben.

Nun, viele von uns auch ;) Ich verstehe, dass WinRT ein großer Teil von Windows ist und dass verschiedene Teile über verschiedene Teams verstreut sind.

Es ist nicht sehr beruhigend für uns, die Vision, die MS für WinRT hat, nicht öffentlich zu sehen. Keine Zeitleiste zu haben, was/wann/wenn passiert.

Für mich ist die Geschwindigkeit beim Umgang mit Dateien/Ordnern einfach von größter Bedeutung. Wie kann jemand WinRT/UWP vertrauen, wenn etwas so Einfaches wie das Aufzählen der Dateien in einem Ordner so lange dauern kann? Und um herauszufinden, wie man das verbessern kann, kommt es darauf an, "werde ich das Glück haben, dass meine Google-Suche auf die *FromApp-API läuft"?

Ich möchte nicht undankbar rüberkommen - ich weiß es wirklich zu schätzen, dass Sie sich die Zeit genommen haben und uns das alles skizziert haben. Dankeschön!

@BenJKuhn Jemand (https://docs.microsoft.com/answers/questions/6112/updating-existing-app-with-new-certificate-uwp.html?childToView=25297#comment-25297) hat ein weiteres Ticket über die The eingereicht Ausgabe "Neues Zertifikat" hier --> https://aka.ms/AA8bw9v

Auf der wirklich schlechten Seite - ich habe versucht, darauf zuzugreifen, und es sagt mir, dass ich keinen Zugriff habe, um dieses Ticket anzuzeigen. Dies trägt nicht wirklich zur Glaubwürdigkeit von "Feedback Hub" bei.

Warum erlauben Sie Sideloading außerhalb des MS Store, machen es aber fast unmöglich, dies tatsächlich zu tun?

Eigentlich stimmt das nicht. Sie können Ihre Anwendung nicht in den MS Store hochladen und den Appinstaller als alternative Möglichkeit zur Installation der App verwenden. Dafür wurde meine App während der Zertifizierung gesperrt.
MS Store-Richtlinien:
https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies?redirectedfrom=MSDN#101 -distinct-function--value-accurate-representation

10.1.5
Ihre App darf Software nur über den Microsoft Store bewerben oder verteilen.

Nachdem ich die Appinstaller-Datei von meinem Server entfernen musste, können Benutzer den MS Store wieder verwenden, um meine App zu installieren. Ich verstehe - Regeln sind Regeln, selbst ich kann keinen Grund dafür finden. Aber es ist wirklich enttäuschend, wenn ich viele Anwendungen kenne, die über Store und Appinstaller (Unigram) oder Chocolatey (neues MS Terminal) vertrieben werden.

Warum erlauben Sie Sideloading außerhalb des MS Store, machen es aber fast unmöglich, dies tatsächlich zu tun?

Eigentlich stimmt das nicht. Sie können Ihre Anwendung nicht in den MS Store hochladen und den Appinstaller als alternative Möglichkeit zur Installation der App verwenden. Dafür wurde meine App während der Zertifizierung gesperrt.
MS Store-Richtlinien:
https://docs.microsoft.com/en-us/windows/uwp/publish/store-policies?redirectedfrom=MSDN#101 -distinct-function--value-accurate-representation

Ich bin mir nicht sicher, ob wir hier über dasselbe sprechen - in der heutigen Zeit fällt mir einfach kein einziger Grund ein, den MS Store zu brauchen oder zu wollen. Mein Problem damit war, dass es wahnsinnig schwer ist, eine App zu entwickeln und sie dann außerhalb des MS-Stores bereitzustellen.