Wahrscheinlich eine weit entfernte Sache, aber Blend muss überarbeitet werden und benötigt einen designorientierten Workflow.

Der XAML-Designer muss robust und leistungsstark sein.

Irgendeine Möglichkeit, die Schichtstruktur der Seite/des Fensters zu visualisieren, besonders wichtig bei erhöhten Steuerelementen.

Möglichkeiten zur Visualisierung von UI-Elementen außerhalb einer Seite, z. B. ein einzelnes Steuerelement/eine einzelne Vorlage.

Anpassungen der Anzeigesteuerung, die für CoreOS, "Surface Phone", Surface Hub, Xbox, HoloLens vorgenommen wurden, alles innerhalb des Designers.

Kombinierte Designer für XAML, gemischt mit WinForms, WPF, MFC und allen anderen Frameworks, mit denen WinUI Desktop funktioniert.

Gute Möglichkeiten zum Importieren und Exportieren von XAML, sodass Designer in Blend isoliert von der Haupt-App arbeiten und sie dann an die Entwicklungsteams übergeben können, um sie in die App zu integrieren.

Bessere Visualisierung und Auflistung von Systemressourcen sowie großartige Möglichkeiten zum Herausziehen dieser globalen Ressourcen, die leicht gestaltet werden können, um die Standardeinstellungen zu überschreiben, und die Designoberfläche spiegelt diese Änderungen in Echtzeit wider.

Bessere Möglichkeiten zum Testen verschiedener DPI-Skalierungen mit Apps mit WinForms, MFC usw.

Vorlagen für neue Steuerelemente, benutzerdefinierte Themenressourcenwörterbücher, Integration des Fluent-Theme-Editors, Vorlagen für unterstützte App-Kombinationen (Win32 MFC mit Xaml-Benutzeroberfläche usw.) .

Vorlagen für Shell-Integrationspunkte, wie Dateiauswahl, Taskleisten-Flyouts.

Das sind nur ein paar Gedanken...

Meine Gedanken sind wie folgt:

1. MSIX ist schön und gut, aber ich verwende immer noch das gute alte MSI, um komplexere Anwendungen zu installieren, die Funktionen erfordern, die MSIX nicht unterstützt. Ich bin auch misstrauisch, MSIX zu verwenden, da die erforderlichen Authenticode-Zertifikate teuer sind. (Ich kann meinen Code problemlos mit einem selbstsignierten Zertifikat signieren, das meiner Meinung nach genauso sicher ist wie eines, das ich bei einer Firma kaufe, aber dann lädt Windows es nicht. Windows akzeptiert jedoch gerne eine selbstsignierte MSI-Datei .) Solange ich WinUI 3 von einer MSI-basierten Anwendung aus verwenden kann, bin ich glücklich.
2. Ein besserer XAML-Designer wäre sehr wünschenswert, aber ich brauche nicht die zusätzliche Komplexität der Integration der WinUI-XAML- und WinForms/WPF-Designer in einen. Ich bin vollkommen in Ordnung mit dem Flip-Flop zwischen verschiedenen Registerkarten in VS.
3. Wie ich bereits erwähnt habe , wäre es sehr nützlich, den XBF-Compiler von den C#- und Visual Basic-Projektsystemen zu entkoppeln. (Es wäre noch besser, wenn die XBF-Compiler-Quelle oder die Dokumentation, die ausreicht, um sie neu zu erstellen, veröffentlicht würde, aber ich weiß nicht, wie wahrscheinlich dies ist.)
4. Bessere Unterstützung für C++/WinRT und MIDL 3 im C++-Projektsystem. Derzeit ist die Projektunterstützung für die Verwendung von C++/WinRT spröde und klobig. (Wenn Sie beispielsweise den Namespace in der IDL-Datei ändern – was häufig erforderlich ist, wenn der Projektname einen Punkt enthält, den Sie in Namespaces verwenden möchten, da die Vorlage diese automatisch in Unterstriche umwandelt – kann Ihr Projekt nicht kompiliert werden , und das Beheben des Problems erfordert meiner Erfahrung nach, die Dateien *.h und *.cpp beiseite zu verschieben, sie von Grund auf neu zu generieren, Code zu kopieren und dann die vcxproj-Datei zu entladen und zu bearbeiten, um die Verschachtelung zu beheben.) So sehr ich auch etwas moderneres und flexibleres als vcxproj verwenden möchte, kann ich dies aufgrund der starken Abhängigkeit des XBF-Compilers nicht tun.

Falls noch was dazu kommt, werde ich es auf jeden Fall hier posten. Vielen Dank!

1. Was ich mich hier frage, ist... Nun, muss ich das Namespace-Präfix wie < winui:Listview oder < controls:listview verwenden oder was auch immer die Entwickler entscheiden? Ich denke, es wäre viel besser, wenn möglich, die gleiche Erfahrung wie jetzt zu verwenden, nur Präfix ist in Ordnung und großartig, nur für ein paar Steuerelemente. Aber wenn Sie anfangen, überall zu verwenden, macht dies das Lesen von XAML zu einem Albtraum und sehr.
   Es macht keinen Sinn, ein Namespace-Präfix zu verwenden, da Windows.UI.Xaml.Controls nicht verwendet werden kann und WinUI die Standardauswahl ist.

2. Im Moment verwende ich nicht einmal den XAML-Designer. Ich deaktiviere buchstäblich in den Einstellungen. XAML-Designer ist träge und benötigt eine bessere Unterstützung. Es war gut für WPF, aber nicht für UWP, insbesondere wenn Sie Responsive Design machen, mit Seiten umgehen, Daten anzeigen usw.
   Dies ist wahrscheinlich ein Feedback für die ferne Zukunft, aber ich denke, es ist ein gutes Feedback, das man sich ansehen sollte. WPF-Designer ist viel schneller.
   Liegt das an der Sandbox oder was?

3. Wäre interessant ein Tool um eine Migration durchzuführen. Zumal es einige Kompatibilitätsprobleme mit aktualisierten WinUI 3.0-Steuerelementen wie ScrollViewer geben kann. Wenn es also ein Tool gibt, müsste es zumindest mögliche Warnungen zu diesen aktualisierten/umgeschriebenen Steuerelementen anzeigen.

1. Wir brauchen einen robusten Xaml-Code-Editor mit IntelliSense getrennt vom Designer.
   Die meiste Zeit schreibe ich nur Xaml-Code wie C#. Derzeit ist der Code-Editor langsam und fragil, wie in meinem vorherigen Kommentar erklärt . Die IntelliSense-Erfahrung ist auch recht einfach. Keine schnellen Dokumentationsinformationen, keine Umbenennung von Mitgliedern.
2. Die Unterstützung x:Bind für
3. Ich möchte viel mehr freie Kombinationen von Verpackungsmodellen für meine Anwendungen. Kann nicht zum Thema gehören, aber ich kann nirgendwo Feedback an das App-Modellteam finden.

TL;DR Ich möchte, dass ein App-Modell die Koexistenz beliebiger Instanzen unterstützt . Sogar dieselbe Version kann mit unterschiedlichen Daten-/Optionssätzen ausgeführt werden, wie z. B. Visual Studio-Hives. Derzeit scheint die einzige Lösung xcopy zu sein.

Kann mir jemand sagen, wie man das zusammenbricht?

Erstens verwende ich auch die App, die ich täglich entwickle (und benutze >> Debug für die meisten Tage). Die Koexistenz des Dev-Builds mit dem stabilen Build wird mir also sehr helfen. Derzeit muss ich die Versionsnummer erhöhen, eine Debug-Msix verpacken, die installierte Paketversion auf Debug aktualisieren.
Während verschiedener Debug-Phasen möchte ich unterschiedliche Fähigkeiten. Bei komplexen realen Daten möchte ich, dass die Debug-Instanz die Daten mit einer stabilen teilt. Für willkürlich gefälschte Daten möchte ich jedoch Isolation. Dies wird theoretisch durch den Zugriff auf Daten mit der Ordnerauswahl gelöst, aber es tut mir leid, dass SQLite in UWP dies nicht unterstützt, und es gibt keine andere eingebettete ACID-Engine, wie ich weiß.

Ach, und noch etwas. Ich würde es wirklich _wirklich_ schätzen, wenn etwas dagegen unternommen werden könnte, wie vcxproj die Verwendung von package.config für NuGet-Paketreferenzen erfordert. WinUI wird als NuGet-Paket verteilt, ebenso wie C++/WinRT und andere Schlüsselkomponenten. Ich mag es wirklich nicht, package.config zu verwenden. PackageReference ist viel effizienter (und führt nicht zu einem fehlerhaften Build, wenn Sie das vcxproj in ein anderes Verzeichnis verschieben). Es funktioniert tatsächlich, wenn es von einem vcxproj verwendet wird, solange das Wiederherstellungsziel zum richtigen Zeitpunkt ausgeführt wird. (Dies liegt daran, dass die vcxproj-Ziele die PackageReference-Wiederherstellungsmaschinerie für Nicht-SDK-C#-Projekte indirekt importieren.) Ich habe eine Reihe von Zielen geschrieben, die das Wiederherstellungsziel automatisch ausführen, wenn sich die PackageReference-Elemente geändert haben, da VS dies nicht tut selbst (noch). Leider weiß das NuGet-System nichts darüber und versucht daher, eine Datei package.config hinzuzufügen, wenn ich eine C++/WinRT-Dateivorlage hinzufüge. Dies verursacht alle Arten von Chaos, was dazu führt, dass eine Ausnahme ausgelöst wird und die Projektdatei beschädigt wird. Ich bin mir nicht sicher, wie ich das am besten lösen kann, aber ich würde es wirklich begrüßen, wenn es zumindest vor der Veröffentlichung von WinUI 3 untersucht werden könnte. Vielen Dank!

Es wäre schön, wenn WinUI das neue Projekt sdk - Microsoft.NET.Sdk oder MSBuild.Sdk.Extras unterstützt .
csproj-Dateien im alten Stil sind schwer zu pflegen. Und wir können nicht mehrere TargetFrameworks damit verwenden, was für die Migration zu WinUI nützlich sein könnte.

Warum keine F#-Unterstützung?

Sollte die Funktionalität von Azure DevOps und Visual Studio App Center hier erörtert werden?

Wie @vitorgrs bevorzuge ich native Steuerelemente ohne Namespace-Präfix, es fügt dem Code "Rauschen" hinzu. Und es hilft zu sehen, welche nativen Steuerelemente sind und welche von Drittanbietern.

Ein Migrationstool wäre natürlich schön. Wenn es mit den großen Drittanbietern (Telerik, DevExpress,...) funktioniert, wäre das schon eine große Sache.

Vorlagen

Besteht Interesse/Bedarf, dass die vorherigen Versionen von UWP-XAML-Vorlagen im neuen VS-Projektablauf verbleiben?

Von meiner Seite ist es nicht nötig, die Vorlagen aufzubewahren. Aber könnte es sein, dass UWP ein Control hat, das sich nicht in WinUI befindet? Wenn dies passieren könnte, könnte dies ein triftiger Grund sein, eine herkömmliche UWP-App zu erstellen und sie zu WinUI zu migrieren, wenn das erforderliche Control vorhanden ist. Dann wird die Vorlage möglicherweise benötigt.

Vielleicht ist es auch für Entwickler verwirrend, wenn Sie eine App erstellt haben und diese mit der neuesten Visual Studio-Version nicht mehr erstellen können.

Aber ich persönlich habe kein Interesse die Vorlagen zu behalten

Wie können wir Ihnen helfen, in Bezug auf Vorlagen und Komponenten in Visual Studio effizienter oder erfolgreicher zu sein?

Für mich sieht das gut aus für UWP. Jetzt möchte ich das gleiche für Win32 sehen. :)

Ist dieser Rundgang hilfreich und möchten Sie mehr davon sehen, wenn die Szenarien Gestalt annehmen?

Ja auf jeden Fall. Dieser Rundgang ist sehr hilfreich, um zu verstehen, wie die Zukunft aussehen könnte und sollte. Davon würde ich gerne mehr sehen.

Migration

Wäre es von Vorteil, wenn wir ein Migrationstool bereitstellen würden, das die Schritte 1-3 automatisiert?

Bestimmt. Vielleicht wäre eine kleine Visual Studio-Erweiterung eine großartige Option für diese Migration. Ich kann mir auch so etwas wie einen "WinUI Compatibility Analyzer" vorstellen, der ausgibt, was migriert werden kann und was nicht. Etwas Ähnliches wie der .NET-Portabilitätsanalysator.

Welche Bibliotheken verwenden Sie außerhalb des nativen Windows 10-Steuerungssatzes?

Normalerweise Telerik DataGrid und Community Toolkit

Wie können wir bei der Migration helfen, an die wir derzeit noch nicht denken?

Wenn Sie eine UWP-App in Visual Studio öffnen, die eine niedrigere Version als das von Ihnen installierte Win SDK hat, migriert Visual Studio sie für Sie. Vielleicht sollten Sie auch für die WinUI-Migration über so etwas nachdenken. Ich bin mir nicht sicher, aber es ist etwas, das man im Hinterkopf behalten sollte. Insbesondere wenn Visual Studio nicht mehr über die normalen UWP-Vorlagen verfügt, kann es für Entwickler verwirrend sein, eine Anwendung zu haben, die Sie nicht mit einer Vorlage erstellen können.

Andere

Wie bereits in anderen Kommentaren erwähnt, denke ich, dass es an der Zeit ist, zu .csproj-Dateien im SDK-Stil zu wechseln.

Winui 3.0-Vorlagen zum Windows-Vorlagenstudio hinzufügen.

WinUI in Desktop-Apps

WinUI in Desktop ermöglicht es Entwicklern, die Windows-UI-Bibliothek in einem Desktopanwendungsmodell zu verwenden. @marb2000 arbeitet in den kommenden Wochen an einem ausführlicheren Diskussionsbeitrag. Für Anregungen könnt ihr diesen Thread bis dahin gerne nutzen.

Als .net-Entwickler interessiert mich das am meisten.

Vorlagen

• Besteht Interesse/Bedarf, dass die vorherigen Versionen von UWP-XAML-Vorlagen im neuen VS-Projektablauf verbleiben?

Abhängig von der Anzahl der Vorlagen. Ist die Zahl gering (zB nur die "Blank App (Universal Windows)" pro Sprache, also 1 bei c#), ist das Rauschen gering und kann unterstützt werden. Wenn es sich jedoch um mehr als ein paar Vorlagen handelt, schließen Sie diese nicht standardmäßig ein und fügen Sie eine optionale VS-Installationskomponente hinzu, um sie hinzuzufügen.

• Wie können wir Ihnen helfen, in Bezug auf Vorlagen und Komponenten in Visual Studio effizienter oder erfolgreicher zu sein?

Behalten Sie eine echte leere Vorlage ohne Gerüste (besser für Tutorials). Werfen Sie einen Blick darauf, was asp.net core tut, es gibt viele Änderungen, die sie in ihrer neuen Projekterfahrung vorgenommen haben. Grundsätzlich wählen Sie eine generische Vorlage "App (UWP WinUI)", dann können Sie auf einem zweiten Bildschirm, der speziell auf Ihr App-Modell zugeschnitten ist, aus verschiedenen Vorlagen auswählen. Verwenden Sie diesen Schritt, um auch die Mindest- und Zielplattformversion auszuwählen (also kein zusätzlicher Schritt). Sie können beispielsweise eine Option hinzufügen, um das App-Paketierungsprojekt direkt zu erstellen.

Bieten Sie auch zwischen den Projekten eine gute Unterstützung für Komponenten in der Toolbox. Neue Controls sollen sofort nach Projekten gruppiert in der Toolbox angezeigt werden. Vielleicht Unterstützung für Designer-Symbole, um sie zu unterscheiden.

• Ist dieser Rundgang hilfreich und möchten Sie mehr davon sehen, wenn die Szenarien Gestalt annehmen?

Jawohl

Sprachunterstützung

• Wäre es von Vorteil, wenn wir ein Migrationstool bereitstellen würden, das die Schritte 1-3 automatisiert?

Eine gute Dokumentation (eine Seite mit klaren Schritten) sollte ausreichen. Wenn alles in VS erledigt werden kann, ohne das csproj von Hand zu bearbeiten, schlage ich vor, nur eine Dokumentationsseite hinzuzufügen, die die Schritte beschreibt.

Wenn Sie sich entscheiden (und ich hoffe, Sie werden es tun), auf das neue csproj-Format umzusteigen, wird sicherlich ein Migrationstool erforderlich sein, da die Migration eine Bearbeitung der csproj-Datei erfordert.

Verpackung

MSIX ist die moderne Paketierungsmethode für alle Apps. Sollten wir für WinUI in Win32 ClickOnce unterstützen? Welche anderen Verpackungsmethoden sollten wir unterstützen? Speziell für WinUI in Win32

Vergleichen Sie die Unterschiede zwischen Clickonce- und msix-Bereitstellung:

1. die App Installer-Funktion bietet nicht die gleiche Erfahrung auf älteren Windows-Versionen
2. MSIX erfordert ein gültiges signiertes Paket (intern oder öffentlich). Clickonce unterstützt selbstsignierte Pakete.
3. das Paket -

Für mich ist das nervigste Problem das 2. Wir haben normalerweise Clickonce-Apps, die intern auf Computern bereitgestellt werden, die nicht bei einer Domäne registriert sind. Für diese Art von Apps müssen wir das Paket also mit einem gültigen öffentlichen Signaturzertifikat signieren.

Es ist schwer, alle Unterschiede zwischen diesen beiden Frameworks vorwegzunehmen, da das Appx-Paketformat oft nur für Apps beworben wird, die auf den Store abzielen, und wenn wir Einschränkungen sehen, wissen wir nicht immer, ob sie auch für das Webverteilungsformat gelten.

• Designer-Erfahrung

Performances, Performances, Performances und Support für große Lösungen mit vielen Projekten.

Wird die WinUI-Version des Windows 10 SDK und des WinUI Xaml-Designers Open Source?

Können wir Anfragen für den Design-Time-Workflow und die Erfahrung posten?

Wird das SDK einem ähnlichen Release-Rhythmus folgen wie die Nuget-Releases von WinUI?

Einige zusätzliche Schmerzen:
Verbessern Sie die Debug-Erfahrung von verwaltetem und nicht verwaltetem Mischen.
Wenn eine Ausnahme in nicht verwaltetem Code auftritt, wird derzeit COMException auf der verwalteten Debug-Site angezeigt. Die Dinge können schlimmer sein, wenn die Aufrufliste mehr als einmal die verwaltete/nicht verwaltete Grenze überschreitet.
Im Vergleich zu WPF ist die verwaltete Aufrufliste immer verfügbar, und die ausgelöste Ausnahme enthält eine Zeichenfolge, die für das Debuggen hilfreich ist.
Ich weiß, dass die nicht verwaltete Welt und das COM-Modell nicht so bequem sind wie verwaltet. Aber zumindest, wenn eine Ausnahme (fehlerhaftes HResult) vom Framework ausgelöst wird, möchte ich die notwendigen Informationen, um die Codezeile aus dem Open-Source-Repository zu finden. Der Weg kann manuell sein, sollte aber deterministisch sein.

Wir setzen stark auf ClickOnce, daher wäre es schön, kurzfristig zu unterstützen. Wir wären bereit, auf MSIX zu migrieren, aber nachdem ähnliche Funktionen angeboten werden.

Was Vorlagen angeht, wäre es schön, eine zu haben, die eine Boilerplate-Benutzeroberfläche und Code für eine NavigationView und Navigation bereitstellt.

Danke

Wir setzen stark auf ClickOnce, daher wäre es schön, kurzfristig zu unterstützen. Wir wären bereit, auf MSIX zu migrieren, aber nachdem ähnliche Funktionen angeboten werden.

Was Vorlagen angeht, wäre es schön, eine zu haben, die eine Boilerplate-Benutzeroberfläche und Code für eine NavigationView und Navigation bereitstellt.

Danke

Die gebräuchlichsten "Shell"-Strukturen und -Muster der App - sollten als Vorlagen verfügbar sein, damit Entwickler schnell loslegen können. Die Erstanbieter-Apps von Microsoft sollten in diesen Layouts beispielhaft sein und als Best Practice in Bezug auf Verhalten, Konsistenz und Einhaltung der UI-Designnormen für Fluent Design und WinUI dienen.

@shaggygi @mdtauk
Für "die gängigste App-"Shell" -Struktur und -Muster" und "Was Vorlagen angeht, wäre es schön, eine zu haben, die eine Boilerplate-Benutzeroberfläche und Code für eine NavigationView und Navigation bereitstellt." es gibt das Windows Template Studio, das sowohl von Microsoft als auch von der Community gepflegt und entwickelt wird. Um seine Einleitung zu zitieren:

Windows Template Studio (WTS) ist eine Visual Studio 2017- und 2019-Erweiterung, die die Erstellung neuer Universal Windows Platform (UWP)-Apps mithilfe einer assistentenbasierten Erfahrung beschleunigt. Das resultierende UWP-Projekt ist wohlgeformter, lesbarer Code, der die neuesten Windows 10-Features enthält und gleichzeitig bewährte Muster und Best Practices implementiert.

@Felix-Dev wird es neben UWP irgendwann auch WPF-Vorlagen geben?

@shaggygi Vielleicht gibt es gute Neuigkeiten für dich! Siehe diesen Thread : Während an dieser Stelle scheinbar nichts garantiert ist, wird offenbar die Idee untersucht, Vorlagen speziell für WPF-Projekte bereitzustellen. Wie im verlinkten Thread erwähnt, gab es eine nicht öffentliche Sneak-Peek-Sitzung namens "Windows Template Studio - WPF Edition", die auf der Build 2019 gehostet wurde.

Wir verwenden C++/WinRT. Wir verwenden derzeit weder den xaml-Designer noch die Bindung. Aber wir werden Steuerelemente zur Laufzeit erstellen und sie möglicherweise über UWP xaml stylen. Wir benötigen auch Dialoge und modale untergeordnete Windows mit Xaml-Inseln, einschließlich Docking- / Floating-Fenstern usw.

Ich habe versucht, XAML für meine C++-App zu schreiben, und Junge war die Erfahrung schmerzhaft.

Ich musste viele Projekteigenschaften hinzufügen, die nicht dokumentiert sind, und einige andere Hacks, um alles korrekt zu generieren und richtig zu verpacken.

Zum Beispiel:

• Beim Erstellen eines Projekts zum Speichern meiner XAML-Seiten musste ich <_NoWinAPIFamilyApp>true</_NoWinAPIFamilyApp> und <_VC_Target_Library_Platform>Desktop</_VC_Target_Library_Platform> hinzufügen, zwei Projekteigenschaften, die völlig undokumentiert sind und nur durch Überprüfen des Quellcodes des neuen Terminals herausgefunden wurden.
• Ich hatte ein kryptisches "Konnte keine neue Ansicht erstellen, da das Hauptfenster noch nicht erstellt wurde", bis ich eine App-Klasse erstellt und verwendet habe, zu der es in VS keine Möglichkeit gibt, außer eine normale Seite zu erstellen und in die Eigenschaften der XAML-Datei in VS und ändern Sie sie in eine Anwendungsdefinition, dann passen Sie die MIDL, den Quellcode und die XAML-Datei an.
• Ich habe das NuGet-Paket Microsoft.Toolkit.Win32.UI.XamlApplication hinzugefügt, um meine Anwendungsklasse zu erstellen, und konnte es nicht laden, bis ich auch Microsoft.VCRTForwarders hinzugefügt habe.
• Die PRIs wurden nicht zu einem zusammengeführt, bis ich etwas in der .wapproj-Datei hinzugefügt habe, sodass meine XAML-Ressource nicht gefunden werden konnte.
• Der XBF funktionierte nicht, bis ich <DisableEmbeddedXbf>false</DisableEmbeddedXbf> hinzugefügt habe, was überraschenderweise eingebettetes XBF deaktiviert, anstatt es zu aktivieren. Der einzige Fehler, den ich hatte, war ein XAML-Parsing-Fehler, bei dem nichts darauf hinwies, dass die XBF-Dateien nicht funktionierten.
• maxVersionTested in meinem App-Manifest wurde völlig ignoriert, bis ich alles in Kleinbuchstaben geändert habe, obwohl die Anweisungen zur Verwendung der Camel-Case-Version lauteten :

Darüber hinaus war C++/WinRT auch eine Nervensäge:

• Jedes Mal, wenn ich einen inkrementellen Build ausführte, hatte ich [msg]redefinition [context]: MyClass für meine benutzerdefinierten Klassen, die mich am Bauen hinderten und nicht verschwanden, bis ich einen sauberen Build ausgeführt habe, der aufgrund der C++/WinRT-Header ewig dauert. Dieses Problem verschwand irgendwie auf magische Weise mittendrin.
• Wenn ich jetzt saubere Builds ausführe, erhalte ich eine Fehlermeldung über fehlende Header. Wenn Sie den Build-Button ein zweites Mal drücken, funktioniert es wieder.
• Ich musste meine eigene AppT<> Klasse schreiben, weil ich einen schlechten Codegen von C++/WinRT hatte. Das Beispiel für die Terminal-App und die XAML-Inseln tun dasselbe, als ob die Benutzer dies tun müssten, anstatt das Root-Problem zu beheben.
• Änderungen in den MIDL-Dateien führen zu Build-Fehlern, bis ich einen sauberen Build durchführe.

Selbst dann funktioniert es nicht ausgepackt, selbst wenn ich activatableClass Sachen zu meinem App-Manifest hinzufüge (etwas über das Nicht-finden der XAML-Ressource, wie wenn ich die PRIs nicht zusammengeführt hatte), was wichtig ist für meine App zu unterstützen.

Migration

Die Automatisierung für Schritt 1-3 ist auf jeden Fall hilfreich, zumal das Umbenennen von Namespaces in Hunderten von Dateien sehr zeitaufwendig und fehleranfällig ist. Darüber hinaus wäre ein Compat-Analyzer schön, genau wie das .net-Framework > .net-Kern, der einen Bericht darüber erstellt, wie kompatibel die aktuelle Codebasis ist und alle möglichen Änderungen notiert.

Werkzeuge

Wie andere bereits gesagt haben, wäre ein funktionsreicherer Editor schön. Die meiste Zeit hier bei der Arbeit wird XAML von Hand erstellt und verwendet meist den Designer als grobe Orientierungshilfe für das Aussehen der App. Intellisense und intelligente Refactorings wären wirklich hilfreich, QoL-Dinge wie CTRL + R + R zum Umbenennen von Dingen (zB Abhängigkeitseigenschaften oder sogar das Tag) zum Beispiel besonders wenn Sie dazu neigen, viele benutzerdefinierte UserControls und auch GoTo-Implementierung und Referenzen. Die Unterstützung des Roslyn-Analysators wäre auch wirklich gut.

Zur Erweiterung der Namensraumverbesserungen. Es wäre schön, wenn es irgendwie möglich wäre, benutzerdefinierte Steuerelemente ohne Präfix einfacher zu machen, ohne dem Standard-Namespace ein neues XmlnsDefinition s hinzuzufügen wie Klassen funktionieren würde dies auch gut zur GoTo-Implementierung passen. Normalerweise würde der Name des Steuerelements und möglicherweise der Mauszeiger darüber ausreichen, um den vollständigen Namespace anzuzeigen, um zu wissen, woher es kommt.

Vor allem bei den Tools wäre es schön, wenn er sich wie der C#-Editor verhält, um Refactorings weniger fragil oder mühsam zu machen und das Navigieren im Markup zu erleichtern. Abgesehen davon, was die XAML-Sprache selbst betrifft, wäre eine Verringerung der Ausführlichkeit auch ein schönes Beispiel für das Styling wie in #62 und #279 besprochen.

Zur Erweiterung der Namensraumverbesserungen. Es wäre schön, wenn es irgendwie möglich wäre, benutzerdefinierte Steuerelemente ohne Präfix einfacher zu machen, ohne dem Standard-Namespace ein neues XmlnsDefinition s hinzuzufügen wie Klassen funktionieren würde dies auch gut zur GoTo-Implementierung passen. Normalerweise würde der Name des Steuerelements und möglicherweise der Mauszeiger darüber ausreichen, um den vollständigen Namespace anzuzeigen, um zu wissen, woher es kommt.

Ich würde gerne denken, dass die WinUI 3.0-Version des Page-Steuerelements die Verwendung eines Präfixes für diese Steuerelemente überflüssig machen würde. Ich denke, das wäre eine Sache auf SDK-Ebene.

Ist es möglich, die Namespaces bei der Verwendung von WinUI nicht zu ändern?

Ein Fix sollte sein, dass Sie Windows.UI.Xaml.* WinMD-Referenzen vom Build ausschließen können. Jetzt verweisen die Build-Ziele nur auf das Unified WinMD aka. Windows.winmd , fügen Sie eine Option in den Zielen hinzu, um auch auf einzelne WinMDs zu verweisen. Auf diese Weise können wir die Referenzen basierend auf der von uns erstellten App ein- oder ausschließen.

Ist dies der Fall, müssen Namespaces nicht geändert werden, da es sich wie ein .NET dll verhält, das mit Assembly-Umleitungen zu einer lokalen Version innerhalb des Pakets anstelle der vom System bereitgestellten arbeiten kann.

Ich weiß, dass diese Methode speziell für .NET Framework gedacht ist, aber für UAP sollte es eine Lösung für diese Art von Szenarien geben. Ich weiß, dass es FrameworkDependency auf dem msix/appx Manifest gibt. Vielleicht können wir damit die neue WinUI mit Windows.* Namensräumen statt Microsoft.* -Namensräumen versorgen.

Auf der Entwicklerseite hätten wir weniger Mühe, unsere Apps zu aktualisieren, da wir nur die Referenz und nicht den Code ändern!

Ich würde es vorziehen, den Namensraum überhaupt nicht zu ändern!

Leistungen:

1. Sie müssen den Code nicht hin und her ändern.

2. Sobald der lokale WinUI-Code stabilisiert wurde, können Sie wieder mit der Windows-Plattform zusammenführen, sodass System-Apps und LOB-Apps die neuen Verbesserungen bei jeder neuen Windows-Version nutzen können.

3. Einerseits ist es ein hochstabiles Systemframework mit hoher Kompatibilität wie .NET Framework. Auf der anderen Seite ist es wie bei .NET Core, mit schnelleren Änderungen, mit allen Vorteilen von beiden und ohne die Probleme.

Ich würde nicht denken, dass es notwendig ist, ein Portierungstool bereitzustellen. Es ist eine einmalige Änderung, die mit Find&Replace relativ einfach ist, und die Anzahl der Instanzen wird ziemlich gering sein.

Außerdem sind weitere Probleme aufgetreten:

• Nachdem ich der Klasse App Ressourcen hinzugefügt hatte, konnte mein XAML sie nicht finden, bis ich dies hinzugefügt habe, das wiederum in der Terminal-App gefunden wurde und nicht viel Ahnung davon hatte, was es wirklich tut:
  xml <Target Name="PlaceAppXbfAtRootOfResourceTree" DependsOnTargets="GetPackagingOutputs"> <ItemGroup> <_RelocatedAppXamlData Include="@(PackagingOutputs)" Condition="'%(Filename)' == 'App' and ('%(Extension)' == '.xaml' or '%(Extension)' == '.xbf')" /> <PackagingOutputs Remove="@(_RelocatedAppXamlData)" /> <PackagingOutputs Include="@(_RelocatedAppXamlData)"> <TargetPath>%(Filename)%(Extension)</TargetPath> </PackagingOutputs> </ItemGroup> </Target>
• Der Build bricht nach dem Zufallsprinzip mit einem Fehler ähnlich wie cannot find type Microsoft.Toolkit.Win32.UI.XamlHost.XamlApplication und die einzige Möglichkeit, das Projektgebäude wieder zu erhalten, besteht darin, einen sauberen Build durchzuführen
• Ich kann die App nicht ausführen, indem ich das vcxproj für die Haupt-exe direkt als Startprojekt festlege, ich muss die entpackte appx-Ausgabe manuell in bin\x64\Debug\AppX starten und dann einen Debugger aus VS injizieren oder das App-Paket festlegen als Startvorgang.

Verwandte Themen auf Windows Desktop: .NET Community Standup - 25. Juli 2019 bei Interesse.

LANGE WinForms, WPF-Entwickler hier mit UWP-Erfahrung. Hier meine 2 Cent:

Migration

• Ein Tool zum Migrieren vorhandener UWP-Apps zu WinUI ist ein Muss.
• Ein Tool zum Konvertieren von WinForms- oder WPF-Steuerelementen in WinUI-Steuerelemente in einer vorhandenen App wäre mehr als großartig. Mit Konvertieren der Steuerelemente meine ich, die Verweise im Container auf die einzelnen Steuerelemente zu ändern.
• Ein Tool zum Migrieren von Xamarin Forms zu WinUI, um das Zurückportieren einer mobilen App zu Windows zu ermöglichen.

Werkzeuge

• Der aktuelle XAML-Editor ist schrecklich! Es muss den normalen Texteditor-Canvas verwenden und Roslyn-Features bereitstellen, die auf das XAML-Objektmodell angewendet werden, um eine bessere Intellisense und Refactorings zu ermöglichen.
• Bis Visual Studio 64-Bit ist, muss der XAML-Editor im Hintergrund eine eigenständige 64-Bit-App sein. Ich muss VS 2017 und VS 2019 ständig neu starten, um Fehler wegen unzureichenden Speichers zu vermeiden, wenn ich mit viel XAML arbeite.

Vorlagen

• Wir brauchen diese Projektvorlagen

  • NavigationView WinUI
  • NavigationView WPF
  • Menüband WinUI
  • Farbband WPF
  • Menüband WinForms

• Wir brauchen diese Seiten-/Fenstervorlagen

  • Medien-Controller-Seite
  • Browserseite
  • Dialogfenster
  • Randloses Fenster
  • Schwebendes Fenster

• Wir brauchen Kontrollvorlagen

  • Gekapselte Datenrasteransicht
  • Gekapselte untergeordnete Datenansicht

Diese letzten beiden würden zusammenarbeiten, um einfache Master-Detail-Fenster zu erstellen.

Alle diese Vorlagen und Seiten usw. werden bereits im Windows Template Studio-Projekt erstellt. Warum nicht dem gleichen Weg folgen, anstatt alles neu zu erstellen?

Projektdatei im SDK-Stil
Einer der wichtigsten Punkte, die ich gerne sehen würde – wie viele andere auch erwähnt haben – ist die Unterstützung des neuen Projektdateiformats SDK Style für UWP- und "Desktop-XAML"-Apps.

Migration zwischen UWP- und Desktop-XAML-App-Modellen
Wenn wir mit dem Erstellen einer "Desktop-XAML"-App beginnen, wie weit wird sie von einer UWP-App entfernt sein? Wird es später trivial sein, daraus eine UWP-App zu machen, wenn wir erkennen, dass wir innerhalb der Einschränkungen der UWP-Sandbox geblieben sind? Oder wenn wir mit dem Erstellen einer UWP-App beginnen und feststellen, dass wir mehr brauchen, wird es dann einfach sein, sie in eine "Desktop-XAML"-App umzuwandeln?

Ich bin vom Template Studio-Support.

Ich bin vom Template Studio-Support.

Unterstützt Template Studio XAML C++-Projekte?

Was Template Studio tut, sollte Teil des WinUI SDK IMO . sein

Was Template Studio tut, sollte Teil des WinUI SDK IMO . sein

Sollte ein Teil von Visual Studio IDE IMO sein! 😎

Leute, der Punkt ist, dass Windows Template Studio alles in einem macht für die Erstellung von UWP-Projekten. Wenn also etwas wie die Unterstützung von xaml c++ fehlt, sollten wir in Betracht ziehen, dies zu Windows Template Studio hinzuzufügen. Ich denke, es wird schneller und mehr effizient, wenn alle neuen Innovationen in uwp-Projekten in einem Projekt verbleiben.

Lassen Sie es eine Methode geben, die untere Schicht des Stapels von WinUI 3 direkt ohne XAML oder sogar MVVM zu verwenden. Dies ist besonders nützlich für bestehende Big-Iron-C++-Software, die bereits eine Art MV-was auch immer-Architektur in ihrer Codebasis haben. Sie wollen einfach etwas Besseres als HWND + GDI.

Und lassen Sie die Leute denken, dass WinUI 3 kein Spielzeug ist, sondern ernsthafte Software unterstützen kann .

@be5invis Ich stimme voll und ganz zu. Die einzige Lösung ist derzeit XamlDirect, die jedoch eher auf Middleware-Entwickler ausgerichtet ist.

Sie können mit Xaml Islands bereits Inhalte manuell erstellen. Bringen Sie einfach eine DesktopWindowXamlSource zum Laufen und hängen Sie sie an ein Fenster an, dann erstellen und ordnen/layouten Sie Steuerelemente im Code.

https://gist.github.com/sylveon/5bc68b2801333b24f7b3165c3f098cc9#file -picker-cpp-L46

@MarkIngramUK Sie benötigen möglicherweise etwas „Vollständiges“, wie das Ersetzen von CreateWindow durch WinUI-Funktionen.

Aus Designgründen möchte ich wirklich, dass die zukünftigen WinUI-WPF-Vorlagen das Erweitern des Inhalts einer Seite in die Titelleiste wie bei aktuellen UWP-Apps unterstützen. Im Moment hosten wir mit der vorhandenen XAML-Inseln-Lösung lediglich Steuerelemente in einem WPF/WinForms-Fenster und nicht in einer modernen Ansicht.

@LucasHaines Die Liste der Sprachen, die wir mit WinUI 3.0 unterstützen möchten: C#, C++/WinRT, Visual Basic. Wir untersuchen die Unterstützung von F#.

Dies zeigt, dass Sie es falsch machen, nicht nur für F#, sondern für alle .Net-Sprachen. Sie beginnen damit, über Vorlagen und .xaml-Dateien nachzudenken, was so ist, als würden Sie ein Haus bauen und Teppiche und Vorhänge anbringen, ohne die Struktur fertig gestellt zu haben.

Sie sollten WinUI in jedem .Net Standard 2.0/.Net Core 3.0/.Net 5-Projekt als Nuget-Paket installieren können. Dann haben Sie Zugriff auf alle darin definierten Klassen. Sie können dann von einem WinUI-Projekt (das nur C# sein könnte) auf solche Projekte verweisen. Dadurch können WinUI-Ansichten in jeder .Net-Sprache erstellt werden. Sehen Sie sich an, wie Xamarin.Forms dies macht .

Die Klassen sind bereits für die Verwendung in F# verfügbar (da es sich um Windows-Runtime-Komponenten handelt, die von allen .NET-Sprachen verwendet werden können)

Sie können ein Layout manuell erstellen. Sie können dies sogar über Python mit Py/WinRT für alle WinUI-Belange tun.

@sylveon Welche Klassen speziell? Ich hätte Interesse...

Alle von ihnen. Die öffentliche API von WinUI besteht nur aus Windows-Runtime-Komponenten.

@LucasHaines Die Liste der Sprachen, die wir mit WinUI 3.0 unterstützen möchten: C#, C++/WinRT, Visual Basic. Wir untersuchen die Unterstützung von F#.

Dies zeigt, dass Sie es falsch machen, nicht nur für F#, sondern für alle .Net-Sprachen. Sie beginnen damit, über Vorlagen und .xaml-Dateien nachzudenken, was so ist, als würden Sie ein Haus bauen und Teppiche und Vorhänge anbringen, ohne die Struktur fertig gestellt zu haben.

Sie sollten WinUI in jedem .Net Standard 2.0/.Net Core 3.0/.Net 5-Projekt als Nuget-Paket installieren können. Dann haben Sie Zugriff auf alle darin definierten Klassen. Sie können dann von einem WinUI-Projekt (das nur C# sein könnte) auf solche Projekte verweisen. Dadurch können WinUI-Ansichten in jeder .Net-Sprache erstellt werden. Sehen Sie sich an, wie Xamarin.Forms dies macht .

In diesem Thema/dieser Frage geht es um Werkzeuge. Ja, auf die Bibliotheken kann direkt von jeder Sprache aus verwiesen werden, die sie verwenden kann, aber die Definitionen zwischen Tools und Sprachunterstützung verschwimmen.
Nehmen wir Xamarin.Forms als Beispiel. Das bietet nur Tools für C# und in geringerem Maße für F#. Es ist möglich, Apps mit VB.Net und Xamarin.Forms zu erstellen, aber es wird nicht _offiziell unterstützt_, da es dafür keine Tools und nur eine begrenzte Dokumentation gibt.

Da WinUI Windows-spezifisch ist, kann es nicht in jedem .Net Standard 2.0/.Net Core 3.0/.Net 5-Projekt referenziert werden.
Für einige Szenarien besteht auch Bedarf an Unterstützung auf Projekt-/Compiler-/Packaging-Ebene.

Tolles Arbeitsteam bei der Version 2.2 . Gibt es eine Chance, dass wir ein kurzes Update zum v3.0-Status erhalten?

Ich sehe dies mehrmals erwähnt, aber keine klare Richtung in die eine oder andere Richtung. Da WinUI 3.0 jetzt alle Steuerelemente enthält, MUSS die Namespace-Anforderung zum Verweisen auf WinUI-Bibliothekssteuerelemente entfernt werden. Dies macht XAML stark überladen, behindert die Migration erheblich und stört die einfache Kompatibilität mit Dingen wie der UNO-Plattform und Avalonia.

Bitte entfernen Sie die Notwendigkeit von xmlns:mux="using:Microsoft.UI.Xaml.Controls" aus XAML. Ich verstehe, dass sich der Code dahinter noch ändern muss. Es könnte auch eine Konfiguration dafür an irgendeiner Stelle im Projekt geben.

Bitte entfernen Sie die Notwendigkeit von xmlns:mux="using:Microsoft.UI.Xaml.Controls" aus XAML.

Es wird im XAML _markup_ nicht benötigt, aber das Ändern von Namespaces im Code-Behind wäre weiterhin erforderlich.

Wenn Sie die Windows-Steuerelemente verwenden möchten (wenn sie nicht aus dem Betriebssystem entfernt werden) - Sie müssen den Namespace in XAML deklarieren

Wenn Sie die Windows-Steuerelemente verwenden möchten (wenn sie nicht aus dem Betriebssystem entfernt werden) - Sie müssen den Namespace in XAML deklarieren

Mit WinUI 3.0 ist dies kein Szenario – Sie können Betriebssystemsteuerelemente nicht mit WinUI 3.0-Steuerelementen kombinieren. Das funktioniert derzeit nur mit WinUI 2.x, da diese Steuerelemente Add-Ons für das Betriebssystem sind (und wir haben viele unangenehme Fälle, in denen wir den Typ an beiden Orten wie NavigationView und TreeView ausgeliefert haben, was Mehrdeutigkeiten verursacht).

Wenn Sie die Windows-Steuerelemente verwenden möchten (wenn sie nicht aus dem Betriebssystem entfernt werden) - Sie müssen den Namespace in XAML deklarieren

Mit WinUI 3.0 ist dies kein Szenario – Sie können Betriebssystemsteuerelemente nicht mit WinUI 3.0-Steuerelementen kombinieren. Das funktioniert derzeit nur mit WinUI 2.x, da diese Steuerelemente Add-Ons für das Betriebssystem sind (und wir haben viele unangenehme Fälle, in denen wir den Typ an beiden Orten wie NavigationView und TreeView ausgeliefert haben, was Mehrdeutigkeiten verursacht).

Gut zu hören. Wird es einfacher machen, das vom Betriebssystem abzulehnen. Ich hoffe, die Einstellungs-App, die Shell und andere Teile des Betriebssystems werden auch auf WinUI 3.0 umgestellt.

Und hoffen wir, dass Ports der Administratortools, Wordpad usw. auf XAML übertragen werden und so viel wie möglich denselben Code wiederverwenden!

@jevansaks Ok, verstanden, danke für das Feedback!

@mdtauk Es besteht keine Notwendigkeit, zwischen den Legacy-Steuerelementen des Betriebssystems und den neuen Plattformsteuerelementen von 'WinUI 3.0' in XAML zu unterscheiden. Alles wird auf WinUI 3.0 verschoben und die Betriebssystemsteuerelemente erhalten, wie Sie wissen, keine Funktionsupdates mehr. Wenn ein Entwickler nach WinUI 3.0 weiterhin auf die Legacy-Steuerelemente abzielen möchte, sollte er mit älteren SDKs und Visual Studio-Versionen entwickeln. Die Möglichkeit, aus XAML auf zwei Microsoft/Windows-UI-Steuerelementbibliotheken zu verweisen, wäre aus den zuvor genannten Gründen nur ein Hindernis. Außerdem kann die Entwicklung mit der Entkopplung von WinUI endlich auf einen nachhaltigen Weg übergehen, um Änderungen wie diese zu "erlauben" - was nicht einmal ein Bruch ist.

Bearbeiten: Vergessen, vor dem Antworten zu aktualisieren, das meiste davon ist jetzt überflüssig.

@roloo Ich bin froh, dass dies die vorherigen Versionen von UWP Xaml wirklich ersetzen wird. Ich hoffe auch, dass das Betriebssystem für die Inbox-Apps und die Shell dorthin wechseln kann.

Ich hoffe auch, dass es viele Entwicklervideos geben wird, die den Umstieg auf WinUI 3.0 beschreiben – und wie man mit WinUI 3.0 mit demselben Lebenszyklus wie Win32-Apps arbeitet. Keine Rehydrierung mehr, bessere Möglichkeiten zum Speichern des Seitenstatus und der Navigation usw.

Es könnte hilfreich sein (je nachdem, welche Apps auf WinUI 3.0 umsteigen möchten) Beispiele dafür bereitzustellen, wie man beispielsweise Wordpad übernimmt und Code auf eine neue in WinUI integrierte Benutzeroberfläche überträgt – sowie eine Posteingangs-App wie Groove Music zu übernehmen und diese zu verschieben zu WinUI 3.0

Für WinUI 3 muss hinsichtlich der Platzierung von App-Funktionen in der Designsprache eine gewisse Konsistenz herrschen.

In diesem Zusammenhang App-Einstellungen.

Wo finde ich die App-Einstellungen? Klicke ich oben rechts auf das Zahnrad? Untere linke Ecke? Muss ich oben rechts auf den Profil-Avatar klicken und auf Einstellungen klicken? Klicke ich oben links? Unten links? Gehe ich zu Bearbeiten > Einstellungen?

Hängt wirklich davon ab, ob Sie NavigationView verwenden...

Von: shaheedmalik [email protected]
Gesendet: Donnerstag, 12. September 2019 15:48:12
An: microsoft/microsoft-ui-xaml [email protected]
Cc: Der scharfe Ninja [email protected] ; Kommentar [email protected]
Betreff: Re: [microsoft/microsoft-ui-xaml] WinUI 3.0 Entwicklererfahrung und Tools - Eingabe erforderlich (#1045)

Für WinUI 3 muss hinsichtlich der Platzierung von App-Funktionen in der Designsprache eine gewisse Konsistenz herrschen.

In diesem Zusammenhang App-Einstellungen.

Wo finde ich die App-Einstellungen? Klicke ich oben rechts auf das Zahnrad? Untere linke Ecke? Muss ich oben rechts auf den Profil-Avatar klicken und auf Einstellungen klicken? Klicke ich oben links? Unten links? Gehe ich zu Bearbeiten > Einstellungen?

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie auf diese E - Mail direkt, sehen sie auf GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLB5VXXUOYIA2NIEZATQJKTIZA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6TGV4I#issuecomment-531000049 , oder schalten Sie den Faden https: // GitHub. com/notifications/unsubscribe-auth/AD3GCLCQQ6L7H3LEJAHUDMLQJKTIZANCNFSM4ICOLUJQ .

Wie können wir Ihnen helfen, in Bezug auf Vorlagen und Komponenten in Visual Studio effizienter oder erfolgreicher zu sein?

Es sollte keinen erheblichen Aufwand und keine undokumentierten Projektkonfigurationsattribute erfordern, damit WinUI/XAML Islands mit C++/WinRT in Visual Studio funktioniert.

Ich kann dies nicht genug betonen, aber das Wichtigste für mich ist, dass WinUI für mehr als nur Windows rendert.

Als ich das Surface Duo sah, fragte ich mich, wie die plattformübergreifende Entwicklungsgeschichte nun aussehen wird, da Microsoft ein Android-basiertes Gerät veröffentlicht. Xamarin.Forms schneidet es aus einer Reihe offensichtlicher Gründe nicht ab. Es ist an der Zeit, dass Microsoft ein plattformübergreifendes Toolkit (wie die UNO-Plattform, aber fertig und stabil) vollständig einsetzt, von dem wir alle wissen, dass es seit Jahren in verschiedenen Formen angefordert wird. Ich hoffe, Microsoft hat hier ein paar Pläne für Entwickler.

Satya sagte: "Wir wollten nicht nur Erfahrung und ein Gerät aufbauen, sondern alle Geräte in unserem Leben umfassen." Wenn Sie möchten, dass Entwickler an dieser Fahrt teilnehmen, wie Panos hofft, ist dies der beste Weg, dies zu tun. Andernfalls bitten Sie die Entwickler, zwei separate Benutzeroberflächen zu schreiben, um die "Erfahrung" zwischen Surface Duo und dem Rest der Familie zu überbrücken. Ich denke nicht, dass dies eine faire Anfrage an Entwickler innerhalb einer "Familie" von Geräten ist.

Rendert auf jeder Plattform anders, auch bekannt als "natives Look and Feel".

Ich verstehe das nicht. Bitte nicht, das Letzte, was ich möchte, ist, dass Fluent Design mehr Inkonsistenz verursacht, nicht weniger.

EDIT: Originalkommentar entfernt

Satya sagte: "Wir wollten nicht nur Erfahrung und ein Gerät aufbauen, sondern alle Geräte in unserem Leben umfassen." Wenn Sie möchten, dass Entwickler an dieser Fahrt teilnehmen, wie Panos hofft, ist dies der beste Weg, dies zu tun. Andernfalls bitten Sie die Entwickler, zwei separate Benutzeroberflächen zu schreiben, um die "Erfahrung" zwischen Surface Duo und dem Rest der Familie zu überbrücken. Ich denke nicht, dass dies eine faire Anfrage an Entwickler innerhalb einer "Familie" von Geräten ist.

Genau aus diesem Grund war ich niedergeschlagen, dass das Duo Android war.

Die Vorlagen müssen Open Source sein, um alle darin auftretenden Problembereiche zu entfernen.

Wann verwende ich WinUI mit WPF und wann erstelle ich ein neues Steuerelement mit Code wie:
c# public class MyControl : UserControl { ... }
Es wird WinUI.UserControl oder WPF.UserControl verwenden?
Müssen wir uns entscheiden und wie gehen wir damit um?

Und interessant, wenn die XAML-Tools vereinheitlicht werden, werden wir dann die Möglichkeit haben, eine Art gemeinsam genutzter XAML-Dateien zu erstellen?
Etwas wie:

<UserControl xmlns="???" xmlns:uwp="???" xmlns:wpf="???">
   <!-- Potentional xmlns:android="???" xmlns:avalonia="???" -->
   <Button uwp:Content="Hi, UWP!" wpf:Content="Hi, WPF!">
</UserControl>

Sollte es eine Art gemeinsamer Dialekt mit speziellem Root-Namespace sein? (wie freigegebene Projekte in Visual Studio). Es könnte wie bedingtes xaml aussehen.

Es wird WinUI.UserControl oder WPF.UserControl verwenden?
Müssen wir uns entscheiden und wie gehen wir damit um?

Dies sollte automatisch in der XAML geschehen, in der Sie definieren

<UserControl 
   x:Class="MyApp.MyControl" 
   xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

Das teilt dem Compiler mit, dass es sich um UWP handelt.

public class MyControl : UserControl { ... }

Dies ist tatsächlich falsch. Du solltest so erklären

public partial class MyControl { }

Es ist keine Vererbung erforderlich, da sie von der .g.cs-Datei verarbeitet wird, die die Vererbung und auch das verwendete Framework angibt.

Was Vorlagen angeht, wäre ich glücklicher, wenn es mehr als eine Hello World-Vorlage gäbe. Was ich meine ist, dass Microsoft einige von Peripheriegeräten erkannte Frameworks sichern sollte, die für die Arbeit mit Client-Apps erforderlich sind

@weitzhandler Das würde ich auch gerne sehen !!

Projekte im SDK-Stil für C#- und Cpp/WinRT-Projekte sollten ebenfalls ein Muss sein

Ich denke, es sollte Vorlagen für alle gängigen Win32- und Inbox-App-Muster geben. Eine kurze Liste aus meinem Kopf:

• Schleife
• Hauptmenü
• Dokumentschnittstelle mit Registerkarten
• Navigationsansicht
• Befehl/Symbolleiste
• Navigationsansicht oben
• Hub/Galerie (ich weiß, dass dies etwas veraltet ist)
• Treeview/MasterDetails (Datei-Explorer, RegEdit, Administrations-App)

Es sollte aber auch Elementvorlagen für gängige Dialoge, Seiten, Einstellungsseiten etc. geben.

Wie können wir Ihnen helfen, in Bezug auf Vorlagen und Komponenten in Visual Studio effizienter oder erfolgreicher zu sein?

Arbeiten Sie mit der C++-Erweiterung für VSCode/Visual Studio. Ich möchte VS Code auch als unterstützten Editor sehen, der eine ähnliche Erfahrung wie Visual Studio bietet. WinUI soll OSS sein und VS Code auch, also denke ich, dass dies machbar ist.

Tools wie Template10 und Windows Template Studio sind Anzeichen für fehlende grundlegende Funktionen. Mit WinUI3 sollte es Funktionen für das geben, was diese Tools tun. Ich wette, dass viele Entwickler dieses grundlegende Gerüst immer wieder machen ... es sollte Teil des Frameworks sein. Es sollten keine zusätzlichen Werkzeuge benötigt werden. Vielleicht sollten Sie das MVVM-Gerüst sogar für die seltenen Fälle ausschalten, in denen Sie darauf verzichten möchten.

Nachdem ich etwas mit ASPNET Core gearbeitet habe, fehlt mir die Dependency Injection. Diese Funktion ist nativ in ASPNET Core vorhanden. Es funktioniert einfach, ohne dass Sie etwas extra tun müssen. Und Sie können Dienste so einfach hinzufügen oder ändern, wenn Sie möchten. Aber für UWP heute musst du das selbst bauen oder so etwas wie WTS verwenden, um loszulegen, aber es fühlt sich immer noch so an, als wäre es danach geklebt. WinUI3 mit der richtigen nativen Abhängigkeitsinjektion wäre so hilfreich.

Ich glaube nicht, dass das Vorhandensein von Vorlagensystemen einen Mangel an grundlegender Funktionalität zeigt, ich denke, es unterstreicht die Qualität der unterstützenden Gemeinschaften, die diese Vorlagensysteme zusammenstellen würden.

Tools wie Template10 und Windows Template Studio sind Anzeichen für fehlende grundlegende Funktionen.

Ich sehe solche Dinge als Erweiterung der Grundfunktionalität. Natürlich könnten solche Dinge ins Haus gebracht werden, aber es ist dann mehr Sache des Kernteams, es zu pflegen und zu unterstützen. Da das Kernteam mehr tut, bedeutet dies, dass es dünner verteilt ist und alles länger dauert. Wenn Msft der Meinung ist, dass sie Budget haben, um solche Dinge in das Hauptteam zu bringen, würde ich gerne mit jemandem darüber sprechen;)

Nur ein paar Gedanken zu vereinfachtem Stil und Steuerelementvorlagen, wie z. B. das Hinzufügen von benutzerdefiniertem Verhalten für integrierte Stile und Steuerelemente. Das perfekte Beispiel hierfür ist das Button Styling, wenn wir die gesamte Steuerelementvorlage überschreiben müssen, um die Hover-Farbe zu ändern oder den Randradius zu verwenden. Wenn Sie einige von ihnen direkt festlegen, wie in css , wird verhindert, dass Kilometer XAML-Code erstellt werden

@AntiPasha Hast du schon von Leichtgewichts-Styling gehört ? Damit können Sie die Hover-Farbe ganz einfach ändern, ohne den gesamten Stil neu erstellen zu müssen:

Das Ändern der Hover-Farbe für eine Schaltfläche wäre dann nur:

            <Button Content="MyButton">  
                <Button.Resources>
                    <ResourceDictionary>
                        <ResourceDictionary.ThemeDictionaries>
                            <ResourceDictionary x:Key="Dark">
                                <SolidColorBrush x:Key="ButtonForegroundPointerOver" Color="Blue"/>
                                <SolidColorBrush x:Key="ButtonBackgroundPointerOver" Color="Transparent" />
                            </ResourceDictionary>
                        </ResourceDictionary.ThemeDictionaries>
                    </ResourceDictionary>
                </Button.Resources>
            </Button>

Eine Control.CornerRadius- Eigenschaft wurde auch im 17763 SDK hinzugefügt und das WinUI-Team führt auch überschreibbare Ressourcen ein, um ganz einfach App- oder seitenweite Anpassungen hinzuzufügen, ohne Steuerelemente neu gestalten zu müssen: https://github.com/microsoft/microsoft-ui- xaml-specs/blob/user/chigy/roundedcorner/active/RoundedCorner/roundedcorner.md#customization -options

Und interessant, wenn die XAML-Tools vereinheitlicht werden, werden wir dann die Möglichkeit haben, eine Art gemeinsam genutzter XAML-Dateien zu erstellen?
Etwas wie:

<UserControl xmlns="???" xmlns:uwp="???" xmlns:wpf="???">
   <!-- Potentional xmlns:android="???" xmlns:avalonia="???" -->
   <Button uwp:Content="Hi, UWP!" wpf:Content="Hi, WPF!">
</UserControl>

Sollte es eine Art gemeinsamer Dialekt mit speziellem Root-Namespace sein? (wie freigegebene Projekte in Visual Studio). Es könnte wie bedingtes xaml aussehen.

@Tirraon das ist ein wirklich interessantes Beispiel, aber ich denke, wenn wir über die Vereinheitlichung von Werkzeugen sprechen, ist es besser, mit der Denkweise zu beginnen, dass die Plattformen so existieren werden, wie sie es heute tun, und wir nicht versuchen, einen weiteren Xaml-Standard zu erstellen gleichwertig.

Wir können den Standard-Namespace verwenden, um zu unterscheiden, zu welcher "Top-Level"-Plattform die xaml-Datei gehört. Wir könnten also beispielsweise die folgenden Standard-Namespaces für jede XAML-Plattform haben (diese sind meist hypothetisch, also nehmen Sie sie mit Vorsicht ):

wpf: xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
uwp: xmlns="http://github.com/microsoft/microsoft-ui-xaml"
Avalonie: xmlns="https://github.com/AvaloniaUI/AvaloniaUI"
uno: xmlns="https://github.com/unoplatform/uno"
xamarin.forms: xmlns="https://github.com/xamarin/Xamarin.Forms"

Um WinUI mit WPF unter Verwendung von Xaml Islands zu vermischen, haben Sie ein Markup, das wie folgt aussieht:

<UserControl xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
                       xmlns:uwp="http://github.com/microsoft/microsoft-ui-xaml">
   <StackPanel>
     <uwp:Button Content="Hi, UWP!" x:Name="uwpButton">
     <Button Content="Hi, WPF!" Width="{x:Bind uwpButton.Width}" />
   </StackPanel>

</UserControl>

Was denken Sie?

@stevenbrix
In Ihrem Beispiel für UWP werden beide Schaltflächen gerendert, nicht wahr?
Ich meine, für den Fall, wenn xmlns=".../xaml/presentation" der Namespace der obersten Ebene ist und UserControl wutg StackPanel sowohl in uwp als auch in wpf verfügbar ist, wäre dann der zweite Button nicht auch auf beiden Plattformen verfügbar?

Wenn wir über die Vereinheitlichung von Werkzeugen sprechen, ist es besser, mit der Denkweise zu beginnen, dass die Plattformen so existieren werden, wie sie es heute tun

Ja, ich stimme dem voll und ganz zu.

In Ihrem Beispiel für UWP werden beide Schaltflächen gerendert, nicht wahr?
Ich meine, für den Fall, wenn xmlns=".../xaml/presentation" der Namespace der obersten Ebene ist und UserControl wutg StackPanel sowohl in uwp als auch in wpf verfügbar ist, wäre dann der zweite Button nicht auch auf beiden Plattformen verfügbar?

@Tirraon , das von mir angegebene Beispiel gilt ausschließlich für die WPF-Anwendung, die Xaml Islands verwendet, um ihre Anwendung inkrementell zu modernisieren. Es ist nicht für ein "Standard"-Markup gedacht, das zwischen WPF- und WinUI-Anwendungen verwendet wird. Ist das sinnvoll?

Derzeit müssen App-Autoren, die Xaml Islands verwenden möchten, Benutzersteuerelemente für jede Insel erstellen. Sie verweisen dann über eine Zeichenfolge in ihrem WPF-Markup auf den Typ, anstatt WinUI-Elemente natürlich in das WPF-Markup einzubetten.

Ich telefoniere gerade, aber sobald ich in der Nähe meines PCs bin, kann ich ein konkreteres Vorher und Nachher von dem bekommen, was ich vorschlage.

@stevenbrix
Oh, jetzt habe ich dich, danke.

@stevenbrix
Oh, jetzt habe ich dich, danke.

@Tirraon großartig! Schön, dass wir auf der gleichen Seite sind ☺️

Es tut mir leid, wenn meine Idee aus dem Nichts zu kommen schien, wir waren in frühen Diskussionen darüber, wie wir die Tools möglicherweise vereinheitlichen könnten, um das Szenario von Xaml Island zu verbessern. Glauben Sie, dass so etwas einen Wert hat?

FWIW, ich denke definitiv, dass etwas wie das, was Sie vorgeschlagen haben, seinen Wert hat. Aber ich versuche, mich auf etwas zu konzentrieren, das wir im WinUI3/.NET5-Zeitrahmen erledigen können.

Finden Sie heraus, wie Sie WinUI Xaml in eine Pipeline rendern, die die Ausgabe in einen nativen Canvas übersetzt und Eingaben von einem nativen Nachrichtensystem empfängt. Wie WinUi.Adapters.DirectX, WinUI.Adapters.WASM, WinUi.Adapters.X, WinUi.Adapters.Android.

Beim Launch müssen nicht alle Adapter implementiert werden, sondern nur die, die für die Unterstützung von Windows 10 erforderlich sind.

Von: Steven Kirbach [email protected]
Gesendet: Donnerstag, 7. November 2019 09:13:46
An: microsoft/microsoft-ui-xaml [email protected]
Cc: Der scharfe Ninja [email protected] ; Kommentar [email protected]
Betreff: Re: [microsoft/microsoft-ui-xaml] WinUI 3.0 Entwicklererfahrung und Tools - Eingabe erforderlich (#1045)

@stevenbrix https://github.com/stevenbrix
Oh, jetzt habe ich dich, danke.

@Tirraon https://github.com/Tirraon großartig! Schön, dass wir auf der gleichen Seite sind ☺️

Es tut mir leid, wenn meine Idee aus dem Nichts zu kommen schien, wir waren in frühen Diskussionen darüber, wie wir die Tools möglicherweise vereinheitlichen könnten, um das Szenario von Xaml Island zu verbessern. Glauben Sie, dass so etwas einen Wert hat?

FWIW, ich denke definitiv, dass etwas wie das, was Sie vorgeschlagen haben, seinen Wert hat. Aber ich versuche, mich auf etwas zu konzentrieren, das wir im WinUI3/.NET5-Zeitrahmen erledigen können.

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie auf diese E - Mail direkt, sehen sie auf GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLBHRGZTDFHFWQTAFK3QSQWCVA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDMXFLY#issuecomment-551121583 oder abmelden https://github.com/ notifications/unsubscribe-auth/AD3GCLF2BUTXQFPSVNULZODQSQWCVANCNFSM4ICOLUJQ .

Ja bitte, das XAML Island-Szenario ist im Moment schrecklich

@sharpninja
Sie sollten sich Uno . anschauen
https://plattform.uno/
Außerdem wird WinUI 3.0 für jede Plattform unterstützt
https://platform.uno/winui-on-windows7-via-unoplatform/

@stevenbrix
Ich bin nicht wirklich erfahren mit Xaml Islands und arbeite normalerweise mit einfachem UWP. Aber ich muss mir das unbedingt genauer anschauen.
Mein Vorschlag bezog sich nicht auf Xaml Islands selbst, sondern eher auf WinUI im Allgemeinen, da er auf mehr als einer Plattform funktioniert.

Mein Vorschlag bezog sich nicht auf Xaml Islands selbst, sondern eher auf WinUI im Allgemeinen, da er auf mehr als einer Plattform funktioniert.

@Tirraon , yup, ich

Ich habe kurz mit @jeromelaban und Co. darüber gesprochen, was Sie genau vorschlagen, und es besteht definitiv Interesse. Es gibt noch keinen konkreten Plan oder Zusagen, da wir uns noch in einem sehr frühen Stadium der Gespräche befinden. Diese Art von Input ist großartig und hilft uns, den Wert, den sie für unsere Kunden bringt, besser zu verstehen 😄

Mit dem XAML-Insel-Szenario meine ich das C++-Szenario. Eine Liste der Probleme, mit denen ich konfrontiert war, finden Sie in meinen vorherigen Nachrichten in diesem Thread.

Ja bitte, das XAML Island-Szenario ist im Moment schrecklich

Mit dem XAML-Insel-Szenario meine ich das C++-Szenario. Eine Liste der Probleme, mit denen ich konfrontiert war, finden Sie in meinen vorherigen Nachrichten in diesem Thread.

@sylveon Ich sehe deine Kommentare (Links unten), und ja, das klingt ziemlich schrecklich. Es tut mir leid, dass Sie das erleben, ich bin zuversichtlich, dass wir es besser machen werden.
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment -512945553
https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment -513505038

Ein Großteil des Schmerzes, den Sie durchmachen, klingt projektsystembezogen, und ich weiß, dass das auf dem Radar vieler Leute ist (obwohl ich ziemlich distanziert bin). Haben Sie dieses Video gesehen, das einige unserer Teammitglieder zu XAML-Tools gemacht haben? Dieser Link sollte das YouTube-Video an dem Punkt starten, an dem @michael-hawker und @marb2000 beginnen, in das neue Xaml Island-Erlebnis einzusteigen. C++ ist uns definitiv wichtig, aber ich weiß nicht, ob wir bisher nur die .NET-Erfahrung angesprochen haben oder ob es auch Verbesserungen an C++ gegeben hat. Sie könnten wahrscheinlich mehr dazu kommentieren.

Es gibt viele Dinge, die dazu beitragen, die Erfahrung der Xaml-Insel einfach und natürlich zu machen. Der Aspekt, auf den ich mich beziehe, ist, dass Sie derzeit eine Insel mit UWP-Inhalten in WPF wie folgt einschließen (aus dem obigen Video):

  <Grid>
   <xi:WindowsXamlHost InitialTypeName="UWP_XamlApplication.SamplePage"/>
  </Grid>

Ich denke, wir können es besser machen und bieten so etwas an:

  <Grid>
   <uwp:SamplePage />
  </Grid>

@stevenbrix

Ich habe kurz mit @jeromelaban und Co. darüber gesprochen, was Sie genau vorschlagen, und es besteht definitiv Interesse. Es gibt noch keinen konkreten Plan oder Zusagen, da wir uns noch in einem sehr frühen Stadium der Gespräche befinden. Diese Art von Input ist großartig und hilft uns, den Wert, den sie für unsere Kunden bringt, besser zu verstehen

Das Interesse ist so groß! (Diese Diskussion taucht überall auf) Wenn WinUI nach 3.0 zu plattformübergreifenden Implementierungen übergehen würde, hätten Sie viel Entwicklerunterstützung. Schauen Sie sich einfach die Diskussion zu Nr. 1461 an. Kurzfristig wäre es erstaunlich, mit Uno Platform-Technologie XAML/C# in HTML/WASM zu konvertieren, um UWP-Apps auf allen Plattformen zum Laufen zu bringen. Längerfristig mache ich mir Sorgen über die Leistungseinbußen bei der Ausführung in Electron oder einem Browser und es gibt Raum für eine effizientere Architektur.

Unterm Strich weiß ich, dass im Moment alle mit WinUI 3.0 beschäftigt sind. Aber wenn das fertig ist, wäre es großartig, wenn wir @jeromelaban , @marb2000 , @jevansaks und andere miteinander verbinden würden , um herauszufinden , wie UWP überall am besten

WinUi ist der einzige vernünftige Weg, der dazu führt, dass sowohl Neo als auch Duo überleben

Von: robloo [email protected]
Gesendet: Donnerstag, 7. November 2019 12:00:07
An: microsoft/microsoft-ui-xaml [email protected]
Cc: Der scharfe Ninja [email protected] ; Erwähnen Sie Erwä[email protected]
Betreff: Re: [microsoft/microsoft-ui-xaml] WinUI 3.0 Entwicklererfahrung und Tools - Eingabe erforderlich (#1045)

@stevenbrix https://github.com/stevenbrix

Ich habe kurz mit @jeromelaban https://github.com/jeromelaban und Unternehmen darüber gesprochen, was Sie genau vorschlagen, und es besteht definitiv Interesse. Es gibt noch keinen konkreten Plan oder Zusagen, da wir uns noch in einem sehr frühen Stadium der Gespräche befinden. Diese Art von Input ist großartig und hilft uns, den Wert, den sie für unsere Kunden bringt, besser zu verstehen

Das Interesse ist so groß! (Diese Diskussion taucht überall auf) Wenn WinUI nach 3.0 zu plattformübergreifenden Implementierungen übergehen würde, hätten Sie viel Entwicklerunterstützung. Schauen Sie sich einfach die Diskussion zu #1461 an https://github.com/microsoft/microsoft-ui-xaml/issues/1461 . Kurzfristig wäre es erstaunlich, mit Uno Platform-Technologie XAML/C# in HTML/WASM zu konvertieren, um UWP-Apps auf allen Plattformen zum Laufen zu bringen. Längerfristig mache ich mir Sorgen über die Leistungseinbußen bei der Ausführung in Electron oder einem Browser und es gibt Raum für eine effizientere Architektur.

Unterm Strich weiß ich, dass im Moment alle mit WinUI 3.0 beschäftigt sind. Aber wenn das fertig ist, wäre es großartig, wenn wir @jeromelaban https://github.com/jeromelaban , @marb2000 https://github.com/marb2000 , @jevansaks https://github.com/jevansaks und andere damit verbinden würden Finden Sie heraus, wie Sie UWP überall rendern können. Das wäre auch eine sehr interessante Community-Diskussion für einen zukünftigen Aufruf.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie auf diese E - Mail direkt, sehen sie auf GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLCHIRMGIIB4EEMXQATQSRJSPA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDNI2QA#issuecomment-551193920 oder abmelden https://github.com/ notifications/unsubscribe-auth/AD3GCLCAZIOGVET6CJKLKLTQSRJSPANCNFSM4ICOLUJQ .

WinUi ist der einzige vernünftige Weg, der dazu führt, dass sowohl Neo als auch Duo überleben

Ich neige dazu, zuzustimmen, aber die gleiche Benutzeroberfläche von einer Windows-App zu erhalten, die auf Android und dem Surface Duo ausgeführt wird. Mit minimalem Eingreifen des Entwicklers - das ist der heilige Gral.

Wenn WinUI eine Chance hat, eine primäre Entwicklungsplattform zu sein und Windows eine Chance zu geben, langfristig nicht nur ein Behälter für die Apps anderer Plattformen zu werden. (Nicht immer schlecht, wenn es um große etablierte Apps geht, aber für LoB und die nächsten großen Apps...)

Ich erstelle meine eigene anwendungsorientierte Sprache und möchte die Verwendung von WinUI mit XAML und meiner Sprache für CodeBehind unterstützen. Es wäre gut, wenn die Tools die Möglichkeit bieten würden, dass eine Sprache Codegenerierung für XAML bereitstellt. Noch besser wäre es, wenn der XAML-Codegenerator IL als Teilklasse erstellt, die mit jeder Sprache vervollständigt werden könnte. Das würde bedeuten, dass der Codegenerator eine kompilierbare IL-Assembly ausgeben würde.

Ich erstelle meine eigene anwendungsorientierte Sprache und möchte die Verwendung von WinUI mit XAML und meiner Sprache für CodeBehind unterstützen. Es wäre gut, wenn die Tools die Möglichkeit bieten würden, dass eine Sprache Codegenerierung für XAML bereitstellt. Noch besser wäre es, wenn der XAML-Codegenerator IL als Teilklasse erstellt, die mit jeder Sprache vervollständigt werden könnte. Das würde bedeuten, dass der Codegenerator eine kompilierbare IL-Assembly ausgeben würde.

Es gibt XAML Direct, wird aber derzeit von C# und C++ unterstützt.
https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.core.direct

Das ist nicht das was ich meine. Ich meine, dass die Ausgabe des Codegenerierungstools IL ist, nicht C# oder C++. Auf diese Weise kann mein Compiler XAML in IL umwandeln und dann diese Klasse erben.

@sharpninja Es wäre auch von Vorteil, wenn es statt nur C++-Code auch LLVM-Bytecode generieren kann.

Auf diese Weise können wir es mit MIDL und XLang kombinieren, um COM-Bibliotheken und WinMD-Dateien zu generieren, die in allen von XLang unterstützten Szenarien verwendet werden können.

Mit aufgesetztem C++-Hut würde ich mir in Bezug auf WinUI-Tools für C++ wünschen, dass Microsoft endlich aufholt, was C++ Builder seit Mitte der 90er Jahre getan hat.

Stellen Sie aktuelle RAD-Tools für die C++-basierte Entwicklung bereit.

C++/CLI scheiterte daran, obwohl es bei Formularen einige Problemumgehungen gab.

C++/CX schien es zu sein, erforderte jedoch etwas mehr Aufwand als das, was C++ Builder leisten kann.

Nun mag C++/WinRT Standard-C++17 sein, aber die Gesamterfahrung für Desktop-Entwickler fühlt sich wie ein Downgrade an, mit der Zunahme der Boilerplate, die man manuell schreiben muss, zusätzlicher Sorgfalt, wie COM-Typen die ABI-Grenze überschreiten, und fehlendem Designer Unterstützung.

Daher verwende ich vorerst immer noch C++/CX, da ich mich nicht mit allen für den MIDL-Compiler und die COM ABI-Unterstützung erforderlichen Boilerplates auseinandersetzen kann.

Auf der anderen Seite, mit meinem .NET-Hut, würde ich gerne sehen, dass nur C++-Bibliotheken wie DirectX endlich als WinUI-Komponenten enthüllt werden, einige Blend lieben, und daran denkend, dass F# angeblich auch eine .NET-Sprache von Microsoft ist.

Ich hatte erhebliche Schwierigkeiten, auf WinUI umzusteigen. Es gibt eine Reihe von 1st- und 3rd-Party-Bibliotheken, die WinUI derzeit nicht verwenden, und Abhängigkeiten von ihnen werden problematisch. Zum Beispiel das Verhaltens-SDK.

Dies ist eine Idee, die ich hatte, als ich im UWP-Community-Discord über StatusBar sprach.

Lassen Sie in Visual Studio die Toolbox Einträge für WPF-Steuerelemente einschließen, die in UWP fehlen, und zeigen Sie bei Auswahl dieser Einträge ein Popup an, in dem erklärt wird, wie das herkömmliche Steuerelement simuliert wird.

Diese Idee stammt aus dem Wunsch, den Übergang für Personen zu erleichtern, die von WPF (oder anderen Frameworks) kommen, wo sie bestimmte Steuerelemente erwarten. Woher weiß man, dass CommandBar wie StatusBar verwendet werden kann? Ich denke, wir müssen es den Leuten so einfach wie möglich machen, auf WinUI umzusteigen. Dies könnte dazu dienen, einige Lücken zu schließen, ohne dass alle fehlenden Kontrollen tatsächlich entwickelt werden müssen.

BEARBEITEN:
Und der Vollständigkeit halber habe ich noch etwas über die Statusleiste gesagt.

Re: StatusBar - Ich dachte aus der Perspektive von Benutzern traditioneller Frameworks, die UWP ausprobieren - und sah, dass es keine StatusBar hat - immer noch ein Grundnahrungsmittel in vielen Apps. Ja, CommandBar könnte sogar besser sein. Aber die Leute wissen nicht, was eine CommandBar ist oder vermuten, dass es sich um etwas anderes handelt. Jemand oben hat sogar vorgeschlagen, dass ich ein Raster hinzufüge, es unten lege, es eine Reihe hoch mache und verschiedene Steuerelemente hinzufüge, um Dinge anzuzeigen. Es scheint also, dass selbst bestehende Xaml-Designer CommandBar nicht kennen. Wie auch immer, vielleicht hast du Recht, vielleicht ist CommandBar besser, aber Paul Thurrot hat es nicht in seiner UWP-Notizblock-App verwendet, er hat ein Raster verwendet. Es scheint also, dass die CommandBar nicht als Ersatz für StatusBar kommuniziert wird. Gelegenheits- (oder neue) Entwickler suchen immer noch nach StatusBar und finden sie nicht. Ich weiß, dass Paul Thurrot kein Entwickler ist, aber Sie verstehen, was ich meine.

Es wäre toll, wenn auch bei einem normalen Anwendungsfall Snippets in das xaml injiziert würden.

Von: Gavin-Williams [email protected]
Gesendet: Dienstag, 18. Februar 2020 19:05:39
An: microsoft/microsoft-ui-xaml [email protected]
Cc: Der scharfe Ninja [email protected] ; Erwähnen Sie Erwä[email protected]
Betreff: Re: [microsoft/microsoft-ui-xaml] WinUI 3.0 Entwicklererfahrung und Tools - Eingabe erforderlich (#1045)

Dies ist eine Idee, die ich hatte, als ich im UWP-Community-Discord über StatusBar sprach.

Lassen Sie in Visual Studio die Toolbox Einträge für WPF-Steuerelemente einschließen, die in UWP fehlen, und zeigen Sie bei Auswahl dieser Einträge ein Popup an, in dem erklärt wird, wie das herkömmliche Steuerelement simuliert wird.

Diese Idee stammt aus dem Wunsch, den Übergang für Personen zu erleichtern, die von WPF (oder anderen Frameworks) kommen, wo sie bestimmte Steuerelemente erwarten. Woher weiß man, dass CommandBar wie StatusBar verwendet werden kann? Ich denke, wir müssen es den Leuten so einfach wie möglich machen, auf WinUI umzusteigen. Dies könnte dazu dienen, einige Lücken zu schließen, ohne dass alle fehlenden Kontrollen tatsächlich entwickelt werden müssen.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie auf diese E - Mail direkt, sehen sie auf GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045?email_source=notifications&email_token=AD3GCLGYERSFO7LBXKWBBRDRDSAWHA5CNFSM4ICOLUJ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMF6O3Y#issuecomment-587982703 oder abmelden https://github.com/ Benachrichtigungen/unsubscribe-auth/AD3GCLFLGA773XOS5OSG5ULRDSAWHANCNFSM4ICOLUJQ .

Die Entwickler-Story sollte eine Art Vergleichsliste enthalten.

Konzepte, die für Win32-Apps intrinsisch sind, also Statusleisten, Symbolleisten, Menüs, Greifer, Registerkarten usw. In einer Liste und die WinUI-Äquivalente auf der anderen.

Die Seite selbst enthält Codebeispiele von beiden, um zu zeigen, wie die Benutzeroberfläche einer vorhandenen App auf WinUI verschoben werden kann.

Offene Fragen)
Wäre es von Vorteil, wenn wir ein Migrationstool bereitstellen würden, das die Schritte 1-3 automatisiert?

Jawohl. Ich unterstütze 1 "alte" Windows Forms-App (alt bedeutet kein Budget zum Neuschreiben) und 2 oder 3 ältere WPF-Apps. Die WinForms-App mag gestrandet sein, aber ein Tool, um die WPF-Apps schnell auf WinUI 3 zu portieren, wäre großartig!

MSIX ist die moderne Paketierungsmethode für alle Apps. Sollten wir für WinUI in Win32 ClickOnce unterstützen? Welche anderen Verpackungsmethoden sollten wir unterstützen? Speziell für WinUI in Win32

Wir verwenden derzeit ClickOnce, um Apps auf den Desktops unserer Benutzer zu veröffentlichen. Ein Modell von automatisierten Updates wäre immer noch wünschenswert.

@JeffSchwandt

Diese Schritte betrafen die Konvertierung von WinUI-Projekten mit früheren Versionen (1-2) in Version 3.

Die Konvertierung einer WPF-App in eine WinUI-App ist automatisiert nicht besonders machbar (ohne enormen Aufwand, aber selbst dann wäre es extrem fehleranfällig).

Ich hoffe, dies ist der richtige Thread für diese Anfrage.

Rust braucht gerade dringend ein richtiges UI-Framework. Es wäre schön, wenn WinUI Rust in Zukunft mit einem nativen SDK und einigen Tools unterstützen könnte.

Ich hoffe, dies ist der richtige Thread für diese Anfrage.

Rust braucht gerade dringend ein richtiges UI-Framework. Es wäre schön, wenn WinUI Rust in Zukunft mit einem nativen SDK und einigen Tools unterstützen könnte.

Gute Nachrichten, Rust/WinRT befindet sich in der Entwicklung, die es Rust-Apps ermöglichen wird, WinRT-APIs wie WinUI zu verwenden! Werfen Sie einen Blick auf https://kennykerr.ca/2020/02/22/rust-winrt-coming-soon/

@jevansaks Hey, danke für die Antwort! Ja, ich weiß, dass Kenny mit Rust/WinRT arbeitet, aber ich frage mich, ob WinRT die einzige API-Schicht ist, die WinUI unterstützt? Ich bin mir nicht sicher, wie dies mit der Tatsache zusammenpassen würde, dass die WinRT-API-Nutzung von Desktop-Apps nur in Windows 10 1903 verfügbar wurde, während WinUI darauf abzielt, ältere Versionen von Windows 10 zu unterstützen.

Rust/WinRT (wie C++/WinRT) sollte bis hinunter zu Windows 7 funktionieren. WinRT selbst hat schon immer mit Desktop-/Win32-Apps funktioniert. Es sind nur bestimmte APIs, die Speicher-/Uwp-/Packaging-Anforderungen hatten (nicht WinRT als Ganzes). Solange WinUI diese Anforderungen nicht erfüllt, können Sie WinUI von Desktop-Apps über C++/WinRT und Rust/WinRT auf jeder unterstützten Plattform verwenden.

WinUI-Desktop-Apps sollten Live-Kacheln und Kachelaktualisierungen unterstützen – mit guten einfachen Beispielen und SDK-Tools, um Kacheln einfacher zu erstellen als heute UWP-Apps.

Ich bin mir nicht sicher, wie dies mit der Tatsache zusammenpassen würde, dass die WinRT-API-Nutzung von Desktop-Apps nur in Windows 10 1903 verfügbar wurde

WinUI Desktop wird derzeit für WinUI 3.0 entwickelt, und das sollte es einfachen Win32-Apps ermöglichen, WinUI-Downlevel zu verwenden (der aktuelle Plan ist auf 1803).

Die Windows-Benutzeroberfläche sollte mindestens die wichtigsten MVVM-Frameworks unterstützen – MVVM Light, Prism und Caliburn. Leider bricht Ihr dokumentiertes Problem mit Änderungen an INotifyPropertyChanged und INotifyCollectionChanged ObservableCollectionsicherlich bricht MVVM Light und wahrscheinlich auch die anderen beiden Frameworks. Dachte, du solltest es wissen.

Leider zerstört Ihr dokumentiertes Problem mit Änderungen an INotifyPropertyChanged und INotifyCollectionChanged, die ObservableCollection zerstören, MVVM Light und wahrscheinlich auch die anderen beiden Frameworks. Dachte, du solltest es wissen.

Danke @terrycox! Wir sind uns bewusst und dies wird von WinUI 3.0 RTM behoben, und idealerweise in einem Vorschau-Build vorher ;)

@terrycox Windows-Benutzeroberfläche sollte mindestens die wichtigsten MVVM-Frameworks unterstützen - MVVM Light, Prism und Caliburn. ... dein dokumentiertes Problem

Ja, es sollte dokumentierte Probleme beheben, aber es ist keine .Net-UI-Bibliothek, einschließlich WinUI, erforderlich, um ein MVVM-Framework zu unterstützen. Es muss nur Objekte unterstützen, die UI-Elemente darstellen. Ein .Net MVVM oder reaktives Framework ist eine Möglichkeit zum Generieren und Ändern von .Net-Objekten, die die Benutzeroberfläche darstellen, basierend auf Objekten, die Daten darstellen. Keiner muss vom anderen wissen. Jedes Framework kann mit jeder UI-Bibliothek kombiniert werden.

Es besteht jedoch keine Notwendigkeit für eine .Net-UI-Bibliothek, einschließlich WinUI, um ein MVVM-Framework zu unterstützen.

Aber Dinge wie Ereignisse und Schnittstellen, die UIElements kennen, sind notwendig und das ist es, was kaputt gegangen ist.

Von: Charles Roddie [email protected]
Gesendet: Mittwoch, 25. März 2020 14:28:46
An: microsoft/microsoft-ui-xaml [email protected]
Cc: Der scharfe Ninja [email protected] ; Erwähnen Sie Erwä[email protected]
Betreff: Re: [microsoft/microsoft-ui-xaml] WinUI 3.0 Entwicklererfahrung und Tools - Eingabe erforderlich (#1045)

@terrycox https://github.com/terrycox Die Windows-Benutzeroberfläche sollte mindestens die wichtigsten MVVM-Frameworks unterstützen – MVVM Light, Prism und Caliburn. ... dein dokumentiertes Problem

Ja, es sollte dokumentierte Probleme beheben, aber es ist keine .Net-UI-Bibliothek, einschließlich WinUI, erforderlich, um ein MVVM-Framework zu unterstützen. Es muss nur Objekte unterstützen, die UI-Elemente darstellen. Ein .Net MVVM oder reaktives Framework ist eine Möglichkeit zum Generieren und Ändern von .Net-Objekten, die die Benutzeroberfläche darstellen, basierend auf Objekten, die Daten darstellen. Keiner muss vom anderen wissen. Jedes Framework kann mit jeder UI-Bibliothek kombiniert werden.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/1045#issuecomment-604040104 an oder melden Sie sich ab https://github.com/notifications/unsubscribe-auth/ AD3GCLASFGPUSCRG5PFKOOTRJJLO5ANCNFSM4ICOLUJQ .

Dotnet cli-Tooling sollte zusammen mit a verwendet werden. Netcore sdk.
Befehle wie dotnet new und dotnet build sollten ausreichen, keine harte Abhängigkeit von der Installation von Visual Studio. Bitte treten Sie vollständig der .Net Core-Ära bei!

• Es ist gut, wenn der xaml-Designer schnell ist. Der aktuelle XAML-Designer ist langsam und gibt immer einen Fehler aus, der besagt, dass eine Ausnahme aufgetreten ist und nicht funktioniert. Bitte korrigieren Sie das und stellen Sie einen robusten Designer bereit.

• Derzeit hat uwp keine APIs, die den Sperrbildschirm erkennen können. Es ist gut, wenn uns APIs zur Verfügung gestellt werden, die Sperrbildschirme erkennen und boolesche Werte als Rückgabewerte liefern. Wir sollten auch in der Lage sein, nach dem Sperren oder Entsperren einige Animationen und Abzeichen anzuzeigen.
  - Vorhandene Lockscreen-API

• Mein Problem erklärt

Gibt es in @JensNordenbros Kommentar eine Chance, dass dies nur mit Vs Code funktioniert?

Ich möchte eine Anwendungsvorlage sehen, die eine .NET 5-Anwendung mit WinUI 3.0-Benutzeroberfläche erstellt, die auf eine .NET 5-Store-Hostanwendung verweist. Dies würde weniger redundante Installationen von .NET 5.0 ermöglichen

Wie geht man in einer WinUI-Desktopanwendung von muxc.Window.ThisPtr zu einem hWnd zum nativen Win32-Fenster?

Ich habe gerade die neuen Mai 2020-Vorlagen für WinUI 3 Preview 1 for Desktop ausprobiert, da mir diese Idee gefällt.

Aber ich habe eine Frage. Da WinUI die native UI-Plattform unter Windows ist, bin ich überrascht über den Mangel an Kommunikation, dass es tatsächlich auch Teil von Windows 10 ist?

Meine resultierende Hello World-App war etwa 120 MB groß. Klar, Platz ist billig, aber ich hatte hier keine eigenen Abhängigkeiten. Davon verbrauchte WinUI eine beträchtliche Menge an Speicherplatz, etwa so viel wie das enthaltene .NET 5 selbst. Das ist allein für den x64-Build. Fügen Sie x86 in ein Multi-Plattform-Paket ein und verdoppeln Sie diese Größe. Fügen Sie einige andere Abhängigkeiten hinzu, und wir könnten uns leicht eine 300-MB-App ansehen, die für die Verteilung paketiert werden soll.

Warum ist WinUI 3 nicht einfach Teil der Windows-Edition von .NET 5? Ist es Teil der .NET Core-Modularisierungsbemühungen? Aber wenn nicht, wo ist der Platz dafür? Wirklich im Ordner jeder App? Als offizielle Windows 10-Benutzeroberfläche...?

Oder wird es in Zukunft Teil von Windows 10 sein? Wenn WinUI eher wie eine Systembibliothek behandelt würde und .NET 5 später mit Windows ausgeliefert wird, würden wir uns stattdessen vergleichsweise kleine Apps ansehen. Aber hoffentlich ist das zumindest für Windows 10X und vielleicht später auch für Windows 10 non-X genau so? Ohne diese beiden Bibliotheken sowie die Windows 10 SDK C#/WinRT-Bridge-DLL sinkt die App-Größe auf 1-5 MB.

@ryandemopoulos hat auf Discord gesagt, dass WinUI als Framework-Paket geliefert wird, sodass Apps, die den Store oder MSIX zur Verteilung verwenden, keine eigene Version von WinUI tragen müssen, da alle dieselbe Kopie davon teilen.

WinUI zu einem Teil von Windows selbst zu machen, würde die Entkopplung von WinUI vom Betriebssystem zunichte machen.

„Zuverlässig verfügbar und nicht in der Größe der App“ ist das Anliegen. Ich würde hoffen, dass .NET 5 ähnlich verteilt wird.

@lmcdougald Ich lade Sie ein, ein Problem im .NET Core Installer zu öffnen und zu bitten, dass .NET 5 auch Framework-Packaging für die Wartung verwendet.

@jonasnordlund es gibt eine weitere Diskussion #2500, in der es um die Bereitstellung von WinRT Runtime geht. Vielleicht findest du dort eine Antwort. :)

@marb2000 Ich habe ein Problem eröffnet, bin aber ehrlich gesagt ratlos. Wird dies nicht als wesentlich für eine App angesehen, die Windows 10X bereitstellen würde?

Hier ist eine Zusammenstellung mehrerer Funktionen, von denen einige nicht direkt WinUI sind, deren Fehlen sich jedoch direkt auf die Erfahrung der .NET-Cliententwicklung auswirkt - einschließlich UWP-Clients und insbesondere LoB-App-Clients.

• Für mich hat in erster Linie oberste Priorität, dass Sie die Uno-Plattform pflegen. Für mich ist es das, was UWP relevant macht, ich hätte bei XF oder einer anderen Technologie Kompromisse gemacht, wenn Uno nicht da wäre. (https://github.com/microsoft/microsoft-ui-xaml/issues/2024)
• Abstrakte clientseitige Identitätsverwaltungs-API zur Verwendung von ViewModel (https://github.com/microsoft/ProjectReunion/issues/31)
• Vollständige Unterstützung für Datenanmerkungen, Validierungen und UI-Titel, Stringlängen, erforderliche Attribute, schreibgeschützte Felder, Wasserzeichen usw. usw. usw. (https://bit.ly/3gcMJ3a)
• Verbessern Sie OData, damit es zu einer echten Alternative zu den früheren RIA-Diensten wird. Zum Beispiel: Unterstützung der Attributgenerierung, Schnittstellenimplementierungen, generische Typen, XML-Dokumente (https://github.com/OData/odata.net/issues/1746)
• Bringen Sie alle fehlenden Funktionen von WPF ein
• x:Bind sollte auch alle Funktionen haben, die Binding hat, wie Bereiche oder verschachtelte Bindungen (https://github.com/microsoft/microsoft-ui-xaml/issues/2237)
• Hot-Restart (https://github.com/microsoft/ProjectReunion/issues/44)
• Mehr als einfache Hello World-Vorlagen. Solche, die für Benutzeranmeldung, MVVM, Routing, x-plat-Projekte (wie Uno-Plattform) usw. geeignet sind. Mit anderen Worten, bitte geben Sie WTS mehr Leistung.
• XAML WYSIWYG-Editor Layoutfunktionen wie in WinForms, wie Andocken, Abstände etc. - dies scheint abgeschlossen zu sein! ❤

Danke für deine Zusammenstellung @weitzhandler , sehr praktisch.

Das WinUI-Team hat eine großartige Beziehung zum Uno-Produktteam (nicht von Microsoft), zum Xamarin Forms/MAUI-Team und zu React Native. Wir arbeiten aktiv mit ihnen zusammen und wünschen ihnen eine erfolgreiche Zukunft.

Zu den fehlenden WPF-Features, können Sie bitte Ihre Top-Features auflisten? Die Lücke zwischen WPF und WinUI zu schließen, ist eines unserer Ziele. Es wird jedoch mehrere Veröffentlichungen dauern.

Apropos komplexere Vorlagen. Das Window Template Studio hat diese Mission.

Ich habe ein Problem gemacht, um zu versuchen, Bereiche zu sammeln, in denen WinUI im Vergleich zu WPF #719 @weitzhandler @marb2000 fehlt

Apropos komplexere Vorlagen. Das Window Template Studio hat diese Mission.

@marb2000 könnten wir Window Template Studio in unseren VSIX integrieren? Oder vielleicht umgekehrt? Verwenden Sie Window Template Studio einfach als Vehikel für den Versand aller WinUI3- (und Project Reunion)-Vorlagen in Zukunft?

Apropos komplexere Vorlagen. Das Window Template Studio hat diese Mission.

@marb2000 könnten wir Window Template Studio in unseren VSIX integrieren? Oder vielleicht umgekehrt? Verwenden Sie Window Template Studio einfach als Vehikel für den Versand aller WinUI3- (und Project Reunion)-Vorlagen in Zukunft?

@crutkas @sibille

Ich schlage vor, einige Zeit mit C++ Builder (VCL/FMX) und Qt Creator/Design Studio zu verbringen, um zu lernen, was mit C++ und modernen Tools möglich ist.

Idealerweise bietet WinUI ähnliche Tools wie diese Produkte bereits heute für in C++ geschriebene plattformübergreifende GUIs.

Was mir wichtig ist, ist die .NET-Entwicklungserfahrung und eine ähnliche Erfahrung für die Anwendungsfälle, die ich gezwungen bin, C++ zu verwenden, die uns aus irgendeinem Grund nicht zur Verfügung gestellt werden.

C++ Builder und QtCreator verfügen über eine solche Erfahrung, und es wäre zu begrüßen, wenn .NET-Entwickler sich wie zu Hause fühlen könnten, wenn sie ein paar Tage damit verbringen müssen, C++/WinRT-Code zu schreiben.

Warum machen Sie das über .NET-Entwickler? Die C++-XAML-Erfahrung ist einfach schlecht, egal ob Sie ein C++- oder .NET-Entwickler sind.

Ich glaube, dass es großartig sein wird, wenn sie den Weg frei machen, um die gleiche XAML-Ausführung auf Desktop, Web (Edge), Mobile und IoT zu ermöglichen.

Wann können wir WinUI 3 in einem C++-Projekt ohne C#, Xaml oder Designer verwenden?
Gibt es auch Neuigkeiten zum Datum des Open Sourcing des c++-Kerns von WinUI 3?

Bearbeiten: Ich glaube, ich habe eine Antwort auf meine erste Frage erhalten, es sieht so aus, als ob es in WinUI 3.0 Preview 1 eine c++ WinUI 3-Projektvorlage gibt :

Nach der Installation der .vsix-Erweiterung können Sie ein neues WinUI 3.0-Projekt erstellen, indem Sie nach "WinUI" suchen und eine der verfügbaren C#- oder C++-Vorlagen auswählen.

Der Anwendungsfall, den ich gerne verbessern würde, ist der der Entwicklung kleiner GUI-basierter Tools für IT-Support-Mitarbeiter an vorderster Front, die oft in PowerShell geschrieben sind. Es wäre großartig, diese Art von Tools in Visual Studio Code erstellen zu können. Sogar eine C#-basierte VSCode-Entwicklungsoption wäre ein großartiger Schritt. Ausgewachsenes Visual Studio fühlt sich für diesen Fall ziemlich schwer und komplex an.

Derzeit verwenden Unternehmensumgebungen stattdessen Tools wie diese:

• https://poshgui.com/ (webbasierter XAML-Assistent)
• Sapien PowerShell Studio 2020 (proprietär)
• Admin Script Editor (ASE) (ein inzwischen aufgegebenes Projekt)

Andere häufig verwendete "Visual Studio für XAML verwenden"-Muster werden hier beschrieben:

• Erstellen Sie eine einfache grafische Oberfläche für ein PowerShell-Skript
• So erstellen Sie eine PowerShell-GUI für Ihre Skripte

Meine Frage steht im Zusammenhang mit der @mqudsi- Frage, die er im Mai gestellt hat, aber niemand hat geantwortet.

In a WinUI desktop application, how does one go from muxc.Window.ThisPtr to an hWnd to the native Win32 window?

Da dies eine Desktop-Anwendung ist, können wir ICoreWindowInterop nicht verwenden, und ich habe zufällige Swags wie new HandleRef(this, ThisPtr) ausprobiert,

Für alle Interessierten ist dies der schnelle Ansatz, den ich verwendet habe, um das hWnd für das Hauptfenster zu greifen, damit ich es randlos machen kann. Die vollständige Lösung für WPF-Äquivalent von WindowStyle = None ist hier .

using var process = Process.GetCurrentProcess();
var hWnd = process.MainWindowHandle;

Zu diesem Zeitpunkt scheint es keine leicht zu findende / dokumentierte Möglichkeit zu geben, das hWnd zu erhalten, wenn sich Ihre WinUI in einem Desktop-Prozess befindet. Deshalb habe ich mich dem von mir verwendeten Ansatz zugewandt. Scheint gut genug zu funktionieren.

Ich denke, vielleicht sollten UWP und Universal Windows als Begriffe wegfallen. Die Bedingungen tragen einige unglückliche Gepäckstücke, die Entwickler dazu bringen, sich zu scheuen.

Vielleicht könnten wir die Vorlage WinUI (Universal Windows) durch WinUI (Win64) ersetzen? Haben Sie dann die Option Desktop oder Store?

Win64 ist verwirrend - es würde bedeuten, dass die Win32-API nur 32-Bit unterstützt und UWP umgekehrt nur 64-Bit unterstützt, die beide falsch sind.

Der Name Win32 allein verwirrt bereits eine Menge Anfänger, wir brauchen Win64 nicht, um die Sache noch schlimmer zu machen.

@VagueGit Etwas, das ich gelernt habe, ist, dass die Auswahl des richtigen Namens und das Erstellen der Geschichte eines der komplizierteren Dinge ist. Besser als einen Namen zu ersetzen, sollten wir (Microsoft) das richtige Produkt (und die richtige Geschichte) liefern, um Ihnen zum Erfolg zu verhelfen. UWP ist eine bekannte Terminologie wie Win32, daher sollten wir sie weiterhin verwenden.

Dies ist unser Ansatz (sehr vereinfacht):

WinUI kann in zwei "Typen" von Apps verwendet werden, die auf verschiedene Geräte abzielen:

• Ihre App zielt auf viele Geräte mit vielen Eingaben und Formfaktoren ab. Verwenden Sie dann UWP. Dafür wurde UWP erstellt; Daher müssen Sie Anforderungen wie Verpackungsmodell, Lager, Anwendungsmodell, Sicherheitsbehälter usw. erfüllen.
• Ihre App ist nur auf Desktop ausgerichtet und erfordert vollen Zugriff auf das Betriebssystem. Verwenden Sie Win32 oder Desktop (so ruft Visual Studio WPF, WinForms, MFC, Apps auf).

WinUI in UWP- Apps und

@ marb2000 Die Benennung von Dingen ist schwer, zugestimmt. Aber manche Namen sind leider giftig und sollten auf der Strecke bleiben. Aus diesem Grund werden Produkte von Zeit zu Zeit umbenannt. UWP ist eine, aber das ist nur meine Ansicht ... und alle, mit denen ich spreche. Aber los gehts.

Wir haben eine UWP-App, die wir zu WinUI migrieren möchten. Wir verwenden keine Win32-API, wir zielen nur auf den Desktop und möchten nicht den Store verwenden. Wie passt das?

@ marb2000 Die Benennung von Dingen ist schwer, zugestimmt. Aber manche Namen sind leider giftig und sollten auf der Strecke bleiben. Aus diesem Grund werden Produkte von Zeit zu Zeit umbenannt. UWP ist eine, aber das ist nur meine Ansicht ... und alle, mit denen ich spreche. Aber los gehts.

Wir haben eine UWP-App, die wir zu WinUI migrieren möchten. Wir verwenden keine Win32-API, wir zielen nur auf den Desktop und möchten nicht den Store verwenden. Wie passt das?

Für wen ist die App genau?

Als Verbraucher, der UWP-Apps verwendet, werde ich sie wahrscheinlich nicht anfassen, geschweige denn sehen, wenn die App nicht im Store ist.

Keine Sorge @shaheedmalik, wir werden dich nicht bitten, es

Wir wissen also, dass es einen Markt für Win64-Business-Apps gibt, und wir glauben, dass wir zu den wenigen Business-Entwicklern gehören, die Win64-Apps bereitgestellt haben, für die Geschäftskunden bezahlen. Ich weiß, dass es ein paar Entwickler in diesem Thread gibt, die den Weg von Universal Windows / Multi-Plattform gehen, aber sie sind ziemlich selten. Die meisten Business-Entwickler zielen meiner Erfahrung nach auf einen bestimmten Formfaktor ab.

Aus der Perspektive eines Entwicklerunternehmens, das stark in UWP investiert und UWP zum Geschäftserfolg gemacht hat, vielleicht Vorlagen für WinUI (Desktop) und WinUI (Store)? Sie müssen nur den technischen Medien folgen, um eine Vorstellung davon zu bekommen, wie schlecht UWP als Entwicklungsplattform angesehen wird.

@VagueGit
"Wir haben eine UWP-App, die wir auf WinUI migrieren möchten. Wir verwenden nicht die Win32-API, wir zielen nur auf den Desktop und wollen nicht den Store verwenden. Wie passt das zusammen?"

Möchten Sie also eine UWP zu WinUI 3 migrieren und außerhalb des Stores bereitstellen? Eine naive Frage: Haben Sie den Sideload des MSIX ausprobiert ? Gibt es außer dem Store einen anderen Grund, der Sie aufhört, UWP zu verwenden?

@VagueGit
"Wir wissen also, dass es einen Markt für Win64-Business-Apps gibt."

Eine Frage, Win64 steht für vieles. zB Apps kompilieren für x64. Was bedeutet Win64 für Sie?

@marb2000 UWP bietet eine schlechte Unterstützung für die Geschäftsberichterstattung. Wir glauben, dass ein Rebranding dazu beitragen könnte, die Entwicklung von Tools von Drittanbietern wie Berichtserstellern anzukurbeln. Wir haben mit Sideloading gespielt, aber es war für uns bis 20H1 nicht machbar, da Sideloading standardmäßig nicht aktiviert war.

Wir glauben, dass Win64 der Weg nach vorne unter Windows ist. Micro$ hat in der Vergangenheit erfolglos versucht, Win32 als Vermächtnis zu präsentieren, und ist nun auf diese Position zurückgekehrt. Aber letztendlich muss Win32 unserer Meinung nach verschwinden (das sage ich nach 30 Jahren Win32-Entwicklung selbst). Wir haben es geschafft, die meisten Einschränkungen von UWP zu überwinden, um eine Geschäfts-App bereitzustellen, die Unternehmen kaufen werden. Wir befürchten, dass eine weitere Iteration von UWP ohne Rebranding nur begrenzte Wirkung haben wird.

Wie die Verwirrung von @marb2000 zeigt, wird der Begriff Win64 bereits (schlecht) verwendet. Darauf habe ich auch schon hingewiesen.

Ich stimme zu, dass ein Rebranding erforderlich sein könnte, aber Win64 ist eine schreckliche Art, dies zu tun. Bis es etwas Offizielles gibt, sollten Sie den Begriff UWP verwenden, um von allen verstanden zu werden.

@sylveon UWP wird von allen als Versager verstanden. Wir mögen es, aber nur wenige andere tun es. Deshalb ist ein Rebranding wichtig. Was halten Sie von WinUI (Deskop) oder WinUI (Store) als Projektvorlagen?

WinUI (Store) ist nicht gut, da Sie auch Win32-Apps im Store oder UWP-Apps außerhalb des Stores versenden können. WinUI (Desktop) ist jedoch gut.

@sylveon WinUI (Store) schließt andere Projekte nicht aus, die auf den Store abzielen. Es bedeutet nur, dass Sie mit den Funktionen beginnen möchten, die die Freigabe über den Store ermöglichen.

Es ist schlimm genug, um Anfänger zu verwirren.

Dies ist nicht an eine bestimmte Person in diesem Thread gerichtet, sondern eher an meine eigene Meinung als Entwickler von Desktop-Anwendungen/Unternehmensinhabern.

Ich bin nie dabei, wie etwas heißt. Mir ist nur wichtig, welche Funktionen es hat und wie gut es unterstützt wird.

Ich würde argumentieren, dass es auch viele Entwickler (mich eingeschlossen) gibt, die begeistert sind, wenn wir hier Begriffe wie MAUI verwenden, aber sofort enttäuscht sind, wenn wir feststellen, dass es immer noch die gleiche Codebasis ist. Das Rebranding deutet darauf hin, dass „hey, wir bauen dieses brandneue Ding, das von einer Codebasis ausgeht, die völlig anders ist als die, die Sie von xyz blockiert hat“. Was ich LIEBE zu sehen ist, ist eine riesige Liste von Funktionen, die geändert haben, welche Kämpfe ich oder jemand anderes hatte.

Plattformen entwickeln sich im Laufe der Zeit wie jedes Produkt oder jede Marke. Ich finde Trost in Marken und Namen, die es seit Jahrzehnten gibt, weil es automatisch LTS impliziert. Obwohl mir bewusst ist, dass Namensänderungen manchmal eine Notwendigkeit sind, erinnern sie Entwickler auch an die Aufgabe (Silverlight). Es gibt viele Automodelle, die jahrelang von Problemen geplagt wurden, aber am Ende zu beliebten und angesehenen Marken wurden. Es gibt viel mit Vertrautheit zu sagen, auch wenn Ihnen die bisherigen Erfahrungen nicht gefallen, denn Sie wissen, was Sie erwartet. Solange Probleme gelöst werden, zählt das wirklich.

Ich denke, es gibt mindestens zwei Zielgruppen, die berücksichtigt werden müssen; Entwickler und Endproduktanwender. Wenn ich als Entwickler/Geschäftsinhaber einen Kunden habe, der eine Anwendung benötigt und er von den zugrunde liegenden Technologienamen verunsichert wurde, ist es meine Aufgabe, ihm das Vertrauen zu vermitteln, dass das durch den Namen repräsentierte Produkt ausgereift ist und was ihn in Bezug auf die Vergangenheit wurde aktualisiert. Auf der anderen Seite, wenn ich sage „Schau, da ist dieses neue großartige Ding namens WinUI oder MAUI“ und sie besitzen bereits WPF- oder UWP- oder Xamarin-Produkte, die wir für sie entwickelt haben, ist eine absehbare Reaktion von ihnen „Oh großartig, jetzt unsere Apps“. sind in 2,3 oder 4 verschiedenen Technologien geschrieben“. Hier muss ich sie dann verkaufen. Da alle Kunden unterschiedlich sind, werde ich auf Ablehnung stoßen, ob Sie den Namen unverändert lassen oder ändern.

Was am Ende (für mich) wichtig ist, ist, dass wir die Tools haben, die wir brauchen, um ansprechende, funktionsreiche Anwendungen mit LTS zu schreiben. Ich bin begeistert, wenn ich sehe, dass ein Produkt die Fristen erreicht, und ich kann die neue Funktion und die Liste der Problemlösungen lesen, wenn das Produkt veröffentlicht wird. Ich liebe das seit 2016 an NetCore/Net5 (Namensänderung LOL).

Im Moment möchte ich nur bis zu einem Punkt vorspulen, an dem ich eine Desktopanwendung mit XAML-Dialekt schreiben und die gleiche Renderingleistung erzielen kann, die UWP/WinUI bietet (ohne die UWP-Sandbox). Aus diesem Grund und aufgrund der ausgefallenen September-Vorschau werde ich mit dem Testfahren von Avalonia beginnen. Ich liebe die WPF-Ähnlichkeiten, während ich von der Rendering-Leistung über SkiaSharp höre.

Spannend wird es in ein paar Jahren, wenn sich die Optionen für die UI-Entwicklung stabilisiert haben. Sie können Projektvorlagen beliebig benennen, das ändert nichts an meiner Meinung über die fehlenden Funktionen.

Ich schätze Sie alle.

Ich verstehe, was jtbrower in seiner E-Mail sagt. Sein Unternehmen wie unseres ist eines der wenigen, das den xaml-Weg erfolgreich beschritten hat. Wir müssen nicht von den Vorteilen überzeugt sein.

Aber so gut es auch sein mag, xaml war eine Katastrophe für Micro$. Die Entwickler blieben überwiegend entweder bei WinForms oder wechselten vollständig zur Webentwicklung. Seit UWP hat sich der Exodus der Entwickler verschlimmert.

Damit xaml-Technologien nachhaltig sind, muss Micro$ die Millionen von Entwicklern gewinnen, die sie nicht an Bord geholt haben. Für diese Entwickler, Tool-Anbieter und die Tech-Medien ist UWP eine Sackgasse. Eine weitere Iteration von UWP wird sie nicht überzeugen.

@VagueGit, aber Entwickler sind daran interessiert, ein umbenanntes Produkt als dasselbe zu kennen. Sie kennen MAUI als umbenanntes Xamarin Forms. Tatsächlich scheinen sie so weit zu gehen, dass MAUI ein gestohlener Name war. Ich glaube nicht, dass man einen typischen Entwickler mit einer Namensänderung motivieren kann. Wir alle wollen Funktionen, nicht wahr? Würden Sie nicht lieber sehen, dass UWP mehrere Windows oder volle Vertrauenswürdigkeit zulässt? Wenn sie beides tun würden, könnten wir alle auf UWP abzielen und vielleicht die Sandbox für Store-Apps behalten. Ich träume gerade laut, was mich wirklich begeistern würde! Merkmale!!

Stimme dir absolut zu jtbrower. Ich schätze auch, dass Sie mir helfen, und ich hoffe, dass andere ihre Ideen kritisieren. Aber wie kann man Entwicklern und Tool-Anbietern signalisieren, dass es zwei verschiedene UWPs gibt, Store und Desktop?

Wer also den UWP-Pfad weitergehen möchte, kann mit dem UWP Store-Template beginnen, aber diejenigen, die einen 64-Bit-Desktop, keine Sandbox und volles Vertrauen wünschen ... nun, das ist nicht UWP, oder?

UWP wird auf dem Markt als verkrüppelt angesehen. Alle außer uns Hartnäckigen gaben UWP auf, als Micro$ selbst sich von der Entwicklung eigener Apps in UWP zurückzog.

Der Entwicklermarkt achtet nicht auf Entwicklungen in UWP. 64-Bit-Desktop, kein Sandkasten und volle Vertrauenswürdigkeit, ist viel mehr als eine Namensänderung; es ist ein anderes Paradigma. Aber wenn es immer noch UWP heißt, wird es von denen, die UWP abgeschrieben haben, nicht bemerkt.

@VagueGit Ich freue mich, dass Sie mit UWP Erfolg haben. Die Benennung ist schwer, und die Tatsache, dass wir es die "Universelle Windows-Plattform" nennen und es von der überwiegenden Mehrheit der Windows-Entwickler nicht wirklich haltbar ist, macht es, nun ja, nicht sehr "universal". Eine genaue Zusammenfassung von Project Reunion besteht darin, dies zu beheben und jeden Aspekt von UWP für alle Windows-Entwickler wirklich zugänglich zu machen.

Ich stimme zu, dass UWP einen schlechten Ruf hat. Wenn Sie den Ausdruck "UWP is" in eine Suchmaschine eingeben, lautet der erste automatische Vorschlag, den Bing oder Google Ihnen gibt, "UWP is dead". Ich denke jedoch, dass @marb2000 richtig ist, dass wir den Namen trotz des Gepäcks, das er trägt, weiterhin verwenden sollten.

Damit ist gesagt...

Heute können viele Aspekte der Desktop-Projekte verschiedene Teile dessen verwenden, was wir früher als "UWP" definiert haben:

1. Der UI-Stack (auch bekannt als WinUI3)
2. MSIX-Verpackung
3. MRT-Ressourcen

Sobald CoreApplication aufgehoben ist, besteht der einzige Unterschied zwischen UWP und Desktop wirklich darin, welches Sandbox-Modell Sie für Ihre Anwendung auswählen und welche Geräte Sie als Ziel verwenden können.

Wir haben besprochen, Änderungen an den Projektvorlagen vorzunehmen und eine assistentenähnliche Erfahrung zu haben, die dies genauer beschreibt.

@JeanRoca ist der PM, der das antreibt und hat möglicherweise weitere Informationen, die er teilen kann

Ich mag die Idee der WinUI Desktop-Vorlage. Geeigneter als Win32 und zukunftsweisend. Es ist die Vorlage, mit der wir beginnen würden, während Win32 eine 32-Bit-Einschränkung vorschlug. WinUI Desktop wird hoffentlich in den Medien und bei den Entwicklern Einzug halten.

Wenn eine UWP-App außerhalb des Stores veröffentlicht wird, ist das Paket .appinstaller. Wenn wir diese App auf Win UI Desktop aktualisieren, ändert sich das Installationspaket von appinstaller zu msix.

Angenommen, wir behalten die Details innerhalb des App-Pakets bei und stoßen die Version entsprechend an. Wird Windows dann erkennen, dass es sich um eine neue Version derselben App handelt, und lokale Daten beibehalten, oder wird es als andere App installiert?

Nach meinem Verständnis wird WinUI 3.0 nie von .NET Framework <= 4.8 verwendet. Wenn wir also über WinUI sprechen, sprechen wir entweder von .NET Native oder .NET 3.1/5+ (oder einem anderen Satz von Bindungen).

Irgendwelche Vorschläge, wie man das Framework-Packaging für .NET 5 (oder ich schätze 6 zu diesem Zeitpunkt) voranbringen / weiter fragen kann? Ich habe ein Problem eröffnet und keine Antwort erhalten. Das Bündeln von .NET 5 In-App ist ein Nichtstarter.

@stevenbrix

Sobald CoreApplication aufgehoben ist, besteht der einzige Unterschied zwischen UWP und Desktop wirklich darin, welches Sandbox-Modell Sie für Ihre Anwendung auswählen und welche Geräte Sie als Ziel verwenden können.

Ein weiterer großer Unterschied besteht leider darin, dass .NET-Entwickler gezwungen sind, für APIs wie DirectX auf C++ umzusteigen, deren Team sich eindeutig weigert, sie UWP-kompatibel zu machen, obwohl sie COM-basiert sind.

Und dabei zurück zu den Produktivitätstagen des manuellen Schreibens von MIDL mit einer netten Notepad-ähnlichen Erfahrung und des Herumkopierens von Dateien, anscheinend kann das Windows-Team die ATL-ähnliche Entwicklungserfahrung nicht loslassen, anstatt eine NET-ähnliche Erfahrung für C++-Workflows bereitzustellen. C++/CX war dem C++ Builder zu nahe gekommen, also musste es im Namen von ISO-Zeug getötet werden, damit wir sie mit etwas Glück in C++23 und 2025 in VS bekommen.

Ich bezweifle, dass sich bis dahin irgendjemand für UWP interessieren wird, es sei denn, es wird eine angemessene Entwicklungserfahrung geschaffen, um all diese Fehlverhalten zu beseitigen.

Außerdem werfen uns GitHub-Probleme in Bezug darauf, welchem ​​Team Feedback gegeben werden soll, eine sehr schnelle Möglichkeit, das Interesse zu verlieren. Ich kümmere mich anscheinend einfach zu sehr darum.

Die DirectX-APIs können aus Gründen der WinRT-Kompatibilität nicht geändert werden, da dies eine erhebliche API-Unterbrechung für bestehende Verbraucher bedeuten würde, und das kann einfach nicht passieren.

Für DirectX stehen mehrere verwaltete Wrapper zur Verfügung, wie TerraFX, das eine rohe 1:1-Bindung ist, oder Vortice , ein API-Wrapper im C#-Stil.

CX musste weg. Compilerspezifische Spracherweiterungen sind schlecht und verpönt. Es behindert die Code-Portabilität erheblich, hinkt in Bezug auf die C++-Standardunterstützung oft hinterher und erfordert eine vollständige vertikale Integration bestehender Bibliotheken. Die Alternative, WRL, war sehr schwierig zu verwenden und zu ausführlich. Daher überrascht es nicht, dass viele Leute (einschließlich der DX-Abteilung) keine WinRT-APIs schreiben wollten.

C++/WinRT ist eine viel bessere Lösung, es ist bedauerlich, dass es IDL zurückbringen musste (aber derzeit ein notwendiges Übel). Das C++-Team hat bei der Standardunterstützung viel bessere Arbeit geleistet als zuvor, daher wäre es nicht verwunderlich, wenn wir tatsächlich Metaklassen erhalten würden, bevor C++23 fertiggestellt ist, was die UX der Entwickler radikal verbessern sollte.

@silveon

Seien Sie nicht überrascht, dass die Windows-Entwickler-Community alles ignoriert, was aus Redmond mit einer solchen Begründung für den Produktivitätsverlust kommt.

Dasselbe geschah mit CX... es wurde weitgehend ungenutzt, weil C++-Entwickler keine proprietären Spracherweiterungen mögen.

Angenommen, wir behalten die Details innerhalb des App-Pakets bei und stoßen die Version entsprechend an. Wird Windows dann erkennen, dass es sich um eine neue Version derselben App handelt, und lokale Daten beibehalten, oder wird es als andere App installiert?

@VagueGit , das ist eine großartige Frage. Letztendlich ist die Technik zum Installieren von UWP- und Desktop-Apps dieselbe. Ich habe das Gefühl, die Antwort lautet ja? Ich denke, seit neueren SDKs haben sogar UWP-Apps die Erweiterung .msix (ich könnte mich irren, also zitiere mich nicht). Ich bin sicher, Sie könnten das lokal ausprobieren und herausfinden? @adambraden für die Info.

Irgendwelche Vorschläge, wie man das Framework-Packaging für .NET 5 (oder ich schätze 6 zu diesem Zeitpunkt) voranbringen / weiter fragen kann? Ich habe ein Problem eröffnet und keine Antwort erhalten. Das Bündeln von .NET 5 In-App ist ein Nichtstarter.

@lmcdougald Ich glaube, ich weiß, auf welches Problem Sie sich beziehen (aber ich kann es nicht finden). Es wird einen geben, aber ich kann mir vorstellen, dass es im .net6-Zeitrahmen sein wird. Jeder ist sich bewusst, dass dies etwas getan werden muss.

Und dabei zurück zu den Produktivitätstagen des manuellen Schreibens von MIDL mit einer netten Notepad-ähnlichen Erfahrung und des Herumkopierens von Dateien, anscheinend kann das Windows-Team die ATL-ähnliche Entwicklungserfahrung nicht loslassen, anstatt eine NET-ähnliche Erfahrung für C++-Workflows bereitzustellen. C++/CX war dem C++ Builder zu nahe gekommen, also musste es im Namen von ISO-Zeug getötet werden, damit wir sie mit etwas Glück in C++23 und 2025 in VS bekommen.

Außerdem werfen uns GitHub-Probleme in Bezug darauf, welchem ​​Team Feedback gegeben werden soll, eine sehr schnelle Möglichkeit, das Interesse zu verlieren. Ich kümmere mich anscheinend einfach zu sehr darum.

@pjmlp Ich schätze deine Ehrlichkeit und Leidenschaft. Ich kann nicht mehr zustimmen, dass die aktuelle C++-Erfahrung unterdurchschnittlich ist. Wir haben einiges getan, um die C++-Erfahrung eher wie .NET zu gestalten, aber wie @sylveon erwähnte, haben sie ihren Preis. Schließlich haben wir beschlossen, dass wir, wenn wir technischen Aufwand darauf verwenden wollen, C++ großartig zu machen, dies in die Verbreitung des C++-Standards stecken sollten. Es ist bedauerlich, dass Metaklassen ein Ausweg sind und wir diskutieren Möglichkeiten, die Erfahrung in der Zwischenzeit zu verbessern, denn ich stimme Ihnen zu, dass wir nicht so lange warten können.

Vielen Dank für die Antwort – ich bin zufrieden mit „jeder ist sich bewusst, dass dies etwas getan werden muss“ und ich werde ein Jahr oder so mit einer überhöhten Binärdatei leben.

@stevenbrix und @VagueGit - Sie sollten weiterhin eine Appinstaller-Datei für Ihre msix-Pakete verwenden können. die appinstaller-Datei ist nichts anderes als eine json-Datei, die die uri für Ihre Pakete bereitstellt. Da Sie Unternehmensszenarien erwähnt haben, können Sie die Appinstaller-URIs entsprechend für interne Standorte anpassen oder sie auch für den externen Zugriff ändern - alles abhängig von Ihrem CDN. In Bezug auf die Versionsverwaltung - ja für verpackte Apps, wenn die Paketidentität dieselbe ist, dann hat die Installation einer neuen Version Zugriff auf die vorhandenen App-Daten.

@stevenbrix @VagueGit Ich werde mit den Informationen antworten, die ich derzeit über die Windows Template Studio voran . Mit dieser Anwendung können Sie derzeit in unserem Assistenten eine neue WPF- oder UWP-App aus vorhandenen Vorlagen mit den gewünschten Seiten und Frameworks erstellen.

Das Ziel und der aktuelle Plan für diese Anwendung in der Zukunft besteht darin, die Entwicklungserfahrung für alle Benutzer zu vereinheitlichen und zu verbessern. Wir entwickeln derzeit Vorlagen für Desktop-Apps mit WinUI 3. Das Tracking-Problem finden Sie hier . Wir diskutieren auch, dasselbe für UWP zu tun, damit unsere Benutzer ihre Projekte zu gegebener Zeit problemlos migrieren können. Wir wissen noch nicht genau, wie das funktionieren wird, aber unser Ziel wird es sein, die Erfahrung so weit wie möglich zu vereinheitlichen und zu vereinfachen. Ich hoffe, das hilft!

Dasselbe geschah mit CX... es wurde weitgehend ungenutzt, weil C++-Entwickler keine proprietären Spracherweiterungen mögen.

Sie lieben sie auf Clang, GCC, Intel. xlCC, PGI, CUDA, C++ Builder und die Fülle von Embedded-Plattformen.

Offensichtlich wurde CX aufgrund einer Politik getötet, die eine C++-RAD-Umgebung von Microsoft nicht akzeptieren kann und stattdessen alle MDIL/ATL mit einer Notepad-ähnlichen Erfahrung ausführen lässt.

Ich vermeide sie um jeden Preis, egal welcher Compiler. Vor allem, wenn die proprietäre Erweiterung für sich allein eine völlig andere Sprache ist.

Ich vermeide sie um jeden Preis, egal welcher Compiler. Vor allem, wenn die proprietäre Erweiterung für sich allein eine völlig andere Sprache ist.

Warum dann gegen eine proprietäre Benutzeroberfläche wie WinUI programmieren, stattdessen einfach offene Standards wie X Windows verwenden.

... als ob das unter Windows nutzbar wäre. Ich vermeide Compiler-Erweiterungen, weil ich Multitarget-Compiler (Clang und MSVC) für die Validierung der Standards-Compliance verwenden und neuere C++-Standards verwenden möchte.

Mein Code verwendet C++20. Viele Spracherweiterungen haben keine C++17-Unterstützung oder haben sie sehr spät bekommen. Diese Situation wird sich mit C++20 wiederholen (oder sich verschlimmern, da C++20 viel mehr neue Sachen enthält als 17). Wenn Sie beispielsweise C++20 ( /std:c++latest ) und CX ( /ZW ) nicht mischen können, erhalten Sie einen Compilerfehler, der besagt, dass die beiden Schalter nicht kompatibel sind.

Es dauerte bis zu diesem Jahr, bis NVCC geräteseitiges C++17 unterstützte. Kein gutes Aussehen.

Ich möchte mich nicht in eine Ecke drängen, in der die von mir verwendete Spracherweiterung mit einem neueren Standard nicht verwendbar ist, aber ich brauche auch ein neues Standard-Feature.

Aus den oben genannten Gründen vermeide ich sie. Wenn wir die WinUI C++-Entwicklererfahrung auf eine Spracherweiterung zurückführen, gehe ich zu einem alternativen GUI-Framework über.

@sylveon Ihr perfekt tragbares C++20 für WinUI ist außerhalb von Windows völlig nutzlos, viel Spaß mit Qt auch ohne Erweiterungen.

Weil für C++-Desktop-Benutzer nichts anderes übrig bleibt, das es wert ist, verwendet zu werden.

Danke für die Bestätigung, dass CX durch sinnlose Politik getötet wurde.

Vorschlag, freundlich zueinander zu sein. Ich kann die technischen C++-Argumente nicht kommentieren und werde nicht beurteilen, wer Recht hat.
Der Punkt ist, dass Sätze wie go have fun with X hier keine freundliche und kollaborative Atmosphäre schaffen. @stevenbrix und andere treten bei Bedarf ein.

Danke @hansmbakker ☺️

@pjmm und @sylveon Ich schätze das leidenschaftliche und ehrliche Gespräch, es ist toll, Kunden wie dich zu haben, die sich interessieren.

Beide Punkte sind äußerst gültig, und ich denke, die Welt ist groß genug, damit Sie beide Recht haben.

@pjmlp wir sind mit der aktuellen Erfahrung für c++ nicht zufrieden und erkennen, dass wir vor den c++-Metaklassen etwas tun müssen. Wir hatten einige Diskussionen über idl-freies c++/winrt, und @kennykerr und @Scottj1s haben einen Build-Talk darüber geführt. Die meisten Probleme, die wir hatten, bezogen sich auf die Integration mit WinUI, da unser Compiler Metadaten benötigt. Wir möchten diesen Workflow überdenken, um zu sehen, ob wir eine zusammenhängende Geschichte haben können, die das gesamte Entwicklererlebnis verbessert. Anstatt C++/Cx zurückzubringen, würde Sie eine IDL-freie Version von c++/winrt interessieren?

Nur um Erwartungen zu wecken, würde ich hier im Jahr 2020 keine großen Fortschritte erwarten.

Ich wäre sehr an einem IDL-freien C++/WinRT interessiert.

Die IDE-Erfahrung ist auch nicht die beste. Beispielsweise können wir im XAML-Editor keinen Ereignisrückruf wie mit C# erstellen (das Dropdown-Menü Neuen Rückruf erstellen tut nichts). Das Navigieren zur Definition aus dem XAML-Editor funktioniert ebenfalls nicht.

Andere Probleme damit sind die verschiedenen XAML-Compiler-Bugs, die ich in diesem Repository ausgefüllt habe, was dazu führt, dass ich Problemumgehungen benötige, die in anderen unterstützten Sprachen nicht erforderlich sind.

@stevenbrix , ich möchte meine Stimme dem IDL-freien C++/WinRT hinzufügen (und möchte sicherlich keine Rückkehr zu C++/CX sehen). Wir schreiben plattformübergreifende Software und kompilieren sowohl mit MSVC als auch mit LLVM (auch unter Windows), daher ist uns standardkonformes C++ sehr wichtig.

@stevenbrix ,

@pjmlp wir sind mit der aktuellen Erfahrung für c++ nicht zufrieden und erkennen, dass wir vor den c++-Metaklassen etwas tun müssen. Wir hatten einige Diskussionen über idl-freies c++/winrt, und @kennykerr und @Scottj1s haben einen Build-Talk darüber geführt. Die meisten Probleme, die wir hatten, bezogen sich auf die Integration mit WinUI, da unser Compiler Metadaten benötigt. Wir möchten diesen Workflow überdenken, um zu sehen, ob wir eine zusammenhängende Geschichte haben können, die das gesamte Entwicklererlebnis verbessert. Anstatt C++/Cx zurückzubringen, würde Sie eine IDL-freie Version von c++/winrt interessieren?

Nur um Erwartungen zu wecken, würde ich hier im Jahr 2020 keine großen Fortschritte erwarten.

Was nur zeigt, wie schlecht diese ganze Idee mit C++/WinRT von Anfang an war, sie auf uns herunterzufahren, ohne Rücksicht auf unseren Produktivitätsverlust.

Um dies in die richtige Perspektive zu rücken, langjähriger Entwickler, dessen Erfahrung als Windows-Entwickler bis auf Windows 3.0 zurückreicht, und heutzutage ist C++ hauptsächlich für die Verwendung neben .NET-basierten Anwendungen relevant, niemals allein.

Borland-Tools waren mein Brot und Butter, bis aus verschiedenen Gründen, die Windows-Entwicklern der alten Zeit bekannt waren, der Weg nach vorne in der Migration auf Microsoft-Compiler endete.

Visual C++ war nie _Visual_ als C++ Builder, nicht einmal mit C++/CLI, da es keine Integration mit Forms und AOT-Kompilierung gibt.

C++/CX schien es Microsoft endlich geschafft zu haben, 25 Jahre später erhielten wir die gleichen Produktivitätsworkflows wie bei der gleichzeitigen Verwendung von Delphi/C++ Builder.

Stattdessen haben wir das, was wir als politischen Schritt bekommen haben, um C++/CX zu töten, ohne Rücksicht auf unsere Produktivität zu nehmen, indem wir die Verantwortung für die fehlenden Funktionen zu ISO C++ und WG 21 schwenken, als ob alles, was das Visual C++-Team uns wegnimmt, sein wird akzeptiert von WG 21.

Und selbst wenn die notwendigen Funktionen irgendwann von ISO C++ übernommen werden, werden es 2023, 2026, ... sein? Und dann ist da der springende Punkt, wann diese Funktionen tatsächlich Windows-Entwicklern zur Verfügung gestellt werden. Schauen Sie sich nur die Modulunterstützung an. Wir brauchen endlose Jahre, um die Gleichheit mit dem zu erreichen, was C++/CX uns seit der Veröffentlichung von Windows 8 im Jahr 2012 bietet.

Angesichts der Tatsache, dass wir bis 2020 keine Verbesserungen sehen werden, sprechen wir hier bereits über 9 Jahre um mit UWP-Fehlern, Reunion, .NET-Ökosystem-Neustart umzugehen, während wir aufgefordert werden, zu programmieren, als wäre es 2000 mit nackter MIDL-Notepad-Erfahrung und endloser Vorlagensuppe wie ATL.

Also ja, entweder eine IDL-freie C++/WinRT-Version oder zumindest eine IDL-Erfahrung mit voller Intellisense/Intelicode-Unterstützung und ohne manuelles Kopieren von Dateien. Das nimmt jedoch nicht die ATL-ähnliche Erfahrung aus dem C++-Code selbst.

Aus Sicht der .NET/C++-Entwicklung interessiert mich nicht die Zeitreise in die Vergangenheit von Microsoft-Frameworks, sondern wie es aussehen könnte, wenn die C++-RAD-Sicht ernster genommen würde, leider mit der Art und Weise, wie die C++/ Die WinRT-Geschichte wurde verwaltet, und alles andere, was jetzt mit dem Zurücktreten von UWP passiert, frage ich mich, wo "Entwickler, Entwickler, Entwickler" geblieben sind.

Es tut mir also leid, wenn es sich immer noch ein bisschen albern anfühlt, aber so empfinde ich meinen Produktivitätsverlust, wenn ich von .NET zu C++ wechseln muss, im Namen einer gewissen ISO-Reinheit, die die meisten C++-Compiler sowieso nicht tun.

C++ ist immer noch eigenständig relevant. Viele Anwendungen werden in rohem C++ geschrieben, ohne dass verwalteter Code ausgeführt wird. Tatsächlich ist die gesamte UWP-Laufzeit und das XAML/WinUI-Framework natives C++. Eine in C++ geschriebene UWP-App hat (zum Glück) keine verwaltete Sprache.

Ich würde argumentieren, dass Sie sich fragen sollten, warum , wenn Sie das Bedürfnis haben, in .NET auf C++ umzusteigen, und versuchen, diese Probleme direkt in .NET anzugehen. Leistung? Verwenden Sie die Span-Typen, Stackalloc und die intrinsischen Vektoren. DirectX, native APIs oder COM? Verwenden Sie eine Bindung wie TerraFX. Interagieren mit einer reinen C++-Bibliothek? Implementieren Sie das, was Sie daraus benötigen, in .NET neu.

.NET ist ohne C++ besser dran und C++ ist ohne .NET besser dran.

Ich denke nicht, dass das Templating in cppwinrt so schlecht ist. Was mich am meisten ärgert, ist die Notwendigkeit der Codegenerierung und die schreckliche Kompilierzeit, die dadurch entsteht.

@sylveon Easy, aufgrund der APIs, die das Windows-Team sich weigert, als UWP zur Verfügung zu stellen und keine Bindungen von Drittanbietern zählen, ist nicht jeder mit einer Rechtsabteilung gesegnet, die alles loslässt, ohne Rücksicht auf Lizenz- und zukünftige Supportprobleme.

Borland (jetzt Embarcadero) und The Qt Company haben gezeigt, wie es geht, es liegt an Microsoft zu entscheiden, wie relevant sie die Plattform behalten möchten.

Versuchen Sie zu sehen, wie weit Sie mit ISO C++ in macOS-, iOS-, Android- und ChromeOS-GUIs kommen.

Wie auch immer, hier aufzuhören, ist sinnlos.

@pjmlp wir haben plattformübergreifende Anwendungen mit Millionen von Zeilen ISO C++, die unter iOS/macOS/Windows
Wir haben bereits C++/CLI verwendet und es ist so mühsam. Einschränkungen wie Klassenmember, die nur unformatierte C++-Zeiger zulassen, erschweren das Speichern von intelligenten Zeigern. Die Kompilierungszeit ist lang (Einzelzeichenänderungen erfordern 5 Minuten MD-Mergezeit).
C++ enthält ein erforderliches Umschließen, um das verwaltete / nicht verwaltete Pragma zu ändern
Der Compiler ist eine andere Version für C++/CLI als für C++ (und mir wurde beim Build gesagt, dass der C++/CLI-Compiler nicht später als C++17 unterstützt, was ein Problem beim Einbinden von Headern aus Bibliotheken ist, die C++ verwenden 20 Funktionen).
Was ich damit sagen will, ist, nicht mehrere konkurrierende Bemühungen zu unternehmen. Bleiben Sie beim Standard und arbeiten Sie damit. Microsoft ist im C++-Komitee, sie helfen, den Standard voranzutreiben, dies sollte der Fokus sein, nicht proprietäre, in Erweiterungen eingeschlossene.

Könnten wir einen xaml-Compiler wie xaml.exe zum Kompilieren von xaml-Dateien haben, ähnlich wie bei midl.exe, cl.exe oder link.exe? Es wäre sehr nützlich, eine automatische Pipeline für die Winui-Anwendung zu erstellen.

Manchmal möchten wir nicht Visual Studio für die Entwicklung verwenden, vielleicht einen beliebigen Editor verwenden, sondern eine Build-Pipeline getrennt halten. Es scheint, dass die Winui-Anwendung xaml ein besonderer Teil ist und es scheint, dass es noch kein Befehlszeilentool gibt, um sie zu kompilieren.

Dies ist für Szenarien wie cmake erforderlich: https://github.com/microsoft/ProjectReunion/issues/58

Könnten wir einen xaml-Compiler wie xaml.exe zum Kompilieren von xaml-Dateien haben, ähnlich wie bei midl.exe, cl.exe oder link.exe? Es wäre sehr nützlich, eine automatische Pipeline für die Winui-Anwendung zu erstellen.

@sammi fasst #1433 eine plausible Lösung für das zusammen, wonach Sie suchen?

Könnten wir einen xaml-Compiler wie xaml.exe zum Kompilieren von xaml-Dateien haben, ähnlich wie bei midl.exe, cl.exe oder link.exe? Es wäre sehr nützlich, eine automatische Pipeline für die Winui-Anwendung zu erstellen.

@sammi fasst #1433 eine plausible Lösung für das zusammen, wonach Sie suchen?

@jtbrower , genau das suche ich, danke!

Sicherlich ist es eine Vorschau, und das bedeutet, dass ich nicht viel erwarten sollte, aber WinUI 3 Vorschau 2 war für mich enttäuschend.

Mein größter Bedarf liegt im Bereich des XAML-Designs. Ich war ziemlich verblüfft darüber, dass der XAML-Designer überhaupt nicht funktionierte, und ich habe bisher keine klaren Informationen darüber gefunden, wann er das wird.

Ja, ich stimme zu, dass der aktuelle XAML-Designer in Visual Studio sehr langsam ist und kaputt geht, wenn man Dinge in Echtzeit ändert, die wirklich nicht kaputt gehen sollten. Zum Beispiel das Ändern von Height="*" in "Auto" oder 100. (Fehlerfenster spuckt ungefähr 10 Fehler aus - Kringel in Hülle und Fülle, und Sie müssen das Projekt neu erstellen)

Um es klar zu sagen – ich benutze den Designer nicht wirklich zum Entwerfen – ich möchte nur eine Vorstellung davon haben, ob mein Layout so aussieht, wie ich es mir vorgestellt hatte, bevor ich den Build-Prozess durchlaufen habe. Wenn es einfacher wäre, wenn der Designer nur "Nur anzeigen" wäre und es aktualisiert wurde, als ich das XAML optimierte (ohne abzustürzen), wäre das für mich in Ordnung, da ich die GUI nicht verwende, um das XAML zu ändern.. oder sehr selten . Wirklich, was das WindowsCommunityToolkit mit der XAML-Quelle macht, das es dem Benutzer ermöglicht, die Quelle zu ändern und die Ausgabe in Echtzeit anzuzeigen, ist für meine Zwecke gut genug.

Alles in allem hat WinUI eine großartige Idee – entkoppeln Sie all diese "einfachen" Dinge vom Betriebssystem und lassen Sie die Arbeit der Entwickler viel schneller voranschreiten, und wir können die Abhängigkeiten mit der App bündeln, um zu vermeiden, dass 1 Mrd damit sie unsere neuen tollen Sachen laufen lassen können.

Ich hoffe, dass Project Reunion auch die GUI vollständig vom App-Container trennt. UWP-ähnliche UX ohne Sandbox/Grenzen wäre ein großer Schritt nach vorn.

Aber wann können wir einen XAML-Designer haben, der wieder funktioniert... bitte?

Ich denke, Hot Reload hat diesen "Nur-Anzeige"-Zweck des XAML-Designers größtenteils veraltet.

Aber wir sprechen hier über WinUI-Tools. Hot Reload und Live Visual Tree funktionieren auch nicht für WinUI.

Was ich mit dem View Only-Designer meinte, war "Ich könnte mich damit zufrieden geben, wenn es etwas wäre, das wir in eine bevorstehende Vorschau einfügen könnten."

Ich könnte mich irren (UND SAGEN Sie es mir bitte, wenn ich es tue), aber im Moment ist die einzige Möglichkeit, Ihre Benutzeroberfläche in WinUI zu sehen, sie zu erstellen und auszuführen.

Aber wir sprechen hier über WinUI-Tools. Hot Reload und Live Visual Tree funktionieren auch nicht für WinUI.

Was ich mit dem View Only-Designer meinte, war "Ich könnte mich damit zufrieden geben, wenn es etwas wäre, das wir in eine bevorstehende Vorschau einfügen könnten."

Ich könnte mich irren (UND SAGEN Sie es mir bitte, wenn ich es tue), aber im Moment ist die einzige Möglichkeit, Ihre Benutzeroberfläche in WinUI zu sehen, sie zu erstellen und auszuführen.

Hey @ericleigh007 hatten Sie die Gelegenheit, unsere neueste Version von WinUI 3 Preview 3 zu testen? Wir haben vor kurzem viele Werkzeugverbesserungen wie IntelliSense, Hot Reload, Live Visual Tree und Live Property Explorer hinzugefügt. Sie können die Versionshinweise hier einsehen und die neueste Vorschau hier abrufen. Ihre Meinung interessiert mich, also melden Sie sich gerne!

@JeanRoca Das Aufholen der C++/CX-Entwicklungserfahrung war leider keine dieser Tool-Verbesserungen. Erwarten Sie nicht viel Entwicklerliebe für WinUI, wenn sich die vorgeschlagenen C++-Tools anfühlen, als würden Sie ins Jahr 2000 zurückgehen, IDL-Dateien in Notepad schreiben (ohne Editor-Unterstützung) und Dateien manuell kopieren.

Es bringt mich dazu, so viel wie möglich in .NET zu bleiben oder C++/CX trotz der Warnungen, in C++/WinRT zu wechseln, einfach weiter zu verwenden.

Danke für das Update; Werde das heute ausprobieren und werde berichten. 🤞

Von E-Mail gesendet https://go.microsoft.com/fwlink/?LinkId=550986 für Windows 10

Von: JeanRoca [email protected]
Gesendet: Mittwoch, 18. November 2020 04:41
An: microsoft/microsoft-ui-xaml [email protected]
Cc: Eric [email protected] ; Erwähnen Sie Erwä[email protected]
Betreff: Re: [microsoft/microsoft-ui-xaml] WinUI 3.0 Entwicklererfahrung und Tools - Eingabe erforderlich (#1045)

Aber wir sprechen hier über WinUI-Tools. Hot Reload und Live Visual Tree funktionieren auch nicht für WinUI.

Was ich mit dem View Only-Designer meinte, war "Ich könnte mich damit zufrieden geben, wenn es etwas wäre, das wir in eine bevorstehende Vorschau einfügen könnten."

Ich könnte mich irren (UND SAGEN Sie es mir bitte, wenn ich es tue), aber im Moment ist die einzige Möglichkeit, Ihre Benutzeroberfläche in WinUI zu sehen, sie zu erstellen und auszuführen.

Hey @ericleigh007 https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fericleigh007&data=04%7C01%7C%7Cae66199f9c044a728fb108d88b7c470d%7C84df9e7fe9f640aa%a4 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=jha7IQJyg%2BKEZKwKvA Wir haben vor kurzem viele Werkzeugverbesserungen wie IntelliSense, Hot Reload, Live Visual Tree und Live Property Explorer hinzugefügt. Sie können die Versionshinweise hier einsehen https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmicrosoft-ui-xaml%2Fissues%2F3620&data=04%7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160082691% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 & sdata = 2jVKkAs9Whd6U9kH1ZxJKy956wI6Itg7jq6lCuaqEgE% 3D & reserviert = 0 und hier die neueste Vorschau bekommen https://eur05.safelinks.protection.outlook.com/?url=https% 3A% 2F% 2Fdocs.microsoft.com% 2Fen-us% 2Fwindows% 2Fapps% 2Fwinui% 2Fwinui3% 2F & data = 04% 7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160092685% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 & sdata = VF2s7jilqpksevP6Fx7mXW1QCNJN2% 2BK5yWOndg3rKoc%3D&reserviert=0 . Ihre Meinung interessiert mich, also melden Sie sich gerne!

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmicrosoft-ui-xaml%2Fissues%2F1045%23issuecomment -729.402.012 & data = 04% 7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160092685% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 & sdata = R1S2JpfBSzsNKJBAH5% 2Fgme8Bq% 2FjHbzB9FySk1KnZKbk% 3D & reserviert = 0 oder abmelden https: //eur05.safelinks.protection.outlook .com /? url = https% 3A% 2F% 2Fgithub.com% 2Fnotifications% 2Funsubscribe-auth% 2FABX3S2XLYXYXP7BZZC3OE73SQNGBFANCNFSM4ICOLUJQ & data = 04% 7C01% 7C% 7Cae66199f9c044a728fb108d88b7c470d% 7C84df9e7fe9f640afb435aaaaaaaaaaaa% 7C1% 7C0% 7C637412713160102680% 7CUnknown% 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0% 3D% 7C1000 & sdata = 0H6IpND3YX1s6oyXy% 2FCXNAMN9n8fvSPdWks%2FfmXT0Bc%3D&reserviert=0 .

-Es gibt derzeit keinen Wysiwyg-Editor / keine Wysiwyg-Methode, die mit winui3 c++ (Desktop) funktioniert, oder?

Microsoft schafft es, auch C++/CX-Benutzer zu entfremden? Diese ganze Sache entwickelt sich überhaupt nicht gut. Jeder, der die Technologie übernommen hat, die Microsoft vor einigen Jahren für UWP forcierte, egal ob .net oder c++, ist jetzt ohne Unterstützung von Microsoft in Schwierigkeiten.

Es scheint, dass WinUI 3 nur für Desktop-Apps geeignet ist, die in WPF geschrieben sind – aber sie werden schnell feststellen, dass UWP nicht alle Funktionen von WPF und WinUI weniger Funktionen bietet. Jeder wird frustriert sein, was ein schlechter Ort ist, um WinUI 3 zu starten.

@robloo Als jemand, der sich früher für UWP einsetzte, haben sie mich verloren, es sind WPF und Win32, bis sie das Chaos beseitigen.

C++/WinRT war ein politischer Schachzug, und uns wurde gesagt, wir sollten es einfach schlucken und warten, bis ISO C++ schließlich Reflexions- und Metaklassenunterstützung bietet, damit das Visual Studio-Team die C++/CX-Erfahrung replizieren kann.

Wie bereits erwähnt, unterscheidet sich sogar das Bearbeiten von IDL-Dateien nicht von der Verwendung von rohem Notepad.

Dass wir uns in .NET damit abfinden mussten, dass Microsoft uns nicht alle UWP-Komponenten zur Verfügung stellte, war mit C++/CX, das eine C++/CLI-ähnliche Erfahrung bietet, irgendwie erträglich. Mit C++/WinRT sind wir jetzt wieder bei ATL.

Wenn man dann die Diskussionen zu den Reunion-Themen und die Update-Roadmap liest, wird klar, dass es mehrere Jahre dauern wird, bis der Kurs korrigiert wird.

WPF und Win32 mögen alt sein, aber sie sind da und funktionieren, ohne noch einmal umgeschrieben und Funktionen verloren zu haben.

-Es gibt derzeit keinen Wysiwyg-Editor / keine Wysiwyg-Methode, die mit winui3 c++ (Desktop) funktioniert, oder?

Der XAML-Designer funktioniert irgendwie, aber er wurde nicht wirklich für die Wysiwyg-Bearbeitung entwickelt. Hot Reload (das jetzt in Preview 3 funktioniert) funktioniert besser.

Live-Visual-Tree und Live-Requisiten-Ansicht funktionieren in Vorschau 3 hervorragend. Wann soll der Designer verfügbar sein?

Ist auch aufgefallen, dass der Desktop-Designer (WPF) (nicht UWP) früher in 2.4 (oder so) funktioniert hat, aber jetzt sehen meine Tests nicht, dass es wieder funktioniert? Übersehe ich etwas mit dem aktuellen Stand des Designers?

Tut mir leid, dass ich zu spät zur Party komme. @wjk hat es mit seinem ersten Punkt auf den Punkt gebracht.

1. MSIX ist schön und gut, aber ich verwende immer noch das gute alte MSI, um komplexere Anwendungen zu installieren, die Funktionen erfordern, die MSIX nicht unterstützt. Ich bin auch misstrauisch, MSIX zu verwenden, da die erforderlichen Authenticode-Zertifikate teuer sind.

Ich schätze die Faszination von MSIX sehr, aber dieses Zertifikatsunterzeichnungsmandat ist für mich ein Deal Breaker. Ich benötige einen geeigneten SCM-freundlichen Installationsassistenten, mit dem ich ein klassisches Desktop-Installationsprogramm erstellen kann. Warum nehmen Sie nicht die Verbesserungen in MSIX und erstellen eine neue Version des MSI-Installationsprogramms ohne den Microsoft Store und die Zertifizierungsanforderungen für ein moderneres Entwicklungserlebnis? Vielleicht ist dies mit der Funktion "Unterstützt Nicht-MSIX-Bereitstellung" gemeint, die in der aktuellen Roadmap aufgeführt ist ? Wenn ja, warte ich wohl auf 3.x, es sei denn durch ein Wunder, das es in eine frühere Version schafft. Ich freue mich darauf, weil VS Installer-Projekte tragischerweise veraltet und überhaupt nicht freundlich zur Quellcodeverwaltung sind. 😓

@Chiramisu Ich stimme der Meinung zu, aber ich bin auch verwirrt - was ist mit der Sideloading-Erfahrung + AppInstaller ist nicht ausreichend?

@Chiramisu Hast du WiX ausprobiert? Ich benutze es für alle meine MSI-basierten Installer und es funktioniert sehr, sehr gut. Es gibt auch eine Visual Studio-Erweiterung , sodass Sie WiX-Projekte haben können, die die verschiedenen Kompilierungsbefehle automatisieren.

@robloo Als jemand, der sich früher für UWP einsetzte, haben sie mich verloren, es sind WPF und Win32, bis sie das Chaos beseitigen.

C++/WinRT war ein politischer Schachzug, und uns wurde gesagt, wir sollten es einfach schlucken und warten, bis ISO C++ schließlich Reflexions- und Metaklassenunterstützung bietet, damit das Visual Studio-Team die C++/CX-Erfahrung replizieren kann.

Wie bereits erwähnt, unterscheidet sich sogar das Bearbeiten von IDL-Dateien nicht von der Verwendung von rohem Notepad.

Dass wir uns in .NET damit abfinden mussten, dass Microsoft uns nicht alle UWP-Komponenten zur Verfügung stellte, war mit C++/CX, das eine C++/CLI-ähnliche Erfahrung bietet, irgendwie erträglich. Mit C++/WinRT sind wir jetzt wieder bei ATL.

Wenn man dann die Diskussionen zu den Reunion-Themen und die Update-Roadmap liest, wird klar, dass es mehrere Jahre dauern wird, bis der Kurs korrigiert wird.

WPF und Win32 mögen alt sein, aber sie sind da und funktionieren, ohne noch einmal umgeschrieben und Funktionen verloren zu haben.

Nur damit ich Schritt halten kann, können Sie mir in einem mitteilen, über welche IDL-Bearbeitung Sie mit C++/WinRT sprechen? Nach allem, was ich von co_await und anderer C++ 17-Syntax gesehen habe, scheint die Komplexität von C++/CX stark gestiegen zu sein.

FRAU? Ist es nicht möglich, dass C++/WinRT, das auf den Fähigkeiten von C++ 17 basiert, einfach zu komplex ist und sich zu sehr von aktuellen Designs unterscheidet, es sei denn, jemand erstellt wirklich gute Wrapper dafür? Könnte C++/CX nicht so lange aufbewahrt werden, dass ein "ausgezeichneter Wrapper" für C++ 17 erstellt werden kann, um C++/WinRT einigermaßen einfach zu verwenden und zu migrieren?

(jetzt wird jemand auf einen Artikel verlinken, der zeigt, wie das gemacht wird, und ich werde mich dumm vorkommen)

@lmcdougald Das habe ich noch nicht probiert. Es sollte beachtet werden, dass mein spezielles Projekt noch auf .NET Framework 3.5 läuft. Ich weiß, ich weiß. Es wurde mir noch nicht erlaubt, es zu aktualisieren, daher bin ich bei der Installer-Technologie stecken geblieben, die mit diesem alten Framework funktionieren wird. 😖

@wjk Ich habe mir das in der Vergangenheit angesehen, aber nein, ich habe es noch nicht ausprobiert. Trotz der obigen Ausführungen scheint es die einzige Technologie zu sein, die für mein bestehendes Projekt so wie es ist, funktionieren kann. Haben Sie dies zufällig für WinForms-Apps verwendet, die auf einem alten Framework basieren? Leider bin ich ein einsamer Entwickler, daher muss ich extreme Vorurteile darüber hegen, wie ich meine Zeit verbringe und habe nicht die Freiheit, mit neuen Technologien zu experimentieren.

Freundlich

@Chiramisu Ja, WiX funktioniert mit alten Versionen des .NET Frameworks und ja, es funktioniert auch mit Winforms-Apps. Da es rohe MSI-Dateien erstellt, kann WiX alles in jeder Programmiersprache installieren. In Bezug auf das Erlernen würde ich mit den grundlegenden Tutorials beginnen . Ich möchte auch darauf hinweisen, wie Sie feststellen können, ob .NET installiert ist , und wie Sie NGEN mit WiX für Dateien ausführen , da Sie diese Technologien in Ihrer App verwenden. Die Visual Studio-Erweiterung wird auch mit einer Reihe von Projektvorlagen geliefert, um Ihnen den richtigen Skelettcode zum Hinzufügen zu geben. (Hinweis: Verwenden Sie nicht die Bootstrapper-Vorlage, da dies ein viel fortgeschritteneres Thema ist.) Hoffe, das hilft!

@Chiramisu Ich bin so verwirrt von dem, wonach Sie suchen - es scheint mir, als ob Sie nach Verpackungstools für Ihr aktuelles Projekt und nicht nach einem WinUI 3.0-Projekt suchen.

Es ist erwähnenswert, dass .NET Framework 3.5 in einen MSIX gepackt werden kann. Sie könnten ein MSIX-Paket für Ihre vorhandene App mit einem Paketprojekt in VS 2019 erstellen und dann einen langen Übergang einigermaßen nahtlos durchlaufen, aber es ist eine Menge Arbeit:

WinUI 3.0 wird .NET 3.5 nie offiziell unterstützen und wird .NET Framework wahrscheinlich in keiner Version unterstützen. Ich würde Ihre Modernisierung mit dem Ziel beginnen, auf .NET 4.6 (oder idealerweise höher, 4.8 wäre ideal) zu aktualisieren, ohne Ihr vorhandenes Verpackungsprojekt zu ändern. Wenn dies reibungslos verläuft, würde ich dann damit beginnen, die Funktionalität in eine gemeinsam genutzte .NET Standard-Bibliothek zu übertragen, auf die Sie von Ihrer aktualisierten .NET 4.6+-App verweisen.

Sobald die .NET 4.6-App stabil und getestet ist, können Sie sie als automatisches Update für Ihr MSIX-Paketierungsprojekt einlagern. Nach dem .NET Standard-Schritt können Sie einen Projektkopf erstellen, der fast den gleichen Code aus .NET Core 3.1 (oder 5, aber ich glaube, dass der LTS-Status Ihrer Organisation wahrscheinlich etwas bedeutet) verwendet. Testen Sie erneut und stellen Sie dann den MSIX auf diese Version um.

Wenn Sie zu diesem Zeitpunkt von WinForms zu WinUI wechseln, müssen Sie WinUI lernen und die Schnittstelle neu implementieren. Erstellen Sie erneut einen neuen Projektkopf, implementieren und verweisen Sie auf die .NET-Standardbibliothek, testen Sie und wechseln Sie dann das Paket, um diese Version zu verwenden.

So würde ich eine Modernisierung angehen, ohne zu irgendeinem Zeitpunkt wild unterschiedliche Projekte zu erstellen. Ich würde der Einrichtung des MSIX-Pakets und der .NET 4.6 + .NET Standard-Schritte Vorrang geben, da Sie dadurch viel mehr Hilfetools und eine Verbindung zum modernen .NET-Entwicklungszyklus erhalten. Eine schnelle Umstellung auf .NET 5 klingt kurzfristig nach einer schlechten Idee für Ihre Organisation, wenn man bedenkt, dass der Lebenszyklus 1/10 der Laufzeit von .NET 3.5 beträgt.

Nur damit ich Schritt halten kann, können Sie mir in einem mitteilen, über welche IDL-Bearbeitung Sie mit C++/WinRT sprechen? Nach allem, was ich von co_await und anderer C++ 17-Syntax gesehen habe, scheint die Komplexität von C++/CX stark gestiegen zu sein.

FRAU? Ist es nicht möglich, dass C++/WinRT, das auf den Fähigkeiten von C++ 17 basiert, einfach zu komplex ist und sich zu sehr von aktuellen Designs unterscheidet, es sei denn, jemand erstellt wirklich gute Wrapper dafür? Könnte C++/CX nicht so lange aufbewahrt werden, dass ein "ausgezeichneter Wrapper" für C++ 17 erstellt werden kann, um C++/WinRT einigermaßen einfach zu verwenden und zu migrieren?

(jetzt wird jemand auf einen Artikel verlinken, der zeigt, wie das gemacht wird, und ich werde mich dumm vorkommen)

Da normales C++ nicht über die Funktionen zum Extrahieren der Typmetadaten verfügt, die zum Erstellen einer .winmd-Datei erforderlich sind, müssen Sie Ihre WinRT-Klassen zusätzlich zu .hpp und .cpp in eine .idl-Datei schreiben.

co_await ist viel weniger komplex als .then([=](Foo^ thing) { }) überall zu schreiben, es ist der await Syntax von C# sehr ähnlich.

Hier ist ein Beispiel (idl + hpp + cpp) aus dem Standard-Laufzeitkomponentenprojekt:

namespace RuntimeComponent6
{
    runtimeclass Class
    {
        Class();
        Int32 MyProperty;
    }
}

#pragma once

#include "Class.g.h"

namespace winrt::RuntimeComponent6::implementation
{
    struct Class : ClassT<Class>
    {
        Class() = default;

        int32_t MyProperty();
        void MyProperty(int32_t value);
    };
}

namespace winrt::RuntimeComponent6::factory_implementation
{
    struct Class : ClassT<Class, implementation::Class>
    {
    };
}

#include "pch.h"
#include "Class.h"
#include "Class.g.cpp"

namespace winrt::RuntimeComponent6::implementation
{
    int32_t Class::MyProperty()
    {
        throw hresult_not_implemented();
    }

    void Class::MyProperty(int32_t /* value */)
    {
        throw hresult_not_implemented();
    }
}

Hier ist ein kleines co_await-Beispiel:

void PrintFeed(SyndicationFeed const& syndicationFeed)
{
    for (SyndicationItem const& syndicationItem : syndicationFeed.Items())
    {
        std::wcout << syndicationItem.Title().Text().c_str() << std::endl;
    }
}

IAsyncAction ProcessFeedAsync()
{
    Uri rssFeedUri{ L"https://blogs.windows.com/feed" };
    SyndicationClient syndicationClient;
    SyndicationFeed syndicationFeed = co_await syndicationClient.RetrieveFeedAsync(rssFeedUri);
    PrintFeed(syndicationFeed);
}

Hi,

Wir lesen Ihr Feedback und machen uns Notizen zu den Schwachstellen.

@ericleigh007 XAML-Designer war nicht mehr Hauptprobleme des Kunden darin bestanden, die innere Schleife des Entwicklers zu verbessern. An der Spitze standen Hot Reload und Live Visual Tree. In-App-Toolbar ist ein weiterer Punkt, den es in der Vorschau 3 nicht geben konnte. Sie haben Recht, dass nicht klar ist, wann der XAML-Designer sein wird; Wir müssen den Gedanken der Feature-Roadmap aktualisieren. Laut aktuellem Engineering-Plan ist es außerhalb des 3.0 RTM, also nach 3.0.

@pjmlp Ich sympathisiere mit Ihrer

@robloo , Wir

@Chiramisu Lassen Sie mich erklären, was "unterstützt die Nicht-MSIX-Bereitstellung" bedeutet. Heute müssen Sie eine Desktop WinUI 3-App mit MSIX installieren und ausführen. Bei dieser Funktion geht es darum, diese Notwendigkeit zu beseitigen. Um eine Desktop WinUI 3-App auszuführen, müssen Sie nur eine .EXE-Datei verdoppeln, und das war's. Um Ihre App zu installieren, können Sie einfach eine Kopie erstellen (Sie müssen nichts unterschreiben). Grundsätzlich können Sie auch andere Verpackungs- und Installationssysteme wie WiX verwenden.

@marb2000 Vielen Dank, dass Sie das Problem anerkannt haben. Was ich und viele andere Windows-Entwickler nicht verstehen, ist, warum Sie (wie in der WinDev-Verwaltung) entschieden haben, dass es eine gute Idee war, C++/WinRT mit minderwertigen Tools brutal aufzuzwingen. Sogar die Rückkehr zu MFC fühlt sich besser an ' nicht manuell Dateien herum kopieren.

Im Moment konzentriere ich mich auf ASP.NET, WFP und Win32, verfolge einfach die UWP-Sachen in der Hoffnung, dass Microsoft irgendwann erkennt, dass wir es satt haben, Anwendungen neu zu schreiben und über manuelle Konfigurationen gezogen zu werden, wie in der UAP => UWP Übergang, .NET Framework zu .NET Core oder ja C++/CX => C++/WinRT.

Dies ist eher eine Feedback-Sache, als ein lautes Mitglied der Windows-Entwickler-Community, das sich von den ständigen Überarbeitungen seit der Einführung von Windows 8 etwas im Stich gelassen fühlt.

@pjmlp Ich bin mir nicht sicher, warum Sie C++/WinRT kritisieren, das nur ein (standardkonformer) C++-Wrapper um Windows-APIs ist. Es ist möglich, Anwendungen mit C++/WinRT zu schreiben, ohne Werkzeuge (und IDL-Dateien usw.) zu benötigen.

@pjmlp Ich bin mir nicht sicher, warum Sie C++/WinRT kritisieren, das nur ein (standardkonformer) C++-Wrapper um Windows-APIs ist. Es ist möglich, Anwendungen mit C++/WinRT zu schreiben, ohne Werkzeuge (und IDL-Dateien usw.) zu benötigen.

Genau das ist das Problem, keine Toolunterstützung im Vergleich zur Entwicklungserfahrung von C++/CX in Visual Studio.

Keine Bearbeitungsunterstützung für IDL-Dateien, nicht einmal Syntax-Highlighting, geschweige denn Intelisense. Und dann wird man aufgefordert, die generierten Übersetzungseinheiten manuell zu kopieren oder zusammenzuführen!

Das ist wie früher ATL.

ISO C++-Kompatibilität ist mir egal, UWP ist sowieso nur Windows und es gibt keine C++-Compiler ohne Spracherweiterungen.

Ich kann nicht erkennen, wie jemand dies als Fortschritt sehen kann, außer den WinDev-Jungs, die die einzigen Benutzer von WRL waren.

@pjmlp ,

ISO C++-Kompatibilität ist mir egal, UWP ist sowieso nur Windows und es gibt keine C++-Compiler ohne Spracherweiterungen.

Für diejenigen von uns, die große plattformübergreifende C++-Anwendungen schreiben, ist die Einhaltung von Standards eine große Sache. Die Einschränkungen von C++/CX waren schrecklich (keine Member-Variablen, die keine rohen Zeiger sind, Hüte! ( ^ ) usw.). Wir verfügen derzeit über eine große C++/CLI-Interop-Bibliothek, und die Schwachstellen sind zu zahlreich, um sie aufzulisten.

Keine Bearbeitungsunterstützung für IDL-Dateien, nicht einmal Syntax-Highlighting, geschweige denn Intelisense. Und dann wird man aufgefordert, die generierten Übersetzungseinheiten manuell zu kopieren oder zusammenzuführen!

Auch hier vermischen Sie C++/WinRT und Tools. Das sind 2 getrennte Dinge. C++/WinRT ist ein C++-Wrapper um die WinRT-APIs. IDL ist für die Codegenerierung, und ja, ich stimme zu, es ist schrecklich, es ist so schlimm, dass ich es nicht benutze.

Ich schreibe eine reine Windows-App und bin immer noch auf die Einhaltung von Standards bedacht, da ich dadurch einen anderen Compiler verwenden kann, wenn MSVC fehlschlägt.

@MarkIngramDE

Auch hier vermischen Sie C++/WinRT und Tools. Das sind 2 getrennte Dinge. C++/WinRT ist ein C++-Wrapper um die WinRT-APIs. IDL ist für die Codegenerierung, und ja, ich stimme zu, es ist schrecklich, es ist so schlimm, dass ich es nicht benutze.

Ich programmiere seit MS-DOS 3.3 für Microsoft-Plattformen, habe C++ 1992 mit Turbo C++ 1.0 zu meiner Toolbox hinzugefügt, habe die meisten Borland- und Microsoft-Produkte in Bezug auf die C++-Entwicklung verwendet. Sie brauchen keine Vorlesung darüber, worum es bei C++/WinRT geht.

Was es definitiv nicht ist, ist eine Übereinstimmung mit der Entwicklererfahrung von C++ Builder und Qt (mit Qt Designer), die C++/CX 25 Jahre später versprach, endlich aufzuholen.

Aber anscheinend wollen die meisten Leute hier nur Visual C++ 6.0 mit ATL 3.0, und der Rest von uns sollte einfach bei .NET 5, WPF und Win32 Desktop-Erfahrung bleiben, weil wir eine Minderheit sind, die es nicht wert ist, betrachtet zu werden, sonst hätte C++/WinRT es nie getan wurde so geschoben, wie es war.

Seien wir ehrlich, C++/WinRT ist jetzt fast 4 Jahre alt und Microsoft konnte nicht einmal Unterstützung für Syntax-Highlighting und Intelisense bieten?

Etwas, das einige von uns in Notepad ++ (Syntaxhervorhebung) erstellt haben. Wirklich?

Es zeigt definitiv, wo die Prioritäten liegen, und auf diese Weise wird sich WinUI nicht durchsetzen, zu viele Neuschreibungen seit Windows 8.

@pjmlp , wieder

Die IDE-Integration könnte besser sein, wie Sie erwähnt haben IDL-Syntax-Highlighting und Dinge wie der Vorschlag, eine Standardimplementierung in .hpp und .cpp aus der IDL zu erstellen (wie derzeit eine Funktion, die ohne Definition in einem Header deklariert wird, Sie mit grünen Kringeln auffordert, um erstellen), aber die Rückkehr zu C++/CX ist eine Netto-Downgrade-IMO. Es würde zu viel Aufwand erfordern, alle Bibliotheken und gemeinsamen Code, die ich mit C++/CX verwende, zu integrieren und mich zu zwingen, mein Projekt von C++20 auf C++17 herunterzustufen (was ich nicht aufgeben möchte, 20 gibt mir zu viele gute Dinge).

C++/WinRT ist auch viel weniger aufdringlich als C++/CX, wenn Programme nur WinRT-Klassen verwenden und nicht erstellen möchten.

Qt und C++ Builder erreichen ihre Erfahrung in größtenteils standardkonformem C++ (beachten Sie, dass Qt etwas Ähnliches wie IDL hat, genannt Qt MOC). Wenn diese das können, kann VS auch. Es erfordert nur mehr Liebe von jemandem in DevDiv.

Und wie Sie zuvor @sylveon erwähnt

@MarkIngramUK und @sylveon

Ich bin mit diesem Thread fertig, es ist ziemlich klar, dass Feedback wie meins zur Verbesserung der WinUI-Entwicklererfahrung und -tools nicht willkommen ist.

Viel Spaß mit Ihrem standardkonformen C++/WinRT.

können Sie dies bearbeiten, um den Tippfehler "kein Catering" zu beheben. Ich denke, das sollte "jetzt..." sein.

@pjmlp Ich glaube ich verstehe GENAU was du meinst.

Vor etwa einem Jahr habe ich die Idee aufgegeben, meinen UWP C++/CX-Code auf C++/WinRT zu portieren. Der Anreiz für die Portierung bestand darin, Clang verwenden zu können, um meine UWP-App zu kompilieren, da MSVC++ einen Fehler enthält, den ich vor etwa 18 Monaten gemeldet habe, aber sie scheinen einfach nicht daran interessiert zu sein, ihn zu beheben.

Es stellte sich jedoch heraus, dass Visual Studio das Erstellen von UWP-Apps mit Clang nicht unterstützt. Großartig, also ging der "Nur ISO C++"-Vorteil von C++/WinRT direkt aus dem Fenster. Hinzu kommt die Tatsache, dass die Portierung einer C++/CX-Codebasis über C++/WinRT einer Zeitreise von 20 Jahren gleichkommt.

Ich habe es im Wesentlichen aufgegeben, unsere Android/iOS-Apps auf Windows zu portieren. Es ist für einen kleinen Laden wie uns einfach nicht machbar, sich neben der Entwicklung für Android/iOS auch mit dem Clusterfuck der Windows-App-Entwicklung zu befassen.

@MarkIngramUK Es scheint, dass Sie einfach nicht verstehen, dass Werkzeuge SEHR WICHTIG IST. Nicht jeder hat die Ressourcen, den Mangel an geeigneten Werkzeugen selbst zu kompensieren.

Nun, nach meinem Gerede, hier mein Input:

Unterstützung der Verwendung von WinUI 3 mit C++/CX. Sobald die Tools für C++/WinRT für Unternehmen akzeptabel sind, die nicht über die Ressourcen verfügen, um ihre eigenen Tools zu entwickeln, kann es in Ordnung sein, zu C++/WinRT zu wechseln. Jetzt ist es definitiv nicht.

@pjmlp Ich glaube ich verstehe GENAU was du meinst.

Vor etwa einem Jahr habe ich die Idee aufgegeben, meinen UWP C++/CX-Code auf C++/WinRT zu portieren. Der Anreiz für die Portierung bestand darin, Clang verwenden zu können, um meine UWP-App zu kompilieren, da MSVC++ einen Fehler enthält, den ich vor etwa 18 Monaten gemeldet habe, aber sie scheinen einfach nicht daran interessiert zu sein, ihn zu beheben.

Es stellte sich jedoch heraus, dass Visual Studio das Erstellen von UWP-Apps mit Clang nicht unterstützt. Großartig, also ging der Vorteil von C++/WinRT "nur ISO C++" direkt aus dem Fenster. Hinzu kommt die Tatsache, dass die Portierung einer C++/CX-Codebasis über C++/WinRT einer Zeitreise von 20 Jahren gleichkommt.

Ich habe es im Wesentlichen aufgegeben, unsere Android/iOS-Apps auf Windows zu portieren. Es ist für einen kleinen Laden wie uns einfach nicht machbar, sich neben der Entwicklung für Android/iOS auch mit dem Clusterfuck der Windows-App-Entwicklung zu befassen.

@MarkIngramUK Es scheint, dass Sie einfach nicht verstehen, dass Werkzeuge SEHR WICHTIG IST. Nicht jeder hat die Ressourcen, den Mangel an geeigneten Werkzeugen selbst zu kompensieren.

Nun, nach meinem Gerede, hier mein Input:

Unterstützung der Verwendung von WinUI 3 mit C++/CX. Sobald die Tools für C++/WinRT für Unternehmen akzeptabel sind, die nicht über die Ressourcen verfügen, um ihre eigenen Tools zu entwickeln, kann es in Ordnung sein, zu C++/WinRT zu wechseln. Jetzt ist es definitiv nicht.

Aus Neugier, welcher Fehler wurde vor 18 Monaten gemeldet? Hast du irgendwo einen Link dazu?

Hallo Miguel,
___bearbeitet, um den schrecklichen Zustand nach der Antwort aus Outlook für Android zu beheben___

Ich hatte eine Idee, die Ihre Ziele für die Vorschauen und Veröffentlichungen deutlich machen könnte, da Sie sagten, dass die Winrt-Plattform das ist, was Sie zur Entwicklung von WINUI verwenden.

Nehmen Sie diesen Artikel, der eine Menge aufruft, wenn IDL-Dateien geschrieben und manuell kopiert werden, und ändern Sie ihn so, dass er dem Status entspricht, auf den Sie in den Tools hinarbeiten

https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/binding-property

Wenn nicht hier, können wir das vielleicht woanders besprechen.

Sie haben mich übrigens vom XAML-Designer überzeugt, insbesondere mit Tools auf Existenz wie XAML-Studio. (Wenn es nur auch in der Lage wäre, etwas Code dahinter zu laden, damit es erfolgreich XAML laden könnte, das IValueConverter ...

Wie in meinem vorherigen Beitrag erwähnt, ist die C++17-Standardkonformität von C++/WinRT an sich in den meisten Fällen kein Anreiz, eine C++/CX-Codebasis auf C++/WinRT zu migrieren, da Sie gezwungen sind, mit dem Visual C++-Compiler von Microsoft zu kompilieren ohnehin. Wenn Sie den Compiler austauschen könnten, würde sich das komplett ändern.

Visual Studio unterstützt jedoch nicht das Auswechseln des Compilers für Windows-Runtime-Komponenten. Es ist mir ein Rätsel, warum dies nicht unterstützt wird, insbesondere weil es für Desktop-Apps unterstützt wird, wie in diesem Blogbeitrag beschrieben . Die Clang-Unterstützung sollte für Windows-Runtime-Komponenten wirklich erweitert werden.

Wir verwenden Clang, um unsere Codebasis für Android und iOS zu kompilieren. Die Möglichkeit, Clang zum Kompilieren unserer Codebasis für Windows zu verwenden, wäre eigentlich ein sehr, sehr guter Grund, von C++/CX abzuweichen. Die Visual Studio-Funktionsanforderung dafür existiert bereits, aber das Visual Studio-Team hat bisher nichts unternommen.

Sie verfügen über die C++-Standardkompatibilität und Clang-Unterstützung in Visual Studio für Desktop-Apps. Führen Sie daher den letzten Schritt aus und geben Sie einen echten Grund für die Migration von C++/CX an, indem Sie Clang-Unterstützung für Windows-Runtime-Komponenten bereitstellen.

Die Einhaltung der Standards ist für Verbraucher nützlich - wie Sie bereits erwähnt haben, halten sich die Hersteller an MSVC. Es gibt eine Möglichkeit, clang-cl zu "erzwingen" (das ist effektiv das, was das LLVM-Toolset bereits tut ), indem die Eigenschaft CLToolExe auf einen Pfad zu clang-cl in der Datei .vcxproj wird. Ich bin mir nicht sicher, wie gut das in UWP-Projekten funktioniert, aber es ist einen Versuch wert.

Sobald die XAML- und C++/WinRT-Producer-Tools in Desktopprojekten freigeschaltet sind, wird es für mich auch weniger ein Problem sein.

@ackh Ich habe ein UWP-Projekt zum Erstellen unter Clang 11:

Folgendes habe ich getan:

• Entladen Sie das Projekt und fügen Sie die folgende Direktive als erste Direktive unter <Project>

  <PropertyGroup>
    <CLToolExe>C:\Program Files\LLVM\bin\clang-cl.exe</CLToolExe>
  </PropertyGroup>

• Ersetzen Sie <AdditionalOptions>%(AdditionalOptions) /bigobj</AdditionalOptions> durch <AdditionalOptions>%(AdditionalOptions) /bigobj -Xclang -std=c++20 -mcx16</AdditionalOptions>
• Ersetzen Sie <PreprocessorDefinitions>WIN32_LEAN_AND_MEAN;WINRT_LEAN_AND_MEAN;%(PreprocessorDefinitions)</PreprocessorDefinitions> durch <PreprocessorDefinitions>_SILENCE_CLANG_COROUTINE_MESSAGE;WIN32_LEAN_AND_MEAN;WINRT_LEAN_AND_MEAN;%(PreprocessorDefinitions)</PreprocessorDefinitions>
• Direkt darunter füge <ModuleOutputFile />
• Laden Sie das Projekt neu
• Bauen

Es hat jedoch ein paar Fallstricke:

• Einige Warnungen bezüglich nicht verwendeter Argumente stützen sich: Sie könnten diese wahrscheinlich beheben, indem Sie die nicht verwendeten Argumente ändern/entfernen.
• Aus irgendeinem Grund gibt Clang eine 64-Bit-Objektdatei in 32 Bit aus, muss möglicherweise nur -m32 zur CLI hinzufügen.
• Da Clang Coroutinen noch nicht vollständig implementiert, können Sie sie nicht verwenden.
• VS führt jedes Mal, wenn Sie die App ausführen, einen vollständigen Singlethread-Neuaufbau durch, anstatt inkrementell und/oder parallel.

Ich würde vorschlagen, ein Problem auf https://github.com/microsoft/ProjectReunion zu eröffnen, um darauf aufmerksam zu machen.

@sylveon Vielen Dank für die Veröffentlichung dieser Anleitung. Ich werde dies irgendwann ausprobieren, hoffe aber immer noch, dass Visual Studio dies irgendwann out of the box unterstützt.