Xamarin.forms: [Bug] InvalidOperationException dans TypedBinding`2 [TSource, TProperty] .Apply

@mfeingol Si vous êtes en mesure de

J'essaierai de faire ça ce week-end, mais celui-ci est un peu difficile à reproduire à la demande. Des indices de votre part, basés sur votre compréhension du code?

Il semble que cela soit lié à la liaison XAML à l'aide d'un DataType.

Je voyage maintenant, mais ma solution temporaire était de désactiver les liaisons compilées.

@mfeingol D'accord, ça semble juste. Si vous en avez l'occasion, veuillez fournir un exemple de projet pour nous aider à réduire le problème. Merci!

Je vois ce même problème sur iOS et Android. Je n'utilise pas de liaisons compilées.

Problème AppCenter:

TypedBinding 2[TSource,TProperty].Apply (System.Boolean fromTarget) TypedBinding 2 + PropertyChangedProxy [TSource, TProperty].b__16_0 ()
Thread + RunnableImplementor.Run ()
IRunnableInvoker.n_Run (System.IntPtr jnienv, System.IntPtr native__this)
(méthode-dynamique de wrapper) System.Object.26 (intptr, intptr)

Projet de formulaires Xamarin, page Xaml avec ViewModel - Grille contenant ScrollView - ScrollView contient des étiquettes. Assez simple.

@samhouts : j'ai fait de mon mieux, mais je suis incapable de reproduire le problème dans un exemple d'application. J'ai cependant une reproduction à 100% dans mon application de production.

Puis-je accorder à un membre de votre équipe des autorisations sur mon projet Azure DevOps afin qu'il puisse reproduire le problème?

shneuvil sur microsoft.com

Vous êtes ici: https://dev.azure.com/sideroads/Sideroads

Repro étapes:

1. git checkout 6698-repro et compilez. Vous devrez peut-être ajouter le répertoire externe à votre liste de répertoires NuGet pour récupérer un package.
2. Exécutez l'application et créez un nouveau voyage à partir de la page des voyages. Nommez le voyage quelque chose comme "Test" et laissez toutes les valeurs par défaut, sauf en spécifiant le départ et l'arrivée et les aéroports (par exemple SEA et LAS).
3. Appuyez sur le trajet pour le sélectionner.
4. Depuis le menu des hamburgers, accédez à la page météo, confirmez que les bulletins météo s'affichent pour les emplacements concernés.
5. Accédez aux paramètres, changez le fournisseur de météo du NWS à ICI.
6. Revenez à la page météo. Vous devriez voir un crash assez rapidement. Le redémarrage de l'application doit se rouvrir dans la page météo, actualiser la météo et générer un autre plantage.

Si, pour une raison quelconque, vous ne pouvez pas reproduire un voyage aussi simple, j'en exporterai un plus sophistiqué pour vous avec plus d'emplacements.

@PureWeen : faites-moi savoir si cela ne fonctionne pas pour vous.

@mtirona : J'ai manqué votre commentaire plus tôt, désolé. C'est étrange que vous voyiez cela sans utiliser de liaisons compilées. Je suppose que vous n'avez pas un simple projet de repro qui déclenche le crash à la demande?

@mfeingol Ce problème apparaît au hasard dans notre application. Je n'ai pas de moyen simple de recréer à la demande - j'ai des centaines de plantages dans AppCenter pour documenter le problème. Je serais reconnaissant pour toutes les directions sur la façon d'éviter le problème ...

@mtirona : êtes-vous sûr à 100% de ne pas utiliser x: DataType n'importe où dans votre XAML?

@mfeingol Il y avait x: DataType sur les pages parentes, j'ai donc parcouru toute l'application et créé une branche où j'ai supprimé le x: DataType. Je suis en train de demander à notre QA de tester cette branche pour les plantages pour voir si cela a résolu le problème.

Je suis certain que cela est lié à XamlC, sauf si vous créez des TypedBindings dans votre propre code (ceux-ci sont _seulement_ créés par le compilateur Xaml)

Remarque: j'ai utilisé Xamarin Forms 3.6 et je viens de mettre à jour la dernière version 4.1. Lors de la première exécution de mon application, j'ai immédiatement vu ce plantage lors de l'ajout rapide d'éléments à une page de liste groupée. Le problème est donc toujours présent avec 4.1.0.618606.

@PureWeen : J'ai mis à jour les étapes de repro ci-dessus pour faire référence à une branche que vous pouvez récupérer et qui devrait reprocher le problème immédiatement pour vous.

@mfeingol pouvez-vous faire ça pour moi?

Si, pour une raison quelconque, vous ne pouvez pas reproduire un voyage aussi simple, j'en exporterai un plus sophistiqué pour vous avec plus d'emplacements.

J'ai essayé tes pas et rien ne s'est écrasé pour moi

Très bien, alors @mfeingol Je ne sais pas comment ou pourquoi vos données s'alignent pour causer ce problème, mais c'est ce que je sais jusqu'à présent

Le TypedBindings utilise un WeakReference au BindableObject donc si c'est la seule chose qui fait référence au BindableObject, il perdra cette référence.

Voici le code qui plante
`` C #
if (! _weakTarget.TryGetTarget (hors cible))
throw new InvalidOperationException ();

If you look at the output of the application while it's running the exception always happens after a GC which makes sense why you are only seeing this after loading a larger data set.

As a test with the TypeBindings I created a nuget where it stores the source and target to a local variable just to see what would happen 

```C#
            _weakSource.SetTarget(source);
            _weakTarget.SetTarget(bindObj);
            _bindObj = bindObj;
            _source = source;
            ApplyCore(source, bindObj, targetProperty);
        }

        BindableObject _bindObj;
        object _source;

Et si je fais cela, le crash ne se produit pas.

Je pense que d'une manière ou d'une autre, vos données arrivent à un endroit où la seule chose qui fait référence à l'instance de LocationDayWeatherViewModel qui est liée à ViewCell est le TypeBinding et c'est tout. Je n'ai toujours pas tout à fait déterminé si c'est en quelque sorte une exception de notre côté par rapport au vôtre. Pouvez-vous vous assurer de conserver une référence à tous les LocationDayWeatherViewModel créés qui sont liés à ListView?

Merci d'avoir examiné cela! Ce problème a été assez difficile à reproduire en dehors de l'application complète, il est donc logique que ce soit quelque chose impliquant des références faibles. Je me demande si l'ajout de la pression mémoire à une reproduction plus simple pourrait entraîner le même problème.

Quoi qu'il en soit, le seul moment où une instance de LocationDayWeatherViewModel ne serait pas référencée par le viewmodel serait lors d'une actualisation de la journée météo, au cours de laquelle le code efface la ObservableCollection liée d'éléments avant d'insérer de nouveaux éléments. Cela se produit profondément dans ExpandableGroupCollectionViewModel.Refresh au cas où vous voudriez définir des bps.

Cependant, je pense que la suppression d'un ObservableCollection lié devrait être une opération sûre, et il n'est pas évident pour moi pourquoi les liaisons XF utiliseraient des références faibles. On dirait qu'il aurait exactement ce genre de course.

A part: j'ai essayé de copier les éléments de this dans une liste temporaire avant de les effacer dans Refresh , mais étonnamment, cela n'a pas semblé contourner le problème. J'ai fait référence à la liste à la fin de la méthode pour m'assurer que le GC ne l'a pas nucléaire également. Je suppose que cela aurait du sens si XF tente d'utiliser la liaison obsolète "plus tard", et cela suggérerait qu'il n'y a pas de bon moyen pour une application de stabiliser les références liées. Mais je ne comprends peut-être pas les choses.

(Et oui, le code météo / expander est un peu hors de contrôle. J'aurais aimé que XF ait un contrôle natif Expander ...)

Je pense que l'ajout de la pression de la mémoire ou simplement appeler GC.Collect pourrait recréer le problème sur un projet plus petit. Cela peut également se produire car le OnPropertyChanged sur TypedBinding est marshalé vers le thread d'interface utilisateur

https://github.com/xamarin/Xamarin.Forms/blob/7cc9a282bdeb76405c793574ebe0d096072f4228/Xamarin.Forms.Core/TypedBinding.cs#L275

Donc avec un clair je pense à ce qui pourrait se passer

PropertyChanged file d'attente sur le thread d'interface utilisateur
Clair
GC
WeakReference perd la référence
PropertyChanged résout maintenant et lève une exception

C'est peut-être lié à ce problème?
https://github.com/xamarin/xamarin-android/issues/2049

@StephaneDelcroix pourrait avoir des informations supplémentaires à ce stade :-)

J'ai eu un peu de temps libre hier soir, et j'ai essayé d'ajouter un GC.Collect() après l'appel à Clear() dans ma repro simplifiée. Malheureusement, je n'ai pas pu reproduire le problème de cette façon.

Avez-vous attendu les finalisateurs en attente?

Nous le faisons comme ça dans nos tests juste pour être sûrs
https://github.com/xamarin/Xamarin.Forms/blob/a76db1407a76fccbf487425db1bca5d15f925127/Xamarin.Forms.Controls.Issues/Xamarin.Forms.Controls.Issues.Shared/Helpers/GarbageCsollection#

C'est un très bon appel. Mais malheureusement, même après cela, le Clear() ne déclenche pas de repro.

Alors en prenant du recul ... comment cela devrait-il fonctionner? Si une liaison contient une référence faible, alors, par définition, cet objet peut être GC. C'est donc quelque chose qui, eh bien, peut arriver, et XF ne devrait pas lancer d'exception inaccessible. Au lieu de cela, il devrait probablement simplement ignorer la notification PropertyChanged et croire que l'application sait ce qu'elle fait. Je veux dire, que peut-il faire d'autre?

Pouvez-vous joindre la reproduction que vous utilisez pour essayer de recréer?

Je vais joindre le code ce soir. Il s'agit essentiellement de la reproduction intégrée à l'application que vous avez déjà vue, extraite dans une application autonome. Mais je n'ai pas encore vu le problème repro à l'intérieur.

TypedBindingCrashes.zip

@PureWeen : que puis-je faire d'autre pour aider à diagnostiquer cela?

@mfeingol pas pour le moment, sauf si vous avez des idées sur la façon de reproduire avec l'application autonome. Il est juste un peu difficile de le réduire dans le plus grand, donc nous allons un peu plus lentement pour résoudre celui-ci.

Est-il possible que nous puissions penser à celui-ci conceptuellement, comme je l'ai mentionné dans https://github.com/xamarin/Xamarin.Forms/issues/6698#issuecomment -519359760? Ou y a-t-il encore des éléments manquants sur ce qui cause réellement le problème?

J'ai le même problème et je suis également incapable de le reproduire facilement) -:

@ysmoradi : Je suppose que vous ne pouvez pas télécharger une simple reproduction?

C'est difficile à reproduire même dans mon application de production!

J'ai également une reproduction en production, mais selon @PureWeen, il leur est difficile de comprendre le problème sans une reproduction plus simple. J'ai essayé et échoué d'en produire un. :-(

Je pense que c'est une bonne idée d'avoir le nom de la propriété + le nom du type de vue + le nom du type du contexte de liaison dans le message de l'exception, afin que nous puissions avoir de meilleures informations.

J'ai exactement le même problème, iOS et Android, en utilisant les formulaires xamarin 4.2.0.709249.
J'ai un ListView utilisant un DataTemplate pour visualiser les objets, définis dans mon xaml.
J'ai DataType défini sur la page xaml, puis un autre sur le modèle de données listview.

Je n'ai pas besoin d'appeler clear ou replace ou anyting sur la liste à laquelle je me lie, il semble suffisant d'appeler GC.Collect et d'attendre une autre méthode pour me donner l'erreur ci-dessus. (Si je n'ai pas l'appel GC.Collect, il échoue très rarement, mais il le fait de temps en temps, avec l'appel, il se charge avec succès, mais échoue lors de l'actualisation.)

Cependant, j'ai trouvé quelque chose d'intéressant, si je supprime ma liaison entre mon viewModel.IsBusy et la listview.IsRefreshing l'erreur disparaît, (mais l'indicateur d'actualisation continue de fonctionner après pull pour actualiser bien sûr).

De plus, si je supprime le type de données sur la page de contenu et que je ne le place que sur le modèle de données, l'erreur disparaît également et je peux utiliser la liaison sur la liste IsRefresing.

Pour résumer ce dont j'ai besoin dans mon application de production pour reproduire:

1. Définir DataType sur ContentPage
2. Définir la liaison sur IsRefreshing dans ListView
3. Avoir un appel GC.Collect suivi de await Task.Delay (250); dans la méthode liée à la listview RefreshCommand

@shoyheim : avez-vous un simple repro que vous pouvez poster ici?

@shoyheim : avez-vous un simple repro que vous pouvez poster ici?

@mfeingol Désolé, j'ai testé / débogué mon code de production. Je vais voir si je peux mettre un peu de temps pour faire quelque chose pour reproduire l'erreur ...

@shoyheim : avez-vous déjà eu de la chance avec ça?

@mfeingol
Non désolé, j'ai essayé, mais chaque fois que je fais une simple repro, je ne peux pas la faire planter, mais mon application de production continue de planter et de planter.
Maintenant, j'ai supprimé toutes mes liaisons compilées et j'utilise simplement les liaisons d'exécution dans mes fichiers xaml, et les plantages ont disparu.
J'ai passé beaucoup de temps à essayer de comprendre ce qui ne va pas, et la seule chose dont je suis sûr est qu'il existe un lien entre l'utilisation de ListView avec une liaison sur "isRefreshing" pour indiquer quand la liste est actualisée et liaisons compilées ... il semble également que les plantages se produisent au moment du garbage collection.

1- Une propriété de contexte de liaison (modèle de vue) est modifiée.
2- Nous faisons apparaître la vue pour qu'elle soit détruite.
3- GC est appelé.

1. Binding.Apply est appelé et il essaie d'obtenir l'accès aux objets requis qui ont disparu, il lève donc InvalidOperationException.
   Vous pourriez vous demander pourquoi l'étape 4 est exécutée si tard? Parce qu'il a été appelé dans Device.BeginInvokeOnMainThread, et une telle action sera ajoutée à la fin de la liste de la file d'attente d'actions du thread principal.
   J'ai pu gérer cette exception en fournissant des PlatformServices personnalisés à xf et il n'y a plus de plantage, mais cela lève une exception plus de 800 fois! Pour presque toutes les reliures tapées de la page détruite

@ysmoradi : J'ai passé un certain temps à essayer de reproduire vos étapes et je n'ai pas pu déclencher de plantages. Je suppose que vous n'avez pas d'exemple de projet.

J'ai déjà dit que je n'ai pas de dépôt simple et que cela se produit dans mon application de production, et cela se produit également de manière aléatoire.
La première fois que j'ai commencé à créer un dépôt, je n'étais pas au courant de beaucoup de choses, mais demain j'essaierai d'en créer un autre en utilisant mes nouvelles hypothèses.
Un autre conseil qui pourrait aider: sur la base de mes hypothèses, le fait d'avoir des GC simultanés a permis d'augmenter les chances de reproduire le crash. Parce qu'il peut collecter des objets sur un thread séparé. Nous devons également modifier la propriété d'un modèle de vue sur un thread / tâche séparé car Device.BeginInvokeOnMainThread transmet l'action à la fin de la file d'attente des threads principaux uniquement lorsqu'elle est appelée sur un thread autre que le thread principal.
Réessayez et faites-moi savoir si vous avez trouvé quelque chose, et j'essaierai demain.

J'ai activé le GC simultané. En utilisant vos suggestions, l'extrait de code que j'utilise fait ceci:

            Page1 page = new Page1();
            await this.Navigation.PushModalAsync(page);
            await Task.Run(() => { page.TXT = "Foo"; });
            await this.Navigation.PopModalAsync();

            GC.Collect();
            GC.WaitForPendingFinalizers();

            GC.Collect();
            GC.WaitForPendingFinalizers();

TXT est une propriété sur Page1, implémentée à l'aide d'un BindableProperty. Page1 utilise des liaisons compilées.

Toujours pas de chance.

Obtenir le même problème au hasard ici également dans mon application de production. Après avoir traversé le processus fastidieux de définition de x: Datatype partout comme recommandé dans les directives de performances, je ne peux pas dire que je suis ravi de devoir tous les supprimer à cause de ce problème.

Je mettrai à jour cela avec une application de repro si je parviens à en faire fonctionner une.

Remarque: je doute que cela soit lié, mais il semble que je n'ai commencé à voir le problème qu'après avoir commencé à utiliser des mises en page compressées. Probablement une coïncidence puisque le problème est très aléatoire, mais qui sait.

Je viens de mettre à jour mon application vers MVVM avec des liaisons compilées et obtenir la même erreur maintenant.
Exécution du dernier Xamarin.Forms: 4.2.0.848062

Avec la configuration suivante:

N'ayez pas non plus d'étapes de repro (cette version de l'application est en version bêta pendant un jour et j'ai déjà deux rapports via AppCenter à ce sujet).
Peut partager le référentiel d'applications, mais sans étapes de repro, je suppose que cela n'aiderait pas beaucoup.

Je ne comprends peut-être pas toute l'image, mais la solution simple pour cela n'est-elle pas simplement de désappliquer et de revenir lorsque la cible a été GCed, comme c'est déjà le cas sans la définition DO_NOT_CHECK_FOR_BINDING_REUSE dans TypedBinding.cs? Je ne vois pas en quoi lancer est une bonne idée ici.

@fmanseau : J'ai le même point de vue. @PureWeen?

De plus, si cela aide, un problème lié à cela dans le dépôt de Prism semble avoir des étapes de repro (cela nécessite une application Prism, mais probablement facile de suivre un modèle similaire sans).

https://github.com/PrismLibrary/Prism/issues/1688

@StephaneDelcroix @ kingces95 @wachs
Vous semblez être derrière l'implémentation de TypedBinding .

Comme vous pouvez le voir dans ce fil de discussion, de nombreux développeurs (moi y compris) ont leur application planter de temps en temps à cause d'un InvalidOperationException lancé par le TypedBinding .
Il semble que @samhouts ait raison dans son hypothèse, qu'après que le GC entre en jeu et supprime le target d'un TypedBinding (comme c'est très probablement le cas dans notre application, où nous avons un assez gros ListView avec de nombreux DataTemplates complexes), le TypedBinding lance un InvalidOperationException qui n'est jamais attrapé et conduit à un crash d'application sur Android (et potentiellement sur toute autre plateforme ??) comme ça:

TypedBinding 2[TSource,TProperty].Apply (System.Boolean fromTarget) System.InvalidOperationException: Operation is not valid due to the current state of the object. Stack traces TypedBinding 2 [TSource, TProperty] .Apply (System.Boolean fromTarget)
TypedBinding`2 + PropertyChangedProxy [TSource, TProperty].b__16_0 ()
Thread + RunnableImplementor.Run ()
IRunnableInvoker.n_Run (System.IntPtr jnienv, System.IntPtr native__this)
(méthode-dynamique de wrapper) Android.Runtime.DynamicMethodNameCounter.43 (intptr, intptr)

Maintenant, @mfeingol demande raisonnablement pourquoi il y a un InvalidOperationException qui provoque ce crash après tout. Je veux dire qu'il n'était pas autorisé sur le plan conceptuel de ramasser la cible, pourquoi utiliser une référence faible?

Je suis moi-même un développeur WPF depuis .NET 3.0 et je sais que les exceptions de liaison n'ont jamais provoqué de plantage, mais étaient uniquement enregistrées.

Donc ma question:
Y a-t-il une bonne raison pour laquelle le TypedBinding lève une exception et n'ignore pas simplement la cible si elle a été collectée?

Ou peut-être que le système de liaison lui-même devrait capturer toutes les exceptions de liaison et nous permettre aux développeurs de les avaler ou de réagir de manière appropriée?

C'est vraiment un bogue important pour notre application de production et si nécessaire, je créerais une version intermédiaire de Xamarin.Forms pour nous qui corrige ce problème. Mais pour cela je veux savoir quels effets indésirables cela pourrait avoir!

@bruzkovsky - cela peut aussi vous intéresser

De plus, @StephaneDelcroix @ kingces95 @wachs , je peux voir un drapeau
DO_NOT_CHECK_FOR_BINDING_REUSE
À quoi sert-il exactement?

J'aimerais très bien compiler Xamarin.Forms avec DO_NOT_CHECK_FOR_BINDING_REUSE défini sur true pour me débarrasser de ce bogue.
Mais quel est le processus de réflexion derrière cela? Il doit y avoir une bonne raison d'avoir ce drapeau présent, non?

Cela m'est arrivé dans un ContentPage simple avec un ListView et DataTemplateSelector.
Y a-t-il une mise à jour sur ce problème?
Comment se fait-il qu'il soit actuellement recommandé d'utiliser des liaisons compilées si ce problème est ouvert?
https://docs.microsoft.com/es-es/xamarin/xamarin-forms/app-fundamentals/data-binding/compiled-bindings

@mrjavicho : avez-vous une chance de publier un projet simple qui reproduit le problème de manière cohérente?

J'ai pu reproduire fréquemment le problème avec cet exemple.
https://github.com/usausa/TypedBindingIssue

Exécutez l'application et cliquez sur le bouton Test.
En outre, si vous supprimez le commentaire dans MainPage.Cleanup (), le problème ne se produira pas.

Voici la trace de pile que je vois en utilisant le code de @usausa . Je ne peux pas dire si c'est le même problème que ci-dessus, mais c'est définitivement un problème:

    0x16 in Xamarin.Forms.Internals.TypedBinding<TypedBindingIssueApp.View1ViewModel,string>.Apply at D:\a\1\s\Xamarin.Forms.Core\TypedBinding.cs:99,5  C#  Annotated Frame
    0x7 in Xamarin.Forms.Internals.TypedBinding<TypedBindingIssueApp.View1ViewModel,string>.PropertyChangedProxy.<OnPropertyChanged>b__16_0 at D:\a\1\s\Xamarin.Forms.Core\TypedBinding.cs:277,31   C#  Annotated Frame
    0x29 in Xamarin.Forms.DispatcherExtensions.Dispatch at D:\a\1\s\Xamarin.Forms.Core\DispatcherExtensions.cs:53,6 C#  Annotated Frame
    0x3F in Xamarin.Forms.Internals.TypedBinding<TypedBindingIssueApp.View1ViewModel,string>.PropertyChangedProxy.OnPropertyChanged at D:\a\1\s\Xamarin.Forms.Core\TypedBinding.cs:277,5    C#  Annotated Frame
    0x15 in Xamarin.Forms.BindingExpression.WeakPropertyChangedProxy.OnPropertyChanged at D:\a\1\s\Xamarin.Forms.Core\BindingExpression.cs:645,6    C#  Annotated Frame
>   0x14 in TypedBindingIssueApp.NotificationObject.RaisePropertyChanged at C:\Operations\Build\External\TypedBindingIssue\TypedBindingIssueApp\TypedBindingIssueApp\NotificationObject.cs:13,13    C#  Symbols loaded.
    0x5D in TypedBindingIssueApp.LongLifecycleModel.Next at C:\Operations\Build\External\TypedBindingIssue\TypedBindingIssueApp\TypedBindingIssueApp\LongLifecycleModel.cs:19,13    C#  Symbols loaded.
    0x2A in TypedBindingIssueApp.MainPage.Button_OnClicked at C:\Operations\Build\External\TypedBindingIssue\TypedBindingIssueApp\TypedBindingIssueApp\MainPage.xaml.cs:29,17   C#  Symbols loaded.
    0x6 in System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.InvokeMoveNext at /Users/builder/jenkins/workspace/archive-mono/2019-08/android/release/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1092,17   C#  Annotated Frame
    0x73 in System.Threading.ExecutionContext.RunInternal at /Users/builder/jenkins/workspace/archive-mono/2019-08/android/release/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:968,17   C#  Annotated Frame
    0x4 in System.Threading.ExecutionContext.Run at /Users/builder/jenkins/workspace/archive-mono/2019-08/android/release/mcs/class/referencesource/mscorlib/system/threading/executioncontext.cs:910,13    C#  Annotated Frame
    0x32 in System.Runtime.CompilerServices.AsyncMethodBuilderCore.MoveNextRunner.Run at /Users/builder/jenkins/workspace/archive-mono/2019-08/android/release/mcs/class/referencesource/mscorlib/system/runtime/compilerservices/AsyncMethodBuilder.cs:1073,25 C#  Annotated Frame
    0x6 in System.Threading.Tasks.SynchronizationContextAwaitTaskContinuation.<>c.<.cctor>b__7_0 at /Users/builder/jenkins/workspace/archive-mono/2019-08/android/release/external/corert/src/System.Private.CoreLib/src/System/Threading/Tasks/TaskContinuation.cs:379,78  C#  Annotated Frame
    0xC in Android.App.SyncContext. C#  Annotated Frame

Le repro est parfait! La première chose que j'ai remarquée, c'est que le crash se produit à des moments complètement aléatoires, parfois en appuyant plusieurs fois sur le bouton et en attendant, je l'ai donc modifié un peu pour le faire planter plus tôt (systématiquement après 29 entités):

Relancez simplement l'événement PC 80 fois comme ceci:
c# for (var i = 0; i < 80; i++) RaisePropertyChanged(nameof(Entity));

Cela planifie beaucoup plus d'événements pour le répartiteur, ce qui augmente le taux d'échec.

Lors de la désactivation de la compilation XAML pour les classes View1 et View2 , il y a un NullReferenceException levé dans BindingExpression.cs:

Toujours à la recherche d'une solution de contournement simple ...