Xamarin.forms: Uwp Xamarin.Forms.Shell

La prise en charge de Shell est uniquement fournie pour Android et iOS pour le moment. Nous évaluons en permanence les commentaires concernant le futur support UWP potentiel et fournirons plus d'informations à l'avenir dès qu'elles seront disponibles.

J'utilise normalement iOS et Android pour les utilisateurs de mon téléphone et UWP pour mes utilisateurs de tablette et de bureau. Il sera donc très important d'avoir le support UWP pour garder les utilisateurs de Windows engagés.

Quoi?? MS abandonne vraiment sa propre plate-forme. C'est triste à entendre !

N'y a-t-il aucune visibilité sur le moment où le support UWP sera fourni ? Ou la décision est-elle déjà prise ?

Prise en charge du shell pour UWP - s'il vous plaît !

J'aimerais également voir le support UWP pour le Shell.

Pour mon entreprise, UWP est très important car nos clients utilisent des tablettes Windows en combinaison avec certains téléphones Android pour effectuer leur travail. Nous ne pourrons pas migrer vers Shell si la prise en charge UWP est manquante.

D'accord -- La compatibilité UWP me permet d'intégrer la capacité de la tablette Windows avec mon implémentation mobile. Je devrais coder cela complètement séparément sans cela. Beurk ! La compatibilité UWP est un must !

Je ne sais pas si cela a du sens, car je n'ai pas encore utilisé Shell. Mais peut-être existe-t-il un moyen d'utiliser tous les autres éléments de l'application (en plus de Shell) pour une implémentation UWP. Après tout, l'utilisation de TabbedPage et MasterDetailPage permettrait d'obtenir la même chose, semble-t-il.

Je voterais également pour la possibilité d'utiliser UWP avec Shell.

UWP s'il vous plaît... ou au moins une version de l'API Microsoft UX sur laquelle nous pouvons compter pendant quelques années. Cette approche du « nous vous ferons savoir si nous pourrions la soutenir plus tard » est juste méchante.

Alors, oui, UWP ou quoi que ce soit le soutiendra, mais plus important encore : UN ENGAGEMENT POUR QUAND NOUS SAURONS SI OU QUAND.

Je ne peux pas passer à Shell sans cette certitude.

Non seulement UWP mais aussi MacOS, s'il vous plaît.

Je ne sais pas si vous avez réalisé que UWP n'est pas seulement une plate-forme qui est encore largement utilisée par les développeurs, mais aussi le moyen le plus rapide de faire fonctionner des applications XF basées sur Android et iOS. Parce que - en comparaison - les émulateurs fournis à la fois pour le monde Android et Mac sont incroyablement lents, sujets à des problèmes et ne parlons pas de l'horrible expérience de certification ou d'être toujours obligés d'avoir un vrai Mac, n'est-ce pas ? Ainsi, même si elle ne peut finalement pas remplacer le développement sur la vraie chose, une application UWP augmente la productivité des développeurs en offrant un moyen rapide, facile et complet de faire… les choses… faites. Et puis : faites ce qu'il faut pour que votre application soit opérationnelle sur iOS et Android également.

Alors, voulez-vous s'il vous plaît ajouter la prise en charge du shell pour UWP ?

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

D'accord avec @Mephisztoe, c'est vraiment un excellent outil de productivité, et bien sûr, la possibilité de rendre l'application disponible pour Windows est également un avantage appréciable :)

Veuillez ne pas reléguer Xamarin.Forms aux plates-formes mobiles uniquement. J'aimerais voir un support continu pour UWP en particulier, mais aussi WPF et GTK#.

Donc, fondamentalement, quiconque possède une application multiplateforme pour les trois plates-formes dans Xamarin Forms ne peut actuellement pas mettre à jour et utiliser ces fonctionnalités. Si le développement futur sur Xamarin Forms pour UWP ne se produira pas, pourquoi ne pas simplement supprimer UWP de la liste multiplateforme ?

Différentes plateformes auront toujours des priorités différentes. Après tout, vous avez dit "les trois plates-formes", pas "les sept plates-formes".

@GalaxiaGuy c'est correct, j'ai dit les trois plates-formes étant donné que si je disais sept plates-formes, je

Xamarin.Forms
Xamarin.Forms expose une boîte à outils d'interface utilisateur multiplateforme complète pour les développeurs .NET. Créez des applications Android, iOS et Universal Windows Platform entièrement natives à l'aide de C# dans Visual Studio.

Et sur le readme il est dit :

Xamarin.Forms permet de créer rapidement des applications natives pour iOS, Android, Windows et macOS, entièrement en C#.

Cela ne veut pas dire qu'il ne prend pas également en charge GTK, WPF et Tizen.

Je suis d'accord que ces plateformes sont probablement moins importantes que UWP, mais il y a beaucoup de gens qui pensent que UWP est moins important qu'iOS et Android.

Cependant, je suis généralement d'accord avec le sentiment et je dois moi-même ignorer les nouvelles fonctionnalités car elles ne sont pas sur UWP.

Pour info, à moins que je lis mal les notes de version, il semble qu'il y ait une implémentation de ShellRenderer pour Tizen dans l'aperçu 4.1. Aucune mention d'UWP.

Si la demande d' extraction de

Je suis désolé que cela n'aille pas plus vite. J'ai subi quelques régressions lors de la synchronisation avec le maître, et j'ai été complètement submergé par des choses liées au travail et à la famille, donc je n'ai tout simplement pas eu beaucoup de temps pour vraiment m'asseoir et essayer de résoudre le problème. Cependant, je suis plus qu'heureux de prendre des relations publiques pour ma succursale.

Nous utiliserons également le shell dès qu'il sera disponible sur UWP. Nous avons le même problème que ci-dessus. Nous avons un mélange de tablettes, de téléphones et d'ordinateurs portables avec Android et Windows. Et nous pensons également que le meilleur environnement de développement est UWP

Ce problème est l'une des principales raisons pour lesquelles j'ai abandonné XF. Pour nos clients, desktop et mobile ont la même priorité.

Que puis-je dire qui n'a pas déjà été dit ..

alors CONTINUEZ !
Le support UWP n'est pas facultatif pour Microsoft - avez-vous vraiment besoin d'être informé ?

@papiermache veuillez noter que le code de conduite s'applique à toutes les communications, problèmes et commentaires sur ce projet

Traiter également cela comme un test de l'engagement de MS Xamarin envers les développeurs. Quelqu'un du côté de la SEP est-il prêt à intervenir ?

Désolé à tous, va tempérer d'autres pensées… mais j'ai été totalement époustouflé de découvrir le manque de support UWP – il ne m'est même jamais venu à l'esprit qu'UWP ne serait pas une plate-forme incluse dès le départ. Meule.

De : Jeremy [email protected]
Envoyé : 16 août 2019 14:28
À : xamarin/Xamarin.Forms [email protected]
Cc : Rick Piovesan [email protected] ; Mentionnez [email protected]
Objet : Re : [xamarin/Xamarin.Forms] Uwp Xamarin.Forms.Shell (#5593)

@papiermache https://github.com/papiermache veuillez noter que le code de conduite s'applique à toutes les communications, problèmes et commentaires sur ce projet

-
Vous recevez ceci parce que vous avez été mentionné.
Répondre à cet e - mail directement, voir sur GitHub https://github.com/xamarin/Xamarin.Forms/issues/5593?email_source=notifications&email_token=ABJC5GJKYHEGIOR3P2UIKX3QE4EVLA5CNFSM4G7ANE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4PT3PQ#issuecomment-522141118 , ou couper le fil https://github.com/ notifications/unsubscribe-auth/ABJC5GKCHSPBRJ5JNNEVD5LQE4EVLANCNFSM4G7ANE7A .

Salut @dotMorten , pouvez-vous donner une mise à jour ? Envisagez-vous toujours d'essayer de faire fonctionner UPW+Shell ? Comprenez que c'est un acte de gentillesse et de communauté :) Je me demande juste puisque vos efforts semblent être les plus proches de faire fonctionner Shell + UWP. Toujours complètement mystifié par ce qui semble être un pivot de Microsoft loin de la prise en charge de Windows avec Xamarin. Reconnaissant pour tout le reste, mais toujours perplexe et frustré.

Pardon. En quelque sorte épuisé en ce moment, donc je n'ai pas revu ça. Je me souviens que la fusion avec le dernier a causé beaucoup de régressions et je n'ai tout simplement pas eu le temps ni l'énergie de le remettre à niveau. A également identifié plusieurs éléments qui devraient changer et nécessiter une adhésion plus large de l'équipe XF, mais n'ont pas reçu beaucoup de soutien au-delà de "bien sûr, examinons-le", puis se sont éteints. En général, le soutien et les commentaires que j'ai reçus de l'équipe XF n'étaient que des encouragements, mais avec un peu de manque de suivi. J'attends toujours des retours sur le travail que j'ai fait mais à ce stade c'est probablement trop obsolète. J'espère que j'aurai bientôt du temps et de l'énergie pour m'y remettre.

Ce problème figure actuellement dans le top 10 des éléments ouverts les plus commentés, mais il n'est pas sur la feuille de route à terminer.

@pauldipietro pouvons-nous obtenir une mise à jour à ce sujet ? Cela me semble envoyer un signal que le support UWP n'est plus une priorité pour l'équipe XF. Si cela est vrai, veuillez nous le dire afin que nous puissions faire des plans autour de cela.

Merci

D'accord, je veux juste savoir si XF n'inclura pas la prise en charge de Windows. Si non, je veux aussi savoir pourquoi pas ? Savent-ils quelle sera la "prochaine" pile UX de Windows autre que UWP et ne veulent-ils pas gaspiller des cycles ? Est-ce que quelque chose Blazor/HTML sera la prochaine pièce ? Si c'est le cas, faites-le moi (nous) savoir afin que je puisse effectuer la transition... Peut-être vers une plate-forme ?

De : Scott Kuhl [email protected]
Envoyé : jeudi 22 août 2019 13:21:22
À : xamarin/Xamarin.Forms [email protected]
Cc : David Gerding [email protected] ; Commentaire [email protected]
Objet : Re : [xamarin/Xamarin.Forms] Uwp Xamarin.Forms.Shell (#5593)

Ce problème figure actuellement dans le top 10 des éléments ouverts les plus commentés, mais il n'est pas sur la feuille de route à terminer.

@pauldipietro https://github.com/pauldipietro pouvons-nous obtenir une mise à jour à ce sujet ? Cela me semble envoyer un signal que le support UWP n'est plus une priorité pour l'équipe XF. Si cela est vrai, veuillez nous le dire afin que nous puissions faire des plans autour de cela.

Merci

-
Vous recevez ceci parce que vous avez commenté.
Répondre à cet e - mail directement, voir sur GitHub https://github.com/xamarin/Xamarin.Forms/issues/5593?email_source=notifications&email_token=AAD7YD4EYE5XBBSXIR6MGV3QF3KKFA5CNFSM4G7ANE7KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD456VUI#issuecomment-524020433 , ou couper le fil https://github.com/ notifications/unsubscribe-auth/AAD7YD42CJSV4KS5ZFWWJU3QF3KKFANCNFSM4G7ANE7A .

Très franchement, il me semble que le meilleur pari serait en fait de remplacer XF par Uno Platform...

Xamarin a clairement indiqué que sa cible était principalement les appareils mobiles (téléphones, tablettes, montres), et non les ordinateurs de bureau ou les ordinateurs portables.

Ils n'ont aucun intérêt à soutenir et à maintenir UWP eux-mêmes, il n'est donc pas bon que je le recommande à mes clients.

Je veux clarifier mon besoin : je n'ai pas besoin de _UWP_ pour Xamarin Forms. J'ai besoin de _certaines cibles Windows_ pour Xamarin Forms. UWP semble être le candidat le plus viable. Si je devais deviner, Microsoft finira par passer au client HTML et Blazor pour les ordinateurs de bureau, car cela pourrait leur donner la plus large portée UX dans un monde post-Windows. Cela pourrait également mieux convenir avec un chemin de shell composable (pas de shell xf). En l'absence de feuille de route cohérente pour le côté Windows de l'UX, je ne peux pas imaginer ce qu'ils pourraient planifier d'autre.

Mais pour être clair, abandonner la prise en charge de Windows pour Xamarin sans annoncer en gros caractères gras, "NOUS NE FAISONS PAS ET NE FAISONS PAS WINDOWS", est, au strict minimum, vraiment, vraiment méchant. Ça sonne "vieux Microsoft".

@davidortinau et al: Veuillez faire quelque chose de plus que de pointer vers le "support communautaire pour XF Shell + Windows" désormais effectivement mort (voir le dernier message de @dotMorten ).

Je suis très reconnaissant pour toutes les nouveautés et les nouveautés de Xamarin. Mais j'ai besoin d'une réponse plus honnête sur la viabilité future, le cas échéant, des cibles Windows utilisant Xamarin.

plusieurs choses qui devraient changer et nécessiter une adhésion plus large de l'équipe XF

Je sais que l'un d'entre eux avait à voir avec WinUI que nous espérons intégrer en tant que dépendance avec ce PR
https://github.com/xamarin/Xamarin.Forms/pull/7214

Ce PR maintient la compatibilité 16299 et, d'après mes tests, fonctionne très bien lorsqu'il est inclus avec un nuget et ne nécessite pas que l'utilisateur installe WinUI. J'ai encore besoin de faire tourner 16299 dans une machine virtuelle pour m'en assurer, mais je reste optimiste. Je sais que @dotMorten vous avez exprimé des inquiétudes concernant l'extraction de WinUI, donc si je les ai totalement ignorés, faites-le moi savoir :-)

Voici cette pépite.

Xamarin.Forms.4.3.0.1853.zip

Si quelqu'un d'autre souhaite le tester pour nous et faites-nous savoir si vous avez des problèmes qui seraient vraiment utiles. Je l'ai testé avec le modèle UWP de base et cela fonctionne bien pour moi sans plantage.

Le chemin que je vois pour cela actuellement est

• obtenir #7214 fusionné afin que nous ayons pris en charge la dépendance de WinUI
• obtenir le UWP Shell PR rebasé (nous avons cela prévu pour un futur sprint donc nous le ferons alors ou si quelqu'un d'autre nous bat)
• Morten le fait déjà fonctionner avec Gastropods, nous voulons donc le tester avec quelques échantillons supplémentaires (principalement Xaminals), une fois que cela fonctionnera et que nous apporterons les modifications de nettoyage de code nécessaires, nous fusionnerons

S'il me manque quelque chose avec ce chemin, faites-le moi savoir et nous essaierons de le résoudre, donc tout ce qui doit être fait est une rebase et une vérification contre Xaminals.

@PureWeen ,
Je peux exécuter App132.zip avec le Xamarin Nuget que vous avez fourni. L'application semble fonctionner correctement ... en supposant qu'elle soit censée ajouter des éléments horodatés au contrôle de liste. Le bouton en haut et le comportement Tirer pour actualiser ajoutent des éléments.

Je ne sais pas ce que je recherche, mais j'apprécie vos efforts et j'essaierai de vous aider autant que possible.

David G

@PureWeen C'est génial de voir que vous avancez avec WinUI. La dépendance à WinUI créait des comportements de rupture pour moi, car WinUI ajoutait une dépendance qui n'était pas ajoutée de manière transitive. C'est réparable si vous utilisez VS2019, mais je ne sais pas si WinUI a encore tiré parti de cette fonctionnalité (et cela affectera toujours les utilisateurs de VS2017, mais a au moins une solution de contournement).
De plus, il y avait des bogues dans WinUI qui m'ont causé beaucoup de maux de tête, mais j'ai remarqué récemment que certains de ceux que j'ai enregistrés ont été corrigés, donc tout est encourageant. Envoyez-moi un ping une fois que 7214 est entré, et j'essaierai de démarrer cet effort.
J'aimerais aussi de l'aide pour le rebasage. La dernière fois que j'ai fait ça, j'ai complètement foiré ce PR :-)

@dotMorten Ça a l'

J'ai testé l'application que j'ai incluse ci-dessus sur VS 2017 et cela a fonctionné pour moi, donc je pense que nous sommes d'accord sur ce front

Je ne sais pas ce que je recherche, mais j'apprécie vos efforts et j'essaierai de vous aider autant que possible.

L'essentiel serait d'ajouter le nuget dans votre projet UWP principal et de vous assurer qu'ils semblent tous se compiler et s'exécuter correctement.

J'essaye juste de vérifier que l'ajout d'une dépendance WINUI ne va pas causer de maux de tête :-)

J'ai testé l'application que j'ai incluse ci-dessus sur VS 2017

Sans ajouter également WinUI au chef de projet ? C'est le problème que j'ai trouvé : si les gens devaient mettre à niveau vers une version de XF qui dépend de WinUI, cela ne fonctionnerait pas sans ajouter manuellement une dépendance à WinUI. À mon humble avis, c'est un changement radical. WinUI peut modifier son package afin que cela fonctionne implicitement, mais cela nécessiterait VS2019 car il repose sur une fonctionnalité NuGet 5.0 (et, si je ne m'abuse, ils n'ont pas apporté cette modification, donc cela ne fonctionnera pas non plus pour le moment).

Voici le problème que j'ai connecté à WinUI : https://github.com/microsoft/microsoft-ui-xaml/issues/596#issuecomment -524187369

Je pourrais juste faire un bref PR pour au moins résoudre ce problème afin que les utilisateurs de VS2019 n'aient pas à ajouter manuellement la dépendance supplémentaire.

J'ajoute juste que lorsque j'ai testé l'application 123, c'était avec VS2019.

Sans ajouter également WinUI au chef de projet ?

Oui, le projet que j'ai lié ci-dessus, je peux l'ouvrir dans VS2017 et il se compile et fonctionne correctement. Je n'ai pas ajouté le nuget WinUI à la tête UWP, il n'est indiqué qu'en tant que dépendance à l'intérieur du nuspec

Je ne comprends pas vraiment comment cela fonctionne. Il y a un style qui doit être ajouté et un package de framework appx supplémentaire qui doit être installé avec le package, et tout est fait par les .targets. Le package de framework est-il déjà installé sur votre machine ?

Visual Studio Magazine vient de couvrir ce problème en particulier. Microsoft, c'est l'heure d'une réponse officielle.

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

@dotMorten Je suis absent pendant quelques jours mais j'examinerai cela à mon retour. J'ai également contacté l'équipe WinUI pour examiner

Cette cible fonctionne bien de manière transitive lorsque j'ai testé sur VS 2017
https://github.com/microsoft/microsoft-ui-xaml/blob/8f8cd0fe32754cfcd83dafb2fc8539703b6aec26/build/NuSpecs/MUXControls-Nuget-Common.targets#L6

Voici un nuget mis à jour qui vous permet de remplacer le paramètre dans votre projet de formulaires local
Xamarin.Forms.4.3.0.1853.zip

<SkipMicrosoftUIXamlCheckTargetPlatformVersion>false</SkipMicrosoftUIXamlCheckTargetPlatformVersion>

Dans le projet de formulaires, nous avons forcé cela à vrai afin que cela ne surprenne pas les gens.

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

@PureWeen C'est le bit qui devrait fonctionner sans ajouter ces lignes explicitement (puisque tous les utilisateurs devraient également mettre à jour leurs chefs de projet):

Je pense que vous dites que cela fonctionne, mais assurez-vous simplement que nous sommes sur la même longueur d'onde.

Vous considérez peut-être cela comme un changement de rupture acceptable, mais je me souviens que cela s'est produit récemment avec une autre dépendance et a jeté beaucoup de gens, car le chemin de mise à niveau n'est pas aussi clair que de simplement choisir une nouvelle version XF.

Re : le besoin d'une cible de bureau/ordinateur portable/tablette pour Xamarin Forms

Pour ceux d'entre nous qui créent des applications mobiles dans des environnements d'entreprise, la capacité de produire un exécutable de bureau/ordinateur portable « de travail similaire » à partir de la même base de code de base que la base Android/iOS est essentielle. Il n'est pas nécessaire que ce soit uniquement Windows (une cible basée sur un navigateur telle que HTML/JS serait tout aussi bonne) mais la grande majorité de nos utilisateurs ont un ordinateur de bureau/ordinateur portable Windows + un téléphone iPhone/Android, donc un exécutable Windows est bien pour la plupart.

Nous avons constaté que lorsque nous rendons une application mobile disponible au sein de l'organisation, la majorité de nos utilisateurs veulent d'abord l'essayer sur leurs ordinateurs portables/de bureau - et ce n'est que s'ils la trouvent utile ou adaptée à leurs besoins qu'ils daigneront mettre cela sur leurs téléphones. De plus, obtenir l'adhésion (et les commentaires) des utilisateurs fonctionne beaucoup mieux s'ils peuvent saisir des données ou interroger des résultats à partir d'un ordinateur de bureau ou d'un appareil, selon l'endroit où ils travaillent à ce moment particulier.

Xamarin Forms fonctionne bien pour ces scénarios, et nous aimerions vraiment utiliser Shell et CollectionView, mais ils sont pour nous des étagères jusqu'à ce qu'ils puissent être utilisés pour produire un ordinateur de bureau/ordinateur portable...

@dotMorten donc la raison pour laquelle je ne vois pas l'exception est que j'ai WinUI en tant que dépendance du nuget, donc si vous installez XF sur la tête UWP, WinUI vient pour le trajet et applique ses cibles.

Cela fait en sorte que le package XF lui-même doit être installé sur le projet principal UWP pour fonctionner. J'ai testé mon exemple ci-dessus avec XF uniquement installé sur le projet netstandard et j'ai pu recréer votre exception.

Nous en avons un peu parlé dans ce numéro
https://github.com/xamarin/Xamarin.Forms/issues/4126

Cela ne fonctionne pas si les utilisateurs n'ont installé que XF dans la bibliothèque partagée et non dans le projet principal UWP. Nous devrons donc en discuter un peu pour voir ce que nous voulons faire à ce sujet

@pureween ok bien. Content qu'on voit la même chose alors. Quelques points à considérer dans vos discussions :

• Si mes relations publiques dans WinUI sont fusionnées, cela n'affectera que les utilisateurs de VS2017 (ce qui peut toutefois devenir étrange si une équipe utilise les deux et cela n'affecte que certains utilisateurs).
• Vous pouvez détecter cela pendant Init() et générer une erreur indiquant aux utilisateurs exactement ce qu'ils doivent faire pour que la douleur ne soit pas si grave.
• Je jouais avec l'idée que XF a un fichier cibles qui ajoute la dépendance au projet de référence s'il n'est pas déjà présent, mais pourrait
  créer une expérience de développement étrange.
• Tous les projets UWP utiliseront toujours cette dépendance une fois que WinUI sera séparé de la plate-forme (mais d'ici là, VS2017 n'est probablement plus pris en charge de toute façon).
  
  
  
  • Vous pourrez prendre en charge les versions inférieures de Win10 avec ce changement, créant une valeur ajoutée qui pourrait le justifier.
  
  
  • Personne ne le remarquera car selon votre équipe, personne n'utilise vraiment UWP de toute façon 😜 j/k
  
  

Une autre approche possible : détectez si WinUI est référencé lors de l'initialisation, mais laissez l'application s'exécuter. Tout moteur de rendu qui s'appuie sur WinUI lancerait à la place, donc cela n'affectera que les utilisateurs de ces nouvelles fonctionnalités. L'histoire devient donc "Si vous souhaitez utiliser Shell ou PullToRefresh, vous devez également ajouter une référence à WinUI (si vous êtes sur VS2017)".

@dotMorten Merci pour tous vos efforts pour amener Shell à UWP ! Ceci est très nécessaire et aurait dû être résolu par l'équipe de base de Xamarin.

Voici un avant-goût de Xaminals fonctionnant sur UWP avec CV et Shell !!!

Bon travail!

Travail fantastique. Nous l'inclurons dans notre cadre de création d'applications au niveau de l'entreprise dès sa sortie

Excellent travail, je vais l'essayer dans une future version de mon application ;)

Oui, Xamarin l'a fait ! J'ai lu qu'un gars dit que nous déménageons à Uno. Non!!!! Xamarin a été formidable pour nous et nous a fait gagner beaucoup de temps pour avoir à apprendre Swift + Java. Soyons patient avec l'équipe et soutenons-la

fermé par #6015

Super travail, merci pour toute l'équipe <3, je vais le tourner 💃

Super travail, merci beaucoup !

OK, quelque chose d'étrange se passe, j'ai mis à niveau mon projet pour utiliser le 4.3.0.947036, maintenant le projet échoue lors de l'appel de forms.init avec
'Impossible de trouver le type de Windows Runtime 'Microsoft.UI.Xaml.Controls.XamlControlsResources

Ce qui est très étrange, c'est la quantité de code maintenant trouvée dans XamlTypeInfo.g.cs, dans la version précédente de Xamarin, nous n'avions que 13 entrées, maintenant nous en avons plus de 43. J'ai installé Win.UI Nuget sur le projet et c'est toujours le cas. pas d'aide. Des idées

@abrantie1z - (bien que hors sujet, je pensais mentionner) Les formulaires Uno et Xamarin ne doivent plus être un choix mutuellement exclusif - voir https://platform.uno/xamarin-forms/ et https :/ /visualstudiomagazine.com/articles/2019/09/19/uno-platform-2.aspx Avertissement : Je n'ai pas utilisé Uno, donc je n'ai aucune idée de la robustesse de ce support. Mais tout ce qui intéresse plus de gens à XF dans les navigateurs est une bonne chose.