Was ist mit einfach .ui?

Könnte diese Unterscheidung auch für Nicht-Insel-Fälle hilfreich sein, oder wäre sie verwirrender?

Oder wenn dies in erster Linie dazu dienen soll, zwischen z. B. WPF und WinUI Xaml in derselben Lösung zu unterscheiden, was ist dann mit einer Konvention wie .winui.xaml oder .island.xaml ? Das würde es wahrscheinlich einfacher machen, vorhandene Tools zu verwenden.

Wäre dies für XAML Islands-Szenarien oder überall? Für jedes andere Szenario sehe ich nicht, welchen Wert dies haben würde, außer Verwirrung zu stiften und Menschen zur Migration zu zwingen (und wahrscheinlich die Abwärtskompatibilität für viele Tools wie ältere Versionen von VS zu brechen). Eine Konvention wie "whatever.winui.xaml" wäre wahrscheinlich weniger destruktiv, aber ich sehe sie immer noch nur im Bereich einer Insel als nützlich, nicht überall sonst.

Ändern des angegebenen Titels Ich möchte die Diskussion nicht nur auf XAML-Inseln beschränken.

Ich sage, verwenden Sie weiterhin .xaml. Der Geltungsbereich (und der Name) von WinUi kann sich ändern, um neben Windows auch andere Plattformen einzubeziehen (vielleicht über UnoPlatform?). Was passiert, wenn sich der Name des Projekts ändert?

Ich tendiere eher zu NEIN. Microsoft hat zu viele Umbenennungen für Produkte und Dienste vorgenommen, manchmal zum Nachteil des Produkts/Dienstes oder seiner Benutzer (Meinung). Dies ist eine weitere Umbenennung.

Wäre dies für XAML Islands-Szenarien oder überall? Für jedes andere Szenario sehe ich nicht, welchen Wert dies haben würde, außer Verwirrung zu stiften und Menschen zur Migration zu zwingen (und wahrscheinlich die Abwärtskompatibilität für viele Tools wie ältere Versionen von VS zu brechen). Eine Konvention wie "whatever.winui.xaml" wäre wahrscheinlich weniger destruktiv, aber ich sehe sie immer noch nur im Bereich einer Insel als nützlich, nicht überall sonst.

Überall, überallhin, allerorts

Ich denke, XAML sollte .xaml bleiben, aber wenn etwas Neues auftaucht, um traditionelles XAML zu ersetzen oder neben ihm nützlich zu sein, dann könnte eine .winui- Erweiterung dafür nützlich sein. #804 :)

Diese Anfrage verwirrt mich total … Ich musste diese Ausgabe zweimal lesen, um zu verstehen, was los war … Das wird das XAML-Ökosystem WIRKLICH mehr fragmentieren, als es die verschiedenen Dialekte jemals getan haben.

Mir fehlen gerade die Worte...

@liquidboy Nun , das ist zumindest ein klares Feedback dafür, diese Änderung nicht vorzunehmen :) Danke, dass du deine Stimme geliehen hast.

Ich mag die Idee von @jesbis , vielleicht könnten wir ein *.islands.xaml hinzufügen, das hilft, den Unterschied zwischen XAML-Dateien, die in einem Islands-Kontext ausgeführt werden, leichter zu unterscheiden und nicht.

Neugierig: Wäre es besser, .islands.xaml zu haben, das nur für XAML-Dateien in einem Island gilt, oder einfach überall .winui.xaml als Gesamterweiterung zu verwenden? Ich bin mir nicht sicher, welche mir von diesen beiden Ideen besser gefällt.

Meine Stimme ist, dass ".islands.xaml" oder ähnliches das empfohlene (aber nicht streng erzwungene) Muster auf Inseln ist, und überall sonst sind .xaml-Dateien immer noch .xaml-Dateien. Auf diese Weise vermeiden wir unnötige Auswirkungen auf Menschen, die keine Inseln nutzen.

Meine größte Sorge kommt von allen Werkzeugen. Ich habe kein Problem mit der anderen Erweiterung, aber das bedeutet, dass jedes Tool, das auf die .xaml-Dateierweiterung angewiesen ist, aktualisiert werden muss (ich denke an Dinge wie R#, XamlStyler usw.). Die Tooling-Unterstützung rund um xaml fühlt sich bereits an, als würde sie Probleme haben, und dies sieht so aus, als würde es wahrscheinlich noch schlimmer werden.

Meine 0,02 $

Vielleicht sollte der Titel des Problems in etwas wie folgt geändert werden:
Sollten XAML-Dateien, die für XAML-Inseln enthalten sind, eine andere Dateierweiterung mit WinUI 3-Projekten haben?

Ich bin stark dafür, .xaml dort zu belassen. Vielleicht gehen Sie zu .ui.xaml oder .xaml.ui, aber die Technologie ist stark und hält Hilfe bereit. Auf der anderen Seite hat xaml leider ein gewisses Stigma nach WPF-Leistungsfallen, Silverlight und Windows Phone, sodass ein saubererer Dateiname helfen könnte, die Wende zu schaffen. Ich liebe XAML immer noch, aber wir brauchen nicht noch mehr Verwirrung bei Technologienamen, es sei denn, es ist klar durchdacht.

Ich denke, es ist eine gute Idee, es einfach als .ui zu haben, denn wenn winui jemals plattformübergreifend wird (wie viele Windows-Sachen), wird es besser geeignet sein.

Dies bedeutet, dass es zukunftssicher ist.

Codedateien haben die Erweiterung .ui.cs, die selbsterklärend und einfach zu lesen ist.

.winui.xaml

Das heißt also, wir haben .winui.xaml.cs-Dateien? Huch..

Verwenden Sie das JSON-Format. Es ist 2020.

JSON ist hart und nicht sehr freundlich zu handhaben.

Verwenden Sie das JSON-Format. Es ist 2020.

Das JSON-Format ist für Computer zum Lesen gedacht, nicht für Menschen. Es ist schwer zu lesen und sieht nicht schön aus.

Ich denke, das .winui wird den Anfänger zum Aufgeben bringen. Weil wir denken, wir sollten eine neue Sprache lernen. Und jetzt haben wir WinForms und WPF und UWP und SL und ASP und ASP.NET Core. Wir sollten immer mehr Zeit damit verbringen, es zu lernen, aber nicht zu erben. Ich denke nicht, dass wir immer die neue Technologie machen sollten.

Entschuldigung, ich und viele meiner Freunde lernen nicht gerne neue Dinge. Wenn wir nicht erwarten, die Minderheit zu sein, sollten wir die Technologie vererben und wiederverwenden und kompatibel machen.

Meiner Meinung nach wäre eine elegantere Lösung für "welches XAML was ist" die Abhängigkeit vom standardmäßigen xmlns-Namespace, wie von @grokys in diesem Kommentar vorgeschlagen: https://github.com/AvaloniaUI/AvaloniaVS/issues/95# AusgabeKommentar -541078633

Wir haben das nicht mit UWP gemacht, aber vielleicht können wir es für WinUI ändern.

Meiner Meinung nach wäre eine elegantere Lösung für "welches XAML was ist" die Abhängigkeit vom standardmäßigen xmlns-Namespace, wie von @grokys in diesem Kommentar vorgeschlagen: AvaloniaUI/AvaloniaVS#95 (Kommentar)

Wir haben das nicht mit UWP gemacht, aber vielleicht können wir es für WinUI ändern.

Sie könnten das Äquivalent eines Doctype wie bei HTML einführen?

Sie könnten das Äquivalent eines Doctype wie bei HTML einführen?

Vielleicht, aber wir sollten nicht müssen. Der Standard-Namespace sollte das sein, was die einzelnen Plattformen voneinander unterscheidet (sie tun es schließlich im Code-Behind).

Die Tooling-Unterstützung rund um xaml fühlt sich bereits an, als würde sie Probleme haben, und dies sieht so aus, als würde es wahrscheinlich noch schlimmer werden.

@keboo , das trifft mich sehr hart und ich dränge darauf, dass wir es beheben und richtig machen.
Die Tatsache, dass wir uns in einer Welt befinden, in der wir sie nicht voneinander unterscheiden können (für das Inselszenario), ist ein Produkt der Entwicklung der Werkzeuge im Laufe der Jahre. Alles ist völlig getrennt, und es ist fast unmöglich, Unterschiede zwischen den verschiedenen Dialekten zu erklären. Ich möchte dies ändern und beginnen, XAML-Parsing und -Kompilierung zu etwas zu machen, das problemlos von allen XAML-Dialekten gemeinsam genutzt werden kann, wobei in diesem Beispiel WinUI und WPF dieselbe grundlegende Engine verwenden. Das Tooling sollte Plug-in-fähig sein, wie vom Standard-Namespace deklariert, und kann bei Bedarf angepasst werden. Meiner Meinung nach sollten wir nicht mehr als das brauchen, damit dieses Szenario richtig funktioniert. Obwohl es ein großes Unterfangen ist, ist es meiner Meinung nach das Richtige für uns alle.

@stevenbrix Die Plattform würde derzeit verstehen, wann XAML in einer Inselsituation verwendet wird, aber was ich in der Frage zu diesem Problem gelesen habe, ist eine Möglichkeit für den Entwickler, zu sagen und zu verstehen, wie die .xaml-Datei in einer WinUI 3.0 verwendet wird Projekt.

Was XAML-Tools im Allgemeinen anbelangt, so muss die Designzeit-Erfahrung meiner Meinung nach vollständig überarbeitet werden. Expression Blend war das letzte Mal, dass sich XAML-Design und -Entwicklung als Spitzenklasse anfühlten.

Aufgrund der Natur von XAML ist es sowohl eine geschriebene Form als auch eine visuelle Form. Das visuelle XAML-Design ist in den Hintergrund getreten, um Intellisense auf eine gute Qualität zu bringen. Wenn es ein robustes, leistungsfähiges und einfach zu prototypisierendes und zu optimierendes XAML-Designerlebnis geben könnte – das könnte die Community neu beleben.

Ein Plugin-Ansatz, der nicht viel Arbeit für Steuerungs- oder Toolkit-Anbieter erfordert, während er dennoch eine gute Designzeit, Werkzeugpalette und Erfahrung mit Elementeigenschaften bietet, könnte sehr hilfreich sein. Da XAML in andere nicht-traditionelle Formfaktoren übergeht, muss der Design-Workflow berücksichtigt werden. Zwei-Fenster-Ansichten (Neo und Duo), nicht fenstergehostete XAML-Oberflächen, Shell-Integrationen, gemischte Framework-Projekte (XAML-Inseln, GDI- und WinUI-Mischungen), Hololens Spatial 3D, Rotating Surface Hubs usw.

Aber vielleicht ist deklaratives Markup nicht mehr der ideale Weg, damit umzugehen. Oder sollte es vielleicht mehr Trennung zwischen XAML-Inhalt und XAML-Styling geben? Wie bei HTML und CSS?

WinUI scheint eine gute Gelegenheit zu sein, die Dinge nicht nur so zu übernehmen, wie sie sind, sondern auch für die nächsten Jahrzehnte zu planen.

Nein. Ich sehe keinen Sinn. Es löst nichts.
Wenn überhaupt, führt dies zu Problemen mit Editoren, die die xaml-Erweiterung bereits kennen.
Ich arbeite jeden Tag mit wpf, uwp und Forms xaml und war noch nie wegen der Erweiterung verwirrt.

Ist der springende Punkt von Xaml nicht, dass es einfacher für Tools ist? Können die Tools das nicht herausfinden, ohne sich auf die alte Idee der Dateierweiterungen zu verlassen?

Ich meine im Allgemeinen, wenn sich nichts im UI-Framework ändert, dh es ist immer noch XAML, tun Sie es nicht.

Wenn es sich um ein komplett neues UI-Framework handeln würde, würde ich kein Problem sehen.

Ich weiß auch nicht, warum Sie XAML-Komponenten für Inseln entweder mit dem vorgeschlagenen islands.xaml unterscheiden möchten. Würde es bei Werkzeugen etwas anders machen oder dient es nur der Lesbarkeit in einer Lösung?

Mein erster Gedanke ist, dass mir diese Idee absolut nicht gefällt. Aber vielleicht sehe ich nicht die wirklichen Probleme, die es lösen kann, und vielleicht verstehe ich den Punkt nicht.

Wenn es eine Datei mit xaml gibt, möchte ich, dass es eine .xaml-Datei ist. In der Vergangenheit kam mir nie in den Sinn, dass ich eine UWP-.xaml-Datei haben möchte, die anders benannt werden soll als eine WPF-.xaml-Datei.

Als Nächstes scheint ein Framework-Name in einer Dateierweiterung keine gute Idee zu sein, da sich Framework-Namen ändern können und XAML immer XAML ist.

Meine Meinung ist also: Bleiben Sie auf jeden Fall bei .xaml.

Aber was sind die Optionen mit einer .xaml-Dateierweiterung?
Eine andere .islands.xaml-Dateierweiterung? Das würde bedeuten, dass die Dateiendung nicht nur zur Beschreibung des Formats, sondern auch des Inhalts einer Datei verwendet wird. Mhm ... Aber der Vorteil davon ist, dass Sie es für einen Entwickler optional machen können. Wenn sie es verwenden möchten, können sie ihre Dateien .islands.xaml nennen und die Tools werden dies mit verschiedenen Symbolen usw. aufnehmen.

Ein anderer default-namespace ist ebenfalls eine gültige Option. Aber das würde für das Tool bedeuten, dass es in jede .xaml-Datei schauen muss, um herauszufinden, um welche Art von Datei es sich handelt. Und es würde auch bedeuten, dass die XAML-Dialekte wegen eines anderen Root-Namensraums wieder etwas voneinander abweichen.

Aber jetzt ein ganz anderer Gedanke:

Wenn ich es richtig verstanden habe, sind all diese Änderungen nur für den Fall von XAML Island wirklich hilfreich, in dem Sie Plattformen in derselben Lösung mischen, richtig? Denn wenn Sie nur WinUI verwenden, wissen Sie, dass jede XAML-Datei WinUI verwendet. Ich bin mir nicht sicher, ob XAML Islands ein Hauptszenario für WinUI sein wird oder nicht. In der Vergangenheit, als WPF eingeführt wurde, hatten wir auch WPF- und WinForms-Interop, und um ehrlich zu sein, habe ich selten Entwickler gesehen, die WPF-Steuerelemente in ihren WinForms-Anwendungen verwendet haben. Stattdessen nutzten sie weiterhin WinForms in WInForms und starteten neue Projekte mit WPF anstelle von WinForms. Und vielleicht könnte das gleiche für WinUI 3 gelten, und ich denke, das wird der Fall sein. XAML Islands ist eine großartige Möglichkeit zur Modernisierung, aber meiner Erfahrung nach werden Entwickler dies nur tun, wenn sie definitiv ein Steuerelement von WinUI in ihrer WPF/WinForms-App benötigen. Wenn nicht, fahren sie auf dem alten Stack fort und starten neue Apps auf dem neuen Stack. Beachten Sie, dass dies nicht der Wahrheit entsprechen muss, es ist nur meine Erfahrung. :-)

Das bedeutet, dass wir über das Ändern eines Dateinamens für ein Szenario sprechen, das möglicherweise nicht das Hauptszenario für die Plattform ist. Und ich denke, deshalb denke ich, dass es sich nicht lohnt. Was ist, wenn ein WPF/UWP/Silverlight/Windows Phone-Entwickler ein neues WinUI 3-Projekt erstellt? Sie werden denken

Warum zum Teufel haben sie die Dateierweiterung .xaml in ... geändert?

Bitte entfernen Sie nicht die Dateierweiterung .xaml.

Bitte wechseln Sie nicht die Nebenstellen!

Vor vielen Jahren haben wir begonnen, die .paml -Erweiterung in Avalonia zu verwenden, sind aber am Ende wegen der Probleme, die sie verursacht hat, zu .xaml zurückgekehrt: Es gibt bereits Werkzeuge in IDEs, um XAML zu handhaben (egal wie ruckelig , zumindest ist es etwas!).

Wenn wir davon ausgehen, dass jeder XAML-Dialekt seine eigene Dateierweiterung hat, muss jedes Projekt, das XAML verwenden möchte, 100 % der Werkzeuge von Grund auf neu schreiben – sogar Dinge wie die Werkzeuge zum Umbenennen von Dateien werden benötigt jedes Mal neu geschrieben werden, um auch Codebehind-Klassen umzubenennen usw.

Wie @stevenbrix oben erwähnt hat, gibt es eine sehr gute Möglichkeit, festzustellen, welchen XAML-Dialekt eine Datei verwendet, nämlich den Standard-Namespace oben in der Datei. Stellen Sie als ersten Schritt sicher, dass die Werkzeuge dies berücksichtigen.

Dann öffnen Sie den XAML-Sprachdienst, stellen Sie eine API für die Interaktion mit einem Designer bereit und jeder kann davon profitieren ;)

Schön bitte ;)

Ein weiterer Grund, dies nicht zu tun: UWP hat bereits mit Adoptionsproblemen zu kämpfen. Die Umbenennung verkauft es als eine weitere Technologie, anstatt "es ist mehr oder weniger dasselbe wie wpf".
Es gibt bereits größere Probleme mit WinUI 3.0 Breaking Changes, die das bestehende UWP-Ökosystem erheblich beeinträchtigen werden. Fügen Sie nicht noch eine andere Sache hinzu, die anders ist.
Es ist immer noch xaml, trifft nur auf verschiedene API-Sets, so wie c# immer noch c# ist, selbst wenn ich es für verschiedene UI-Frameworks verwende. Code und die APIs, die ich verwenden kann, ändern sich, aber es ist immer noch dieselbe Sprache.

Ich stimme mit Nein, ich sehe keine Vorteile, nur zusätzliche Verwirrung.

Ein weiterer Grund, dies nicht zu tun: UWP hat bereits mit Adoptionsproblemen zu kämpfen. Die Umbenennung verkauft es als eine weitere Technologie, anstatt "es ist mehr oder weniger dasselbe wie wpf".
Es gibt bereits größere Probleme mit WinUI 3.0 Breaking Changes, die das bestehende UWP-Ökosystem erheblich beeinträchtigen werden. Fügen Sie nicht noch eine andere Sache hinzu, die anders ist.
Es ist immer noch xaml, trifft nur auf verschiedene API-Sets, so wie c# immer noch c# ist, selbst wenn ich es für verschiedene UI-Frameworks verwende. Code und die APIs, die ich verwenden kann, ändern sich, aber es ist immer noch dieselbe Sprache.

@dotMorten Ha, ich hatte den gleichen Gedanken mit C#. Wenn wir die .xaml Dateien .winui nennen, sollten wir die .cs Dateien .wincode nennen, um sie konsistent zu machen. :-)

Vielleicht übersehe ich immer noch etwas, aber für mich verursacht es mehr Verwirrung und ich sehe nicht die wirklichen Vorteile darin.

Meine 2 Cent, bleib bitte bei _.xaml_.
Bitte vereinen Sie die Dinge, anstatt sie zu divergieren.

Was ist, wenn Sie kleine XAML-Snippets zwischen WPF und WinUI austauschen möchten? Ich vermute, es muss einige Überschneidungen geben, oder? Es würde gemeinsame Projekte weniger nützlich machen ... oder gibt es wirklich einen großen Unterschied? Wenn es sich größtenteils um das gleiche ähnliche XAML handelt, behalten Sie die gleiche Erweiterung bei. Wenn sich das Format MEISTIG von Übergangs-XAML unterscheidet, ist es möglicherweise etwas akzeptabler, die Erweiterung zu ändern. Die eigentliche Frage ist dann, wie nah das Format am Original ist?

XAML wird auch in Xamarin verwendet, das nicht nur auf Windows, sondern auch auf iOS, Android, macOS ... abzielt.

Das Ersetzen von .xaml durch .winui führt zu einer Situation, in der Xamarin .xaml für XAML-Dateien behält (warum sollte man .winui für iOS oder Android verwenden?) und Windows-Ziele wie UWP/WPF... werden für XAML-Dateien nach .winui verschoben .

TL;DR ein Dateiformat/Konvention zwei Namen (.winui für Windows, .xaml für Xamarin), für mich ist es verwirrend.

Die Erweiterung sollte .xaml sein, da die Syntax des Inhalts xaml ist, eine andere Erweiterung würde nur Verwirrung stiften.
Ich stimme für so etwas wie .winui.xaml

Bleiben Sie bei ".xaml", es ist mächtig

Ich muss sagen, Microsoft hat ein Problem mit pathologischen Namen!

Und dieser übertrifft sie wirklich alle.

Nein

Wenn Sie UWP-XAML und WPF-XAML in derselben Projektdatei benötigen, verwenden Sie stattdessen ein neues Custom Tool .

Auf diese Weise erkennt das Tool, ob die XAML-Datei UWP-XAML oder WPF-XAML verwendet, und sendet sie über msbuild-Ziele an den richtigen Compiler.

Noch besser ist es, die XAML-Sprache zu standardisieren, damit wir einen gemeinsamen Compiler, ein gemeinsames Binärformat und eine gemeinsame Framework-Bibliothek entwickeln können.

So würde ich es machen!

Da Sie fragen, nein, tun Sie es nicht.

Wenn die Tools die Datei nicht lesen können, um den Unterschied zu sehen, sollte der SCHLECHTESTE FALL eine nicht erforderliche Konvention von „.winui.xaml“ oder ähnlichem sein. Auch hier ist der Schlüssel NICHT ERFORDERLICH. Nur XAML-Erweiterungsdateien sollten gut funktionieren, aber möglicherweise fehlen einige erweiterte Tools.

Obwohl ich die Idee dahinter verstehe, denke ich, dass es eine schlechte Lösung ist.
Erstens ist WinUI der Handelsname des Frameworks, nicht das Dateiformat. Was ist, wenn jemand entscheidet, dass Version 4 den Namen in UniversalUI oder etwas anderes ändern muss? Sie würden mit einem Framework-Namen enden, der sich von der Dateierweiterung und dem Dateiformat unterscheidet. Es könnte ein Alptraum sein.

Zweitens könnte die Kompatibilität mit bestehenden Tools und Dokumentationen beeinträchtigt werden. Zukünftige Entwickler konnten nicht klarstellen, dass WinUI-Dateien intern xaml sind, sodass sie xaml-Dokumente nicht als relevant finden würden.

Drittens würden die in Microsoft-Produkten verwendeten UI-Sprachen stärker fragmentiert. Ich denke wirklich, dass wir mehr zu einem Standard in Xaml gehen müssen, also ist das Produkt nicht so wichtig. C# ist für Xamarin, Net Core, Windows 10 oder WPF gleich, warum muss XAML anders sein?

Lassen Sie die Leute ihre Projekte anordnen und den Code so organisieren, dass er für sie nicht verwirrend ist.

Verwenden Sie das JSON-Format. Es ist 2020.

@rickydatta Auch im Jahr 2020 verwendet das Web HTML anstelle von JSON, um Benutzeroberflächen zu definieren. Es gibt viele Gründe, warum Auszeichnungssprachen wie HTML und XAML hervorragend zum Definieren von Benutzeroberflächen geeignet sind. JSON eignet sich hervorragend für verschiedene Dinge, aber imo nicht zum Definieren von Benutzeroberflächen. Wenn Sie JSON für eine Benutzeroberfläche verwenden und versuchen, Funktionen wie Datenbindung, statische Ressourcenreferenzen usw. zu erstellen, werden Sie feststellen, dass es ziemlich unlesbar wird. Aber das ist hier offtopic, also lassen wir es. Wenn Sie JSON möchten, erstellen Sie bitte ein neues Problem und lassen Sie uns sehen, wie die Community darauf reagiert. :-)

Ich habe wirklich versucht, Kommentare hier zu vermeiden, da das meiste davon bereits gesagt wurde, aber ich habe nachgegeben. Entschuldigung. Ich bin schwach.

Tu das nicht.

Wenn Sie etwas ändern möchten, müssen klare Vorteile vorhanden sein, die die Nachteile überwiegen.

Was sind die potenziellen Vorteile?

• Es würde mögliche Verwirrung für Personen vermeiden, die über einige .xaml-Dateien verfügen, die vollständig WinUI-Steuerelemente enthalten, und einige .xaml-Dateien, die dies nicht tun.
• Helfen Sie bei der Aktivierung von Tools, um zu bestimmen, wie mit den potenziell unterschiedlichen Inhalten von .xaml-Dateien gearbeitet werden soll.

Das ist es.
Ich habe diesen ganzen Thread dreimal gelesen, und ich kann keine anderen potenziellen Vorteile sehen, die hier aufgeführt sind.

Was sind die möglichen Nachteile?

• Es würde Verwirrung stiften.
  -- "Was ist diese neue Erweiterung?" "Was brauche ich, um es zu öffnen?" "Wie unterscheidet es sich von ...?" "Warum haben sie es geändert?"
  – Welche Erweiterung verwenden Sie für eine Datei, die nur einige WinUI-Steuerelemente enthält, wenn Sie vorhandene UWP-XAML- und WinUI3-Elemente mischen? Oder impliziert genau dieser Vorschlag, dass diese Fähigkeit verschwinden wird? (Schauen Sie, nur indem Sie den Vorschlag machen, eine Dateierweiterung zu ändern, führen Sie bereits zu mehr Verwirrung und FUD. Wenn sich Dinge wie Dateierweiterungen noch ändern, sollte ich vielleicht damit warten, mir WinUI in irgendeiner Form anzusehen, bis es stabiler ist . Mehrere Leute haben mir gesagt, ich solle Flutter untersuchen. Vielleicht liegt dort eine bessere Zukunft für mich.)
  -- Mein Verständnis eines der Verkaufsargumente von Xaml Islands in bestehenden WPF-Apps war, dass es die Möglichkeit bedeutete, vorhandene Fähigkeiten und Kenntnisse bei der Arbeit mit XAML wiederzuverwenden. Diese Änderung deutet darauf hin, dass es sich nicht nur um XAML handelt, sondern um eine andere Sache, die gelernt werden muss, und somit um ein weiteres potenzielles Hindernis für die Einführung.)

• Es ist unnötig.
  -- Wenn Benutzer Dateien innerhalb einer Lösung aufteilen möchten, können sie dies bereits auf mehrere Arten tun: verschiedene Projekte; verschiedene Verzeichnisse; Präfixe oder Suffixe auf Dateinamen; Verwendung mehrerer/Untererweiterungen; oder Verschachteln von Dateien im VS Solution Explorer. Es ist nicht klar, wie eine neue Erweiterung oder das Zwingen aller zur Verwendung mehrerer/Sub-Erweiterungen besser ist als jede dieser Optionen.
  -- [Default] Namespaces innerhalb der Datei teilen den Werkzeugen bereits mit, welcher Dialekt von XAML verwendet wird und was damit möglich sein sollte. (Möglicherweise gibt es in diesem Bereich ein ansonsten undokumentiertes Problem, was bedeutet, dass dies nicht möglich ist, aber wenn dies der Fall ist, sind weitere Informationen darüber erforderlich, warum das Ändern der Dateierweiterung die beste Lösung für dieses Problem ist.)

• Es ignoriert die Geschichte.
  -- Ich habe zuvor mit Lösungen gearbeitet, die Projekte enthielten, die auf WPF, Silverlight und Windows Phone abzielten. Sie verwendeten alle unterschiedliche XAML-Dialekte, aber ich war nie verwirrt darüber, welche verwendet wurden oder was ich in einer Datei tun konnte. Ich habe mit Lösungen gearbeitet, die XAML für UWP und Xamarin.Forms enthalten, aber nicht die Verwirrung erlebt, die in der Annahme hinter diesem Problem vorhergesagt wird. Ich habe auch mit vielen anderen Entwicklern mit ähnlichen Lösungen gesprochen, und ich habe noch nie jemanden sagen hören, dass die Verwendung verschiedener Erweiterungen ihnen helfen würde.
  -- Von all den Kritiken, die ich darüber gehört habe, dass es verschiedene Dialekte von XAML gibt, war die Verwirrung aufgrund der Dateibenennung nie eine davon.
  -- Entwickler mögen es im Allgemeinen nicht, wenn man ihnen ohne guten Grund vorschreibt, wie sie Dateien und Projekte benennen und strukturieren sollen. Es kann viel besser sein, Anleitungen und empfohlene/empfohlene Vorgehensweisen für Szenarien wie das Arbeiten mit Projekten zu dokumentieren, die Dateien mit ähnlichem Inhalt enthalten.
  -- Ein wichtiger Grund dafür, dass die breitere Verwendung mehrerer Erweiterungen für eine Datei nie begonnen hat, ist, dass der Datei-Explorer (oder irgendetwas, das den Inhalt des Dateisystems auflistet - einschließlich der vom Betriebssystem bereitgestellten Auswahlen und Dialoge) mehr Verwirrung stiften kann, wenn sie ( so konfiguriert sind, dass dies die Standardeinstellung ist) bekannte Dateierweiterungen verbergen. Dies kann dazu führen, dass MyClass.winui.xaml wie MyClass.winui #$ aussieht, was dann zu Fragen und Verwirrung darüber führt, was die Datei ist, woher sie stammt, warum sie angezeigt wird usw.
  -- Das Hinzufügen mehrerer/untergeordneter Erweiterungen erhöht die Dateilänge und damit die Wahrscheinlichkeit, dass Probleme mit MAXPATH auftreten. Vielleicht wird das eines Tages kein Thema mehr sein, aber so weit sind wir noch nicht. Ich würde es hassen, wenn Entwickler gezwungen wären, ihren Dateien (und Klassen, da die beiden normalerweise synchron gehalten werden) weniger aussagekräftige Namen zu geben, da die Tools jetzt sechs zusätzliche Zeichen für die Erweiterung(en) benötigten.

• Es schafft mehr Arbeit für Tooling-Entwickler. (Sowohl innerhalb als auch außerhalb von Microsoft.)
  -- Mehr Fall zu handhaben.
  -- Mehr Szenarien zum Dokumentieren und Testen.
  -- Weniger Zeitaufwand für Fehlerbehebungen und neue Funktionen. Angesichts der Tatsache, dass aktuelle XAML-Tools als hinter anderen Technologien zurückbleibend wahrgenommen werden und benutzerdefinierte Tools nur langsam erstellt werden können, warum etwas tun, das die Erstellung neuer Tools verlangsamt?

• Es besteht die Gefahr, dass ein sehr schlechter Präzedenzfall geschaffen wird.
  -- Wenn dies passiert, warum wäre es dann nicht angemessen, alle aktuellen .xaml-Dateien durch .wpf , .uwp , .xamarinforms usw. zu ersetzen? Oder .xaml2006 , .xaml20009 , .xaml-uwp5 , wenn der zugrunde liegende Namespace das Hauptproblem ist und nicht, wo sie verwendet werden? Es gäbe einen minimalen potenziellen Nutzen (wie in diesem Fall), aber viele würden es als die Art und Weise ansehen, wie Microsoft die Benennung von Dateien vorschlägt. (Ich wäre nicht überrascht, wenn jemand solche Vorschläge nicht machen würde, wenn er nur die Diskussion hier sieht.)
  - Mir sind keine von MS bereitgestellten Tools bekannt (aber gerne korrigiert), die Dateien basierend auf Untererweiterungen unterschiedlich handhaben, aber dies würde Visual Studio (und andere?, einschließlich Windows Shell?) Wahrscheinlich dazu zwingen, dies zu tun in der Lage, mit diesen Szenarien umzugehen. Dann, sobald die Fähigkeit da ist, kann ich mir vorstellen, dass die Versuchung, eine breite Palette von komplexen, aber ansonsten unnötigen Namensvorschlägen einzuführen, die vorgeschlagen und eingeführt werden, für einige Entwickler zu viel ist, was für den Rest von uns zu Verwirrung führt.

Zusammenfassend würde der Vorschlag Verwirrung und mehr Arbeit für einen theoretischen Nutzen unter begrenzten Umständen bringen. In diesem Fall würde ich die Windows-Entwicklung aufgeben.

Danke an alle, die ihre Stimme geliehen haben. Wir haben Sie gehört! Wir haben genügend Feedback gesammelt, sodass wir fest sagen können, dass das Ändern der .xaml-Erweiterung ein Non-Go ist .

Es ist nicht unsere Absicht, das Ökosystem zu fragmentieren oder Tools von Drittanbietern zu zerstören (und davon gibt es viele). Wir stimmen zu, dass XAML die Sprache ist und WinUI 3 ein UI-Framework ist, das XAML verwendet. Aus all diesen und anderen Gründen ist es sinnvoll, die xaml-Erweiterung weiterhin zu verwenden.

Unser Team muss noch einige Hausaufgaben machen und andere Alternativen evaluieren, die wir später mit der Community besprechen sollten. Zum Beispiel:

1. Nichts tun. XAML Islands-Entwicklererfahrung wird wie folgt sein: XAML-Dateien in einem anderen Projekt (vielleicht ist das keine große Sache). WInUI 3 verwendet denselben Namespace, und es spielt keine Rolle, da dies die einzige XAML-Sprache sein wird, die im Projekt verwendet wird.

2. Verwenden Sie Namespaces, um zwischen Benutzeroberflächen basierend auf XAML zu unterscheiden. Heutzutage verwenden WPF XAML und UWP XAML dieselben Namespaces, vielleicht sollte WinUI 3 einen anderen Namespace verwenden, wie es Xamarin Forms tut ("http://xamarin.com/schemas/2014/forms"), also die Compiler, Tools und Designer Dateien unterscheiden kann. Auf der anderen Seite werden dadurch Dialekte entstehen, obwohl dies heute der Fall ist. Theoretisch erleichtert dies Entwicklern das Kopieren und Einfügen von XAML-Beispielen aus Dokumenten/Blogs, obwohl es leider viele Beispiele gibt, die keine Namespaces enthalten.

3. Tun Sie etwas, aber nur für Inseln. Keine Notwendigkeit, überhaupt die UI-Frameworks zu unterscheiden. Wir können Konventionen verwenden. Beispielsweise kann eine WPF-App mit XAML Island in Zukunft XAML-Dateien in einem bestimmten Ordner (Insel-Ordner?) enthalten. Dies ähnelt der UWP-Lokalisierung (Strings/en-US/Resources.resw).

Nochmals vielen Dank für Ihr Feedback . Ich werde neue Diskussionen eröffnen, wenn wir weitere Ideen entwickeln.

Das Einfügen einer Snippit- oder Doctype-Stilzeile für eine Inseldatei sollte für die Werkzeuge ausreichen.

Ich mag die .ui.xaml -Idee, weil es ein guter Kompromiss ist. Es ist immer noch eine gültige XAML-Erweiterung und kann auch bei der Auswahl des richtigen Editors und der richtigen Symbole helfen. Es ist auch effizienter, als Dutzende/Hunderte von XAML-Dateien zu öffnen und zu analysieren, nur um einen Typ zu finden.

@marb2000 WinUI 3 ist ein UI-Framework, das XAML verwendet

Sollte sein: WinUI 3 ist ein UI-Framework, das XAML verwenden kann. Da es nicht die Verwendung von XAML erfordert und keine Abhängigkeit von der XAML-Sprache benötigt.

Wir sind uns einig, dass XAML die Sprache ist

Das ist gut, und viele Namensräume, die XAML genannt werden, müssen in WinUI umbenannt werden: alles, was nicht mit der Sprache XAML zu tun hat.

Die De-Betonung von UWP war schmerzhaft mit anzusehen. Wenn Sie jetzt auf Kanal 9 nach UWP-Inhalten suchen, erhalten Sie Xamarin-Inhalte. Es ist so ein offensichtlicher Trick. Bitte hören Sie auf zu versuchen, UWP in etwas anderes zu verwandeln! Investieren Sie erneut, verdoppeln Sie und sorgen Sie dafür, dass es funktioniert. UWP braucht keine Kurskorrektur, es braucht die Xamarin- und Office-Teams, um an Bord zu kommen. Interne Microsoft-Politik tötet UWP.

@Noemata Ist es eine offizielle Notiz?