Xamarin.forms: Uwp Xamarin.Forms.Shell

Shell-Unterstützung wird derzeit nur für Android und iOS bereitgestellt. Wir werten kontinuierlich Feedback bezüglich potenzieller zukünftiger UWP-Unterstützung aus und werden in Zukunft weitere Informationen bereitstellen, sobald diese verfügbar sind.

Normalerweise verwende ich iOS und Android für meine Telefonbenutzer und UWP für meine Tablet- und Desktopbenutzer. Daher ist die UWP-Unterstützung sehr wichtig, um Windows-Benutzer zu beschäftigen.

Was?? MS verzichtet wirklich auf seine eigene Plattform. Das ist traurig zu hören!

Ist nicht ersichtlich, wann UWP-Unterstützung gewährt wird? Oder ist die Entscheidung schon gefallen?

Shell-Unterstützung für UWP - bitte!

Ich würde auch gerne die UWP-Unterstützung für die Shell sehen.

Für mein Unternehmen ist UWP sehr wichtig, da unsere Kunden Windows-Tablets in Kombination mit einigen Android-Telefonen verwenden, um ihre Arbeit zu erledigen. Wir können nicht zu Shell migrieren, wenn die UWP-Unterstützung fehlt.

Einverstanden -- Die UWP-Kompatibilität ermöglicht es mir, die Windows-Tablet-Fähigkeit mit meiner mobilen Implementierung zu integrieren. Ich müsste das komplett separat codieren ohne. Yuck! UWP-Kompatibilität ist ein Muss!

Ich weiß nicht, ob es Sinn macht, da ich Shell noch nicht verwendet habe. Aber vielleicht gibt es eine Möglichkeit, alle anderen Elemente der App (außer Shell) für eine UWP-Implementierung zu verwenden. Schließlich würde die Verwendung von TabbedPage und MasterDetailPage das gleiche erreichen, wie es scheint.

Ich würde auch für die Möglichkeit stimmen, UWP mit Shell zu verwenden.

UWP bitte... oder zumindest ein bisschen von der Microsoft UX API, auf die wir uns einige Jahre verlassen können. Diese Herangehensweise von "Wir werden Sie später wissen lassen, ob wir es unterstützen dürfen" ist einfach gemein.

Also, ja, UWP oder was auch immer wird es unterstützen, aber noch wichtiger: EINE VERPFLICHTUNG, WANN WIR WISSEN, OB ODER WANN.

Ohne diese Gewissheit kann ich nicht zu Shell wechseln.

Bitte nicht nur UWP, sondern auch MacOS.

Ich weiß nicht, ob Sie erkannt haben, dass UWP nicht nur eine Plattform ist, die von Entwicklern immer noch weit verbreitet ist, sondern auch der schnellste Weg, um Android- und iOS-basierte XF-Apps zum Laufen zu bringen. Denn im Vergleich dazu sind die Emulatoren, die sowohl für die Android- als auch für die Mac-Welt bereitgestellt werden, verdammt langsam, anfällig für Probleme und lassen Sie uns nicht über die schrecklichen Zertifizierungserfahrungen sprechen oder immer noch gezwungen sein, einen echten Mac zu haben, oder? Auch wenn sie die Entwicklung in der Realität nicht ersetzen kann, erhöht eine UWP-App die Entwicklerproduktivität, indem sie eine schnelle, einfache und umfassende Möglichkeit bietet, ... Dinge ... zu erledigen. Und dann: Tun Sie alles, um Ihre App auch auf iOS und Android zum Laufen zu bringen.

Werden Sie also bitte Shell-Unterstützung für UWP hinzufügen?

https://github.com/xamarin/Xamarin.Forms/pull/6015

Stimme @Mephisztoe zu, es ist wirklich ein großartiges Produktivitätstool, und natürlich ist die Option, die App tatsächlich für Windows verfügbar zu machen, auch ein nettes Plus :)

Bitte übertragen Sie Xamarin.Forms nicht nur auf mobile Plattformen. Ich würde mir vor allem eine kontinuierliche Unterstützung für UWP wünschen, aber auch WPF und GTK#.

Im Grunde kann also jeder, der über eine plattformübergreifende App für alle drei Plattformen in Xamarin Forms verfügt, diese Features nicht aktualisieren und verwenden. Wenn die zukünftige Entwicklung von Xamarin Forms für UWP nicht stattfindet, warum entfernen Sie UWP nicht einfach aus der plattformübergreifenden Liste?

Unterschiedliche Plattformen werden immer unterschiedliche Prioritäten haben. Immerhin hast du "alle drei Bahnsteige" gesagt, nicht "alle sieben Bahnsteige".

@GalaxiaGuy das ist richtig, ich habe alle drei Plattformen gesagt, wenn ich erfinden . Laut Xamarin.Forms-Dokumentation:

Xamarin.Forms
Xamarin.Forms stellt ein vollständiges plattformübergreifendes UI-Toolkit für .NET-Entwickler bereit. Erstellen Sie vollständig native Android-, iOS- und universelle Windows-Plattform-Apps mit C# in Visual Studio.

Und in der Readme steht:

Xamarin.Forms bietet eine Möglichkeit, native Apps für iOS, Android, Windows und macOS schnell und vollständig in C# zu erstellen.

Das bedeutet nicht, dass es nicht auch GTK, WPF und Tizen unterstützt.

Ich stimme zu, dass diese Plattformen wahrscheinlich weniger wichtig sind als UWP, aber viele Leute denken, dass UWP weniger wichtig ist als iOS und Android.

Ich stimme der Meinung jedoch im Allgemeinen zu, und ich muss neuere Funktionen selbst ignorieren, da sie nicht auf UWP sind.

Zu Ihrer Information, es sei denn, ich lese die Versionshinweise falsch, es sieht so aus, als ob es in der 4.1-Vorschau eine ShellRenderer Implementierung für Tizen gibt. Keine Erwähnung von UWP.

Wenn die Einbindung der Pull-Anfrage von

Es tut mir leid, dass es nicht schneller gegangen ist. Ich habe beim Synchronisieren mit dem Master einige Rückschritte gemacht, und ich war völlig überschwemmt mit Arbeit und Familie, also hatte ich nicht viel Zeit, mich wirklich hinzusetzen und zu versuchen, es anzugehen. Ich nehme jedoch gerne PRs für meine Filiale entgegen.

Wir werden auch die Shell verwenden, sobald sie auf UWP verfügbar ist. Wir haben das gleiche Problem wie oben. Wir haben eine Mischung aus Tablets, Telefonen und Notebooks sowohl mit Android als auch mit Windows. Und wir denken auch, dass die beste Entwicklungsumgebung UWP ist

Dieses Problem ist einer der Hauptgründe, warum ich XF aufgegeben habe. Für unsere Kunden haben Desktop und Mobile die gleiche Priorität.

Was soll ich sagen, was noch nicht gesagt wurde..

also mach weiter damit!
UWP-Unterstützung ist für Microsoft nicht optional – muss man das wirklich wissen?

@papiermache Bitte beachten Sie, dass der Verhaltenskodex für alle Mitteilungen, Probleme und Kommentare zu diesem Projekt gilt

Dies wird auch als Test für das Engagement von MS Xamarin gegenüber Entwicklern behandelt. Ist jemand auf MS-Seite bereit, sich zu wiegen?

Entschuldigung, ich werde weitere Gedanken zügeln … aber ich war einfach total überwältigt, als ich den Mangel an UWP-Unterstützung entdeckte – es war mir nie in den Sinn gekommen, dass UWP nicht von Anfang an eine integrierte Plattform sein würde. Rick.

Von: Jeremy [email protected]
Gesendet: 16. August 2019 14:28
An: Xamarin / Xamarin.Forms [email protected]
Cc: Rick Piovesan [email protected] ; Erwähnen Sie Erwä[email protected]
Betreff: Re: [xamarin/Xamarin.Forms] Uwp Xamarin.Forms.Shell (#5593)

@papiermache https://github.com/papiermache Bitte beachten Sie, dass der Verhaltenskodex für alle Mitteilungen, Probleme und Kommentare zu diesem Projekt gilt

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie auf diese E - Mail direkt, sehen sie auf GitHub https://github.com/xamarin/Xamarin.Forms/issues/5593?email_source=notifications&email_token=ABJC5GJKYHEGIOR3P2UIKX3QE4EVLA5CNFSM4G7ANE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4PT3PQ#issuecomment-522141118 , oder schalten Sie den Faden https://github.com/ Benachrichtigungen/unsubscribe-auth/ABJC5GKCHSPBRJ5JNNEVD5LQE4EVLANCNFSM4G7ANE7A .

Hallo @dotMorten , kannst du ein Update geben? Planen Sie immer noch, UPW+Shell zum Laufen zu bringen? Verstehen Sie, dass dies ein Akt der Freundlichkeit und der Gemeinschaft ist :) Ich frage mich nur, da Ihre Bemühungen am nächsten zu sein scheinen, um Shell + UWP zum Laufen zu bringen. Immer noch völlig verwirrt von dem, was wie ein Microsoft-Pivot weg von der Windows-Unterstützung mit Xamarin aussieht. Dankbar für all die anderen Güte, aber immer noch ratlos und frustriert.

Verzeihung. Irgendwie ausgebrannt im Moment, also habe ich das nicht noch einmal besucht. Ich erinnere mich, dass das Zusammenführen mit den neuesten viele Rückschritte verursacht hat und ich weder die Zeit noch die Energie hatte, um es wieder auf den neuesten Stand zu bringen. Er identifizierte auch mehrere Dinge, die geändert werden müssten und eine breitere Zustimmung des XF-Teams erfordern würden, aber nicht viel Unterstützung erhielten, außer "lasst uns das sicher untersuchen" und starb dann aus. Im Allgemeinen war die Unterstützung und das Feedback, das ich vom XF-Team erhielt, nur Ermutigung, aber es fehlte ein bisschen an der Umsetzung. Ich warte immer noch auf Feedback zu meiner Arbeit, aber zu diesem Zeitpunkt ist es wahrscheinlich zu veraltet. Hoffentlich habe ich bald etwas Zeit und Energie, um mich wieder damit zu beschäftigen.

Dieses Problem befindet sich derzeit in den Top 10 der am häufigsten kommentierten offenen Punkte, steht jedoch nicht auf der Roadmap für die Fertigstellung.

@pauldipietro können wir dazu ein Update bekommen? Es scheint mir ein Signal zu senden, dass die UWP-Unterstützung für das XF-Team keine Priorität mehr hat. Wenn das stimmt, teilen Sie uns dies bitte mit, damit wir entsprechende Pläne schmieden können.

Danke

Zugegeben, ich möchte nur wissen, ob XF keine Windows-Unterstützung bietet. Wenn nicht, möchte ich auch wissen, warum nicht? Wissen sie, was der "nächste" Windows-UX-Stack außer UWP sein wird, und möchten keine Zyklen verschwenden? Wird irgendein Blazor/HTML-Ding das nächste Stück sein? Wenn ja, lassen Sie es mich(uns) einfach wissen, damit ich umsteigen kann... Vielleicht auf die uno-Plattform?

Von: Scott Kuhl [email protected]
Gesendet: Donnerstag, 22. August 2019 13:21:22
An: Xamarin / Xamarin.Forms [email protected]
Cc: David Gerding [email protected] ; Kommentar [email protected]
Betreff: Re: [xamarin/Xamarin.Forms] Uwp Xamarin.Forms.Shell (#5593)

Dieses Problem befindet sich derzeit in den Top 10 der am häufigsten kommentierten offenen Punkte, steht jedoch nicht auf der Roadmap für die Fertigstellung.

@pauldipietro https://github.com/pauldipietro können wir dazu ein Update bekommen? Es scheint mir ein Signal zu senden, dass die UWP-Unterstützung für das XF-Team keine Priorität mehr hat. Wenn das stimmt, teilen Sie uns dies bitte mit, damit wir entsprechende Pläne schmieden können.

Danke

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie auf diese E - Mail direkt, sehen sie auf GitHub https://github.com/xamarin/Xamarin.Forms/issues/5593?email_source=notifications&email_token=AAD7YD4EYE5XBBSXIR6MGV3QF3KKFA5CNFSM4G7ANE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD456VUI#issuecomment-524020433 , oder schalten Sie den Faden https://github.com/ Benachrichtigungen/unsubscribe-auth/AAD7YD42CJSV4KS5ZFWWJU3QF3KKFANCNFSM4G7ANE7A .

Ehrlich gesagt scheint es mir die beste Wahl zu sein, XF durch die Uno-Plattform zu ersetzen ...

Xamarin hat deutlich gemacht, dass ihr Ziel hauptsächlich mobile Geräte (Telefone, Tablets, Uhren) sind, nicht Desktops oder Laptops.

Sie haben kein Interesse daran, UWP selbst zu unterstützen und zu pflegen, daher kann ich es meinen Kunden nicht empfehlen.

Ich möchte meinen Bedarf verdeutlichen: Ich benötige _UWP_ nicht für Xamarin Forms. Ich brauche _einige Windows-Ziele_ für Xamarin Forms. UWP scheint einfach der geeignetste Kandidat zu sein. Wenn ich raten müsste, wird Microsoft irgendwann den HTML- und Blazor-Client für Desktops verwenden, da dies ihnen die größte UX-Reichweite in einer Post-Windows-Welt bieten könnte. Das passt möglicherweise auch besser zu einem zusammensetzbaren Shell-Pfad (nicht zu einer xf-Shell). Da es keine kohärente Roadmap für die Windows-Seite von UX gibt, kann ich mir nicht vorstellen, was sie sonst noch planen könnten.

Aber um es klarzustellen, ist es zumindest wirklich unfreundlich, die Windows-Unterstützung für Xamarin einzustellen, ohne in großen, fetten Buchstaben "WIR NICHT UND WERDEN WINDOWS" anzukündigen. Es klingelt nach "altem Microsoft".

@davidortinau et al: Bitte tun Sie etwas mehr, als auf die jetzt effektiv tote (siehe @dotMortens neuesten Beitrag) "Community-Unterstützung für XF Shell + Windows" zu

Ich bin super dankbar für all die neuen und coolen Dinge in Xamarin. Aber ich benötige eine ehrlichere Antwort auf die Zukunftsfähigkeit von Windows-Zielen, die Xamarin verwenden, falls vorhanden.

einige Dinge, die sich ändern müssten und eine breitere Zustimmung des XF-Teams erfordern

Ich weiß, dass eines davon mit WinUI zu tun hatte, das wir mit diesem PR als Abhängigkeit einbinden möchten
https://github.com/xamarin/Xamarin.Forms/pull/7214

Dieser PR behält 16299-Kompatibilität bei und funktioniert nach meinen Tests hervorragend, wenn er in einem Nuget enthalten ist und der Benutzer nicht die Installation von WinUI erfordert. Ich muss noch 16299 in einer VM hochfahren, um sicherzugehen, aber ich bleibe optimistisch. Ich weiß, @dotMorten, Sie hatten Bedenken bezüglich des

Hier ist das Nuget.

Xamarin.Forms.4.3.0.1853.zip

Wenn jemand anderes es für uns testen möchte, und lassen Sie es uns wissen, wenn Sie irgendwelche Probleme haben, die wirklich hilfreich wären. Ich habe es mit der grundlegenden UWP-Vorlage getestet und es funktioniert für mich ohne Abstürze.

Der Weg, den ich dafür sehe, ist derzeit

• Holen Sie sich #7214 zusammengeführt, damit wir uns um die WinUI-Abhängigkeit gekümmert haben
• die UWP Shell PR neu basieren lassen (wir haben dies für einen zukünftigen Sprint geplant, also werden wir es entweder dann tun oder wenn uns jemand anderes übertrifft)
• Morten hat es bereits mit Gastropods funktioniert, also wollen wir es nur mit ein paar weiteren Beispielen (hauptsächlich Xaminals) testen

Wenn ich bei diesem Pfad etwas übersehe, lass es mich wissen und wir werden versuchen, es zu beheben. Es müssen also nur noch ein Rebase und eine Überprüfung gegen Xaminals durchgeführt werden.

@PureWeen ,
Ich kann App132.zip mit dem von Ihnen bereitgestellten Xamarin Nuget ausführen. App scheint gut zu funktionieren ... vorausgesetzt, es soll Zeitstempelelemente zum Listensteuerelement hinzufügen. Sowohl die Schaltfläche oben als auch das Verhalten Pull to Refresh fügen Elemente hinzu.

Ich bin mir nicht sicher, wonach ich suche, aber ich weiß Ihre Bemühungen zu schätzen und werde versuchen, so gut ich kann zu helfen.

Dave G

@PureWeen Schön zu sehen, dass Sie mit WinUI vorankommen. Die Abhängigkeit von WinUI erzeugte für mich Unterbrechungsverhalten, da WinUI eine Abhängigkeit hinzufügte, die nicht transitiv hinzugefügt wurde. Das kann behoben werden, wenn Sie VS2019 verwenden, aber ich bin mir nicht sicher, ob WinUI diese Funktion bereits genutzt hat (und sie betrifft immer noch VS2017-Benutzer, hat aber zumindest eine Problemumgehung).
Darüber hinaus gab es Fehler in WinUI, die mir viele Kopfschmerzen bereiteten, aber ich habe vor kurzem bemerkt, dass einige der von mir protokollierten Fehler behoben wurden, also ist das alles ermutigend. Pingen Sie mich an, sobald 7214 eingeht, und ich werde versuchen, diese Bemühungen zu starten.
Würde auch gerne Hilfe beim Rebasieren. Als ich das das letzte Mal gemacht habe, habe ich diese PR total durcheinander gebracht :-)

@dotMorten Klingt gut!!

Ich habe die App, die ich oben enthalten habe, auf VS 2017 getestet und sie hat für mich funktioniert, also denke ich, dass wir in dieser Hinsicht in Ordnung sind

Ich bin mir nicht sicher, wonach ich suche, aber ich weiß Ihre Bemühungen zu schätzen und werde versuchen, so gut ich kann zu helfen.

Die Hauptsache wäre, das Nuget zu Ihrem UWP-Hauptprojekt hinzuzufügen und nur sicherzustellen, dass alle kompiliert und ordnungsgemäß ausgeführt werden.

Versuchen Sie nur zu überprüfen, dass das Hinzufügen einer WINUI-Abhängigkeit keine Kopfschmerzen verursacht :-)

Ich habe die App, die ich oben enthalten habe, auf VS 2017 getestet

Ohne auch WinUI zum Projektkopf hinzuzufügen? Das ist das Problem, das ich gefunden habe: Wenn Leute auf eine Version von XF aktualisieren würden, die von WinUI abhängt, würde es nicht funktionieren, ohne auch manuell eine Abhängigkeit zu WinUI hinzuzufügen. IMHO ist das eine bahnbrechende Veränderung. WinUI kann ihr Paket ändern, damit es implizit funktioniert, aber es würde VS2019 erfordern, da es auf einer NuGet 5.0-Funktion basiert (und afaik haben sie diese Änderung nicht vorgenommen, sodass sie derzeit auch nicht funktioniert).

Hier ist das Problem, bei dem ich mich in WinUI angemeldet habe: https://github.com/microsoft/microsoft-ui-xaml/issues/596#issuecomment -524187369

Ich könnte nur eine kurze PR machen, um zumindest das anzugehen, damit VS2019-Benutzer die zusätzliche Abhängigkeit nicht manuell hinzufügen müssen.

Ich füge nur hinzu, dass, als ich die app123 getestet habe, VS2019 war.

Ohne auch WinUI zum Projektkopf hinzuzufügen?

Ja, das Projekt, das ich oben verlinkt habe, kann ich in VS2017 öffnen und es kompiliert und läuft gut. Ich habe das WinUI-Nuget nicht zum UWP-Kopf hinzugefügt, es wird nur als Abhängigkeit innerhalb der Nuspec angezeigt

Ich verstehe nicht wirklich, wie das funktioniert. Es muss ein Stil hinzugefügt werden und ein zusätzliches appx-Frameworkpaket, das mit dem Paket installiert werden muss, und alles wird von .targets erledigt. Ist das Framework-Paket bereits auf Ihrem Rechner installiert?

Das Visual Studio Magazine hat gerade dieses Thema speziell behandelt. Microsoft, Zeit für eine offizielle Antwort.

https://visualstudiomagazine.com/articles/2019/08/23/xamarin-forms-4-2.aspx

@dotMorten Ich bin ein paar Tage prüfen , wenn ich zurückkomme. Ich habe mich auch an das WinUI-Team gewandt, um es zu überprüfen

Dieses Ziel läuft transitiv gut, als ich auf VS 2017 getestet habe
https://github.com/microsoft/microsoft-ui-xaml/blob/8f8cd0fe32754cfcd83dafb2fc8539703b6aec26/build/NuSpecs/MUXControls-Nuget-Common.targets#L6

Hier ist ein aktualisiertes Nuget, mit dem Sie die Einstellung in Ihrem lokalen Formularprojekt überschreiben können
Xamarin.Forms.4.3.0.1853.zip

<SkipMicrosoftUIXamlCheckTargetPlatformVersion>false</SkipMicrosoftUIXamlCheckTargetPlatformVersion>

Im Formularprojekt haben wir dies erzwungen, damit es die Leute nicht überrascht.

https://github.com/xamarin/Xamarin.Forms/pull/7214/files#diff -5e6292d5925c776aa9aa6d6f8c63ddf6R19

@PureWeen Dies ist das Bit, das funktionieren sollte, ohne diese Zeilen explizit hinzuzufügen (da alle Benutzer auch ihre Projektköpfe aktualisieren müssten):

Ich denke, Sie sagen, es funktioniert, aber stellen Sie nur sicher, dass wir auf der gleichen Seite sind.

Es könnte sein, dass Sie dies für eine akzeptable Breaking Change halten, aber ich erinnere mich, dass dies kürzlich mit einer anderen Abhängigkeit passiert ist und viele Leute abgeschreckt hat, da der Upgrade-Pfad nicht so sauber ist wie die Auswahl einer neuen XF-Version.

Betreff: die Notwendigkeit eines Desktop-/Laptop-/Tablet-Ziels für Xamarin Forms

Für diejenigen von uns, die mobile Apps in Unternehmensumgebungen erstellen, ist die Fähigkeit, eine "funktionsähnliche" Desktop-/Laptop-Ausführungsdatei aus derselben grundlegenden Codebasis wie die Android-/iOS-Basis zu erstellen, unerlässlich. Es muss nicht nur Windows sein (ein browserbasiertes Ziel wie HTML/JS wäre genauso gut), aber die überwiegende Mehrheit unserer Benutzer hat einen Windows-Desktop/-Laptop + ein iPhone/Android-Telefon, daher ist eine ausführbare Windows-Datei größtenteils in Ordnung.

Wir haben festgestellt, dass die Mehrheit unserer Benutzer, wenn wir eine mobile App innerhalb des Unternehmens zur Verfügung stellen, diese zuerst auf ihren Laptops/Desktops ausprobieren möchte - und nur wenn sie sie für nützlich oder angemessen für ihre Bedürfnisse halten, werden sie es geruhen, sie zu implementieren es auf ihren Handys. Außerdem funktioniert das Einholen von Zustimmung (und Feedback) von Benutzern erheblich besser, wenn sie Daten eingeben oder Ergebnisse abfragen können, entweder vom Desktop oder vom Gerät, je nachdem, wo sie gerade arbeiten.

Xamarin Forms funktioniert gut für diese Szenarien, und wir würden gerne Shell und CollectionView verwenden, aber sie sind für uns Shelfware, bis sie verwendet werden können, um einen Desktop-/Laptop-ähnlichen Arbeitsplatz zu erstellen ...

@dotMorten Der Grund, warum ich die Ausnahme nicht sehe, ist, dass ich WinUI als Abhängigkeit vom Nuget habe. Wenn Sie also XF auf dem UWP-Kopf installieren, kommt WinUI mit und wendet seine Ziele an.

Dies führt dazu, dass das XF-Paket selbst auf dem UWP-Head-Projekt installiert werden muss, um zu funktionieren. Ich habe mein obiges Beispiel getestet, indem ich XF nur auf dem netstandard-Projekt installiert hatte, und konnte Ihre Ausnahme neu erstellen.

Wir haben in dieser Ausgabe ein bisschen darüber gesprochen
https://github.com/xamarin/Xamarin.Forms/issues/4126

Dies ist problematisch, wenn Benutzer nur XF in der gemeinsam genutzten Bibliothek und nicht im UWP-Head-Projekt installiert haben. Wir müssen das also ein bisschen besprechen, um zu sehen, was wir dagegen tun wollen

@pureween ok gut. Schön, dass wir dann das Gleiche sehen. Einige Dinge, die Sie in Ihren Diskussionen berücksichtigen sollten:

• Wenn mein PR in WinUI zusammengeführt wird, betrifft dies nur VS2017-Benutzer (was jedoch seltsam werden könnte, wenn ein Team beide verwendet und nur einige Benutzer betrifft).
• Sie könnten dies während Init() erkennen und einen Fehler auslösen, der den Benutzern genau sagt, was zu tun ist, damit der Schmerz nicht so schlimm ist.
• Ich habe mit dem Gedanken gespielt, dass XF eine Zieldatei hat, die die Abhängigkeit zum verweisenden Projekt hinzufügt, wenn sie nicht bereits vorhanden ist, aber könnte
  Erstellen Sie eine seltsame Entwicklererfahrung.
• Alle UWP-Projekte verwenden diese Abhängigkeit immer, sobald WinUI von der Plattform getrennt wird (aber bis dahin wird VS2017 wahrscheinlich sowieso nicht mehr unterstützt).
  
  
  
  • Mit dieser Änderung können Sie niedrigere Versionen von Win10 unterstützen und einen Mehrwert schaffen, der dies rechtfertigen könnte.
  
  
  • Niemand wird es bemerken, denn laut Ihrem Team verwendet sowieso niemand wirklich UWP 😜 j/k
  
  

Ein weiterer möglicher Ansatz: Erkennen Sie, ob WinUI während der Init referenziert wird, aber lassen Sie die App laufen. Jeder Renderer, der auf WinUI basiert, würde stattdessen werfen, sodass er nur Benutzer dieser neuen Funktionen betrifft. Die Geschichte lautet also "Wenn Sie Shell oder PullToRefresh verwenden möchten, müssen Sie auch einen Verweis auf WinUI hinzufügen (wenn Sie VS2017 verwenden)".

@dotMorten Vielen Dank für all Ihre Bemühungen, Shell zu UWP zu bringen! Dies ist dringend erforderlich und hätte vom Kernteam von Xamarin angegangen werden sollen.

Hier ist ein Vorgeschmack auf Xaminals, das auf UWP mit CV und Shell läuft!!!

Gute Arbeit!

Fantastischer Job. Wir werden es in unser Framework zum Erstellen von Anwendungen auf Unternehmensebene aufnehmen, sobald es herauskommt

Tolle Arbeit, ich werde es in einer zukünftigen Version meiner App versuchen ;)

Ja, Xamarin hat es geschafft! Ich habe gelesen, dass ein Typ sagt, dass wir nach Uno ziehen. Nein!!!! Xamarin war großartig für uns und hat uns viel Zeit erspart, um Swift + Java lernen zu müssen. Lasst uns geduldig mit dem Team sein und es unterstützen

geschlossen von #6015

Tolle Arbeit, danke für das ganze Team <3, ich werde es drehen 💃

Super Arbeit, vielen Dank!

OK, es passiert etwas Seltsames, ich habe mein Projekt aktualisiert, um die 4.3.0.947036 zu verwenden, jetzt schlägt das Projekt beim Aufrufen von forms.init mit fehl
"Der Windows-Runtime-Typ "Microsoft.UI.Xaml.Controls.XamlControlsResources" konnte nicht gefunden werden

Was sehr merkwürdig ist, ist die Menge an Code, die jetzt in der XamlTypeInfo.g.cs gefunden wird, in der vorherigen Version von Xamarin hatten wir nur 13 Einträge, jetzt haben wir über 43. Ich habe Win.UI Nuget auf dem Projekt installiert und das tut es immer noch nicht helfen. Irgendwelche Ideen

@abrantie1z - (obwohl ich nicht zum Thema gehörte, dachte ich, ich würde es erwähnen) Uno und Xamarin Forms müssen sich nicht mehr gegenseitig ausschließen - siehe https://platform.uno/xamarin-forms/ und https:/ /visualstudiomagazine.com/articles/2019/09/19/uno-platform-2.aspx Vorbehalt : Ich habe Uno nicht verwendet, daher habe ich keine Ahnung, wie robust diese Unterstützung ist. Aber alles, was mehr Leute für XF in Browsern interessiert, ist eine gute Sache.