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

@mfeingol Wenn Sie dies

Ich werde versuchen, dies an diesem Wochenende zu tun, aber es ist schwierig, dies auf Anfrage zu reproduzieren. Irgendwelche Hinweise von Ihrer Seite, basierend auf Ihrem Verständnis des Codes?

Es sieht so aus, als ob dies mit der XAML-Bindung unter Verwendung eines Datentyps zusammenhängt.

Ich bin jetzt auf Reisen, aber meine vorübergehende Problemumgehung bestand darin, kompilierte Bindungen zu deaktivieren.

@mfeingol Okay, das klingt ungefähr richtig. Wenn Sie eine Chance bekommen, geben Sie bitte ein Beispielprojekt an, um das Problem einzugrenzen. Vielen Dank!

Ich sehe das gleiche Problem sowohl auf iOS als auch auf Android. Ich verwende keine kompilierten Bindungen.

AppCenter-Problem:

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)
(Wrapper Dynamic-Methode) System.Object.26 (intptr, intptr)

Xamarin Forms-Projekt, Xaml-Seite mit ViewModel - Grid mit ScrollView - ScrollView enthält Beschriftungen. Ziemlich einfach.

@samhouts : Ich habe mein Bestes versucht, kann das Problem jedoch nicht in einer Beispiel-App reproduzieren. Ich habe jedoch eine 100% ige Reproduktion in meiner Produktions-App.

Kann ich jemandem in Ihrem Team Berechtigungen für mein Azure DevOps-Projekt erteilen, damit er das Problem reproduzieren kann?

shneuvil bei microsoft.com

Sie befinden sich in: https://dev.azure.com/sideroads/Sideroads

Repro Schritte:

1. git checkout 6698-repro und bauen. Möglicherweise müssen Sie das externe Verzeichnis zu Ihrer Liste der NuGet-Verzeichnisse hinzufügen, um ein Paket abzuholen.
2. Führen Sie die App aus und erstellen Sie eine neue Reise auf der Seite "Reisen". Nennen Sie die Reise etwa "Test" und lassen Sie alle Standardeinstellungen außer Angabe von Abflug und Ankunft sowie Flughäfen (z. B. SEA und LAS).
3. Tippen Sie auf die Reise, um sie auszuwählen.
4. Gehen Sie im Hamburger-Menü zur Wetterseite und bestätigen Sie, dass Wetterberichte für die relevanten Standorte angezeigt werden.
5. Gehen Sie zu Einstellungen und ändern Sie den Wetteranbieter von NWS zu HIER.
6. Gehen Sie zurück zur Wetterseite. Sie sollten ziemlich schnell einen Absturz sehen. Ein Neustart der App sollte auf der Wetterseite erneut geöffnet werden, das Wetter aktualisieren und einen weiteren Absturz verursachen.

Wenn Sie aus irgendeinem Grund eine so einfache Reise nicht wiederholen können, exportiere ich eine anspruchsvollere für Sie mit mehr Standorten.

@PureWeen : Lass es mich wissen, wenn das bei dir nicht funktioniert.

@mtirona : Ich habe deinen Kommentar früher verpasst, sorry. Es ist seltsam, dass Sie dies sehen, ohne kompilierte Bindungen zu verwenden. Ich nehme nicht an, dass Sie ein einfaches Repro-Projekt haben, das den Absturz bei Bedarf auslöst.

@mfeingol Dieses Problem tritt zufällig in unserer Anwendung auf. Ich kann nicht einfach bei Bedarf neu erstellen - ich habe Hunderte von Abstürzen in AppCenter, die das Problem dokumentieren. Ich wäre dankbar für Anweisungen, wie das Problem verhindert werden kann ...

@mtirona :

@mfeingol Auf den übergeordneten Seiten befand sich x: DataType.

Ich bin mir sicher, dass dies mit XamlC zusammenhängt, es sei denn, Sie erstellen TypedBindings in Ihrem eigenen Code (diese werden nur vom Xaml-Compiler erstellt).

Randnotiz: Ich war in Xamarin Forms 3.6 und habe gerade auf die neueste Version 4.1 aktualisiert. Beim ersten Start meiner App sah ich diesen Absturz sofort, als ich schnell Elemente zu einer gruppierten Listenansichtseite hinzufügte. Das Problem ist also weiterhin mit 4.1.0.618606 vorhanden.

@PureWeen : Ich habe die obigen Repro-Schritte aktualisiert, um auf einen Zweig zu verweisen, den Sie repro .

@mfeingol kannst du das für mich tun?

Wenn Sie aus irgendeinem Grund eine so einfache Reise nicht wiederholen können, exportiere ich eine anspruchsvollere für Sie mit mehr Standorten.

Ich habe deine Schritte ausprobiert und nichts ist für mich abgestürzt

Okay, also @mfeingol Ich bin mir nicht sicher, wie oder warum Ihre Daten dieses Problem verursachen, aber das weiß ich bisher

Die TypedBindings verwenden eine WeakReference für das BindableObject. Wenn dies das einzige ist, das auf das BindableObject verweist, geht diese Referenz verloren.

Hier ist der Code, der abstürzt
`` `C #
if (! _weakTarget.TryGetTarget (out target))
neue InvalidOperationException () auslösen;

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;

Und wenn ich das mache, passiert der Absturz nicht.

Ich denke, dass Ihre Daten irgendwie an einen Ort gelangen, an dem das einzige, was auf die Instanz von LocationDayWeatherViewModel verweist, die an die ViewCell gebunden ist, die TypeBinding ist und das war's. Ich habe immer noch nicht ganz herausgefunden, ob dies irgendwie eine Ausnahme auf unserer Seite gegenüber Ihrer ist. Können Sie sicherstellen, dass Sie einen Verweis auf alle erstellten LocationDayWeatherViewModel beibehalten, die an ListView gebunden sind?

Vielen Dank, dass Sie sich damit befasst haben! Dieses Problem war außerhalb der vollständigen App nur schwer zu reproduzieren, daher ist es sinnvoll, dass es sich um schwache Referenzen handelt. Ich frage mich, ob das Hinzufügen von Speicherdruck zu einem einfacheren Repro zu demselben Problem führen könnte.

Das einzige Mal, dass eine Instanz von LocationDayWeatherViewModel vom Ansichtsmodell nicht referenziert wird, ist eine Aktualisierung am Wettertag, bei der der Code die gebundene ObservableCollection von Elementen löscht, bevor neue Elemente eingefügt werden. Dies geschieht tief in ExpandableGroupCollectionViewModel.Refresh falls Sie bps einstellen möchten.

Ich würde jedoch denken, dass das Löschen einer gebundenen ObservableCollection eine sichere Operation sein sollte, und es ist mir nicht klar, warum die XF-Bindungen schwache Refs verwenden würden. Das klingt so, als hätte es genau diese Art von Rennen.

Nebenbei: Ich habe versucht, die Elemente in this in eine temporäre Liste zu kopieren, bevor ich sie in Refresh , aber überraschenderweise schien das Problem nicht zu umgehen. Ich habe auf die Liste am Ende der Methode verwiesen, um sicherzustellen, dass der GC sie nicht ebenfalls nuklearisiert. Ich denke, dies wäre sinnvoll, wenn XF "später" versucht, die veraltete Bindung zu verwenden, und es würde darauf hindeuten, dass es für eine App keine gute Möglichkeit gibt, gebundene Referenzen zu stabilisieren. Aber ich kann Dinge missverstehen.

(Und ja, der Wetter- / Expander-Code ist etwas außer Kontrolle. Ich wünschte, XF hätte eine native Expander-Kontrolle ...)

Ich denke, dass das Hinzufügen von Speicherdruck oder das Aufrufen von GC.Collect das Problem bei einem kleineren Projekt erneut

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

Mit einem klaren Gedanken denke ich also darüber nach, was passieren könnte

PropertyChanged-Warteschlange im UI-Thread
klar
GC
WeakReference verliert die Referenz
PropertyChanged löst jetzt eine Ausnahme auf und löst sie aus

Vielleicht hängt es mit diesem Problem zusammen?
https://github.com/xamarin/xamarin-android/issues/2049

@StephaneDelcroix könnte an dieser Stelle einige zusätzliche Einblicke haben :-)

Ich hatte letzte Nacht ein wenig Freizeit und habe versucht, nach dem Anruf GC.Collect() zu Clear() in meinem vereinfachten Repro hinzuzufügen. Leider konnte ich das Problem nicht so reproduzieren.

Haben Sie auf die anstehenden Finalisierer gewartet?

Wir machen das in unseren Tests so, nur um ganz sicher zu sein
https://github.com/xamarin/Xamarin.Forms/blob/a76db1407a76fccbf487425db1bca5d15f925127/Xamarin.Forms.Controls.Issues/Xamarin.Forms.Controls.Issues.Shared/HelpersC

Das ist ein wirklich guter Anruf. Aber leider löst das Clear() auch danach keinen Repro aus.

Also einen Schritt zurück machen ... wie soll das funktionieren? Wenn eine Bindung eine schwache Referenz enthält, kann dieses Objekt per Definition GC-fähig sein. Das kann also passieren, und XF sollte keine unauffindbare Ausnahme auslösen. Stattdessen sollte es wahrscheinlich nur die PropertyChanged-Benachrichtigung ignorieren und darauf vertrauen, dass die App weiß, was sie tut. Ich meine, was kann es sonst noch tun?

Können Sie den Repro anhängen, mit dem Sie versuchen, ihn neu zu erstellen?

Ich werde den Code heute Abend anhängen. Es ist im Grunde das In-App-Repro, das Sie bereits gesehen haben und das in eine eigenständige App extrahiert wurde. Aber ich habe das Problem noch nicht darin gesehen.

TypedBindingCrashes.zip

@PureWeen :

@mfeingol momentan nicht, es sei denn, Sie haben Ideen, wie Sie mit der eigenständigen App Repro machen können. Es ist nur ein bisschen schwierig, es in das größere zu reduzieren, also werden wir etwas langsamer mit der Lösung dieses Problems umgehen.

Ist es möglich, dass wir dies konzeptionell durchdenken können, wie ich in https://github.com/xamarin/Xamarin.Forms/issues/6698#issuecomment -519359760 erwähnt habe? Oder fehlen noch Teile darüber, was das Problem tatsächlich verursacht?

Ich habe das gleiche Problem und kann es auch nicht so einfach reproduzieren.

@ysmoradi : Ich nehme nicht an, dass du einen einfachen Repro hochladen kannst?

Selbst in meiner Produktions-App ist es schwer zu reproduzieren!

Ich habe auch einen Repro in der Produktion, aber laut @PureWeen ist es für sie schwierig, das Problem ohne einen einfacheren Repro zu verstehen. Ich habe versucht und konnte keinen produzieren. :-(

Ich denke, es ist eine gute Idee, den Eigenschaftsnamen + den Namen des Ansichtstyps + den Typnamen des Bindungskontexts in der Nachricht der Ausnahme zu haben, damit wir bessere Einblicke erhalten.

Ich habe genau das gleiche Problem, iOS und Android, mit Xamarin-Formularen 4.2.0.709249.
Ich habe eine ListView, die eine DataTemplate verwendet, um die in meiner xaml definierten Objekte zu visualisieren.
Ich habe DataType auf der xaml-Seite und dann einen anderen auf der Listview-Datenvorlage festgelegt.

Ich muss nicht clear oder replace oder irgendetwas in der Liste aufrufen, an die ich gebunden bin. Es scheint ausreichend zu sein, GC.Collect aufzurufen und auf eine andere Methode zu warten, um mir den obigen Fehler zu geben. (Wenn ich den GC.Collect-Aufruf nicht habe, schlägt er sehr selten fehl, aber gelegentlich. Der Aufruf wird erfolgreich geladen, schlägt jedoch beim Aktualisieren fehl.)

Ich fand jedoch etwas Interessantes, wenn ich meine Bindung zwischen meinem viewModel.IsBusy und der Listenansicht entfernte. IsRefreshing Der Fehler verschwindet (aber die Aktualisierungsanzeige läuft nach dem Ziehen zur Aktualisierung natürlich weiter).

Wenn ich den Datentyp auf der Inhaltsseite entferne und ihn nur auf der Datenvorlage festlege, verschwindet der Fehler ebenfalls und ich kann die Bindung für die Listenansicht IsRefresing verwenden.

Um zusammenzufassen, was ich in meiner Produktions-App haben muss, um zu reproduzieren:

1. Legen Sie DataType auf der ContentPage fest
2. Legen Sie die Bindung für IsRefreshing in ListView fest
3. Lassen Sie GC.Collect aufrufen und warten Sie anschließend auf Task.Delay (250). in der an die Listenansicht gebundenen Methode RefreshCommand

@shoyheim : hast du einen einfachen Repro, den du hier posten kannst?

@shoyheim : hast du einen einfachen Repro, den du hier posten kannst?

@mfeingol Entschuldigung, ich habe meinen Produktionscode getestet /

@shoyheim : glück damit?

@mfeingol
Nein, tut mir leid, ich habe es versucht, aber wenn ich einen einfachen Repro mache, kann ich ihn nicht zum Absturz bringen, aber meine Produktions-App stürzt immer wieder ab.
Jetzt habe ich alle meine kompilierten Bindungen entfernt und nur Laufzeitbindungen in meinen xaml-Dateien verwendet, und die Abstürze sind verschwunden.
Ich habe viel zu viel Zeit damit verbracht, herauszufinden, was schief geht, und ich bin mir nur sicher, dass es einen Zusammenhang zwischen der Verwendung von ListView mit einer Bindung an "isRefreshing" gibt, um anzuzeigen, wann die Liste aktualisiert wird, und der Verwendung kompilierte Bindungen ... es scheint auch, dass die Abstürze um die Zeit der Speicherbereinigung auftreten.

1- Eine Eigenschaft des Bindungskontexts (Ansichtsmodell) wird geändert.
2- Wir öffnen die Ansicht, damit sie zerstört wird.
3- GC wird aufgerufen.

1. Binding.Apply wird aufgerufen und versucht, auf erforderliche Objekte zuzugreifen, die nicht mehr vorhanden sind, sodass InvalidOperationException ausgelöst wird.
   Sie fragen sich vielleicht, warum Schritt 4 so spät ausgeführt wird? Weil es in Device.BeginInvokeOnMainThread aufgerufen wurde und eine solche Aktion am Ende der Liste der Aktionswarteschlange des Hauptthreads hinzugefügt wird.
   Ich konnte diese Ausnahme behandeln, indem ich xf benutzerdefinierte PlatformServices zur Verfügung stellte, und es gibt keinen Absturz mehr, aber es wird mehr als 800 Mal eine Ausnahme ausgelöst! Für fast alle getippten Bindungen der zerstörten Seite

@ysmoradi : Ich habe einige Zeit damit verbracht, Ihre Schritte zu reproduzieren, und konnte keine Abstürze auslösen. Ich nehme nicht an, dass Sie ein Beispielprojekt haben.

Ich habe vorher gesagt, dass ich kein einfaches Repo habe und es in meiner Produktions-App passiert, und es passiert auch zufällig.
Als ich zum ersten Mal anfing, ein Repo zu erstellen, waren mir viele Dinge nicht bewusst, aber morgen werde ich versuchen, unter Verwendung meiner neuen Annahmen ein weiteres zu erstellen.
Weitere Tipps, die helfen könnten: Basierend auf meinen Annahmen hat die gleichzeitige GC die Ergebnisse erhöht und die Chance erhöht, den Absturz zu reproduzieren. Weil es Objekte in einem getrennten Thread sammeln kann. Wir müssen auch die Eigenschaft eines Ansichtsmodells für einen getrennten Thread / eine separate Aufgabe ändern, da Device.BeginInvokeOnMainThread die Aktion nur dann an das Ende der Warteschlange der Hauptthreads übergibt, wenn sie für einen anderen Thread als den Hauptthread aufgerufen wird.
Versuchen Sie es erneut und lassen Sie mich wissen, wenn Sie etwas gefunden haben, und ich werde es morgen versuchen.

Ich habe gleichzeitig GC aktiviert. Mit Ihren Vorschlägen macht das von mir verwendete Codeausschnitt Folgendes:

            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 ist eine Eigenschaft auf Seite 1, die mithilfe einer BindableProperty implementiert wird. Seite 1 verwendet kompilierte Bindungen.

Immer noch kein Glück.

Das gleiche Problem zufällig hier auch in meiner Produktions-App zu bekommen. Nachdem ich den langwierigen Prozess des Festlegens von x: Datentyp überall durchlaufen habe, wie in den Leistungsrichtlinien empfohlen, kann ich nicht sagen, dass ich begeistert bin, möglicherweise alle aufgrund dieses Problems entfernen zu müssen.

Ich werde dies mit einer Repro-App aktualisieren, wenn es mir gelingt, eine zum Laufen zu bringen.

Hinweis: Ich bezweifle, dass dies damit zusammenhängt, aber anscheinend habe ich das Problem erst gesehen, nachdem ich auch komprimierte Layouts verwendet habe. Wahrscheinlich ein Zufall, da das Problem sehr zufällig ist, aber wer weiß.

Ich habe gerade meine App mit kompilierten Bindungen auf MVVM aktualisiert und erhalte jetzt den gleichen Fehler.
Ausführen der neuesten Xamarin.Forms: 4.2.0.848062

Mit folgender Konfiguration:

Haben Sie auch keine Repro-Schritte (diese Version der App ist für einen Tag in der Beta und ich habe bereits zwei Berichte über AppCenter darüber).
Kann das App-Repository freigeben, aber ohne Repro-Schritte würde es wohl nicht viel helfen.

Ich verstehe möglicherweise nicht das ganze Bild, aber ist die einfache Lösung dafür nicht einfach, sich zu entfernen und zurückzukehren, wenn das Ziel GCed wurde, wie es bereits ohne die in TypedBinding.cs definierte Definition DO_NOT_CHECK_FOR_BINDING_REUSE der Fall ist? Ich sehe nicht, wie gut das Werfen hier ist.

@fmanseau : Ich habe die gleiche Ansicht. @PureWeen?

Auch wenn es hilft, scheint ein Problem im Zusammenhang mit Prismas Repo Repro-Schritte zu haben (es erfordert eine Prisma-App, aber wahrscheinlich ist es einfach, einem ähnlichen Muster ohne zu folgen).

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

@StephaneDelcroix @ kingces95 @wachs
Ihr scheint hinter der Implementierung von TypedBinding .

Wie Sie in diesem Thread sehen können, stürzen viele Entwickler (einschließlich mir) ab und zu ab, weil InvalidOperationException von TypedBinding geworfen wird .
Es scheint, dass @samhouts in ihrer Annahme Start des GC die target eines TypedBinding (wie es sehr wahrscheinlich in unserer App der Fall ist, in der wir eine ziemlich große haben ListView mit vielen komplexen DataTemplates ) wirft das TypedBinding ein InvalidOperationException das niemals abgefangen wird und zu einem Anwendungsabsturz auf Android (und möglicherweise jeder anderen Plattform) führt ??) so was:

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)
(Wrapper Dynamic-Methode) Android.Runtime.DynamicMethodNameCounter.43 (intptr, intptr)

Jetzt fragt @mfeingol vernünftigerweise, warum es ein InvalidOperationException , das diesen Absturz schließlich verursacht. Ich meine, es war konzeptionell nicht erlaubt, dass das Ziel Müll gesammelt wurde. Warum sollte man eine schwache Referenz verwenden?

Ich selbst bin seit .NET 3.0 ein WPF-Entwickler und weiß, dass Bindungsausnahmen nie zu einem Absturz geführt haben, sondern nur protokolliert wurden.

Also meine Frage:
Gibt es einen guten Grund, warum TypedBinding eine Ausnahme auslöst und das Ziel nicht einfach ignoriert, wenn es gesammelt wurde?

Oder sollte das Bindungssystem selbst alle Bindungsausnahmen erfassen und es uns Entwicklern ermöglichen, sie zu schlucken oder angemessen zu reagieren?

Dies ist wirklich ein wichtiger Fehler für unsere Produktions-App. Bei Bedarf würde ich eine Xamarin.Forms-Zwischenversion für uns erstellen, die dies behebt. Aber dafür möchte ich wissen, welche unerwünschten Auswirkungen dies haben könnte!

@bruzkovsky - das könnte auch für dich von Interesse sein

Außerdem, @StephaneDelcroix @ kingces95 @wachs , kann ich eine Flagge sehen
DO_NOT_CHECK_FOR_BINDING_REUSE
Wofür genau ist es?

Ich würde sehr gerne Xamarin.Forms kompilieren, wobei DO_NOT_CHECK_FOR_BINDING_REUSE auf true , um diesen Fehler zu beseitigen.
Aber was ist der Denkprozess dahinter? Es muss einen guten Grund geben, diese Flagge zu haben, oder?

Dies ist mir gerade in einer einfachen ContentPage mit ListView und DataTemplateSelector passiert.
Gibt es ein Update zu diesem Thema?
Wie kommt es, dass derzeit empfohlen wird, kompilierte Bindungen zu verwenden, wenn dieses Problem offen ist?
https://docs.microsoft.com/es-es/xamarin/xamarin-forms/app-fundamentals/data-binding/compiled-bindings

@mrjavicho :

Mit diesem Beispiel konnte ich das Problem häufig reproduzieren.
https://github.com/usausa/TypedBindingIssue

Führen Sie die Anwendung aus und klicken Sie auf die Schaltfläche Test.
Wenn Sie den Kommentar in MainPage.Cleanup () entfernen, tritt das Problem nicht auf.

Hier ist die Stapelverfolgung, die ich mit @usausas Code

    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

Der Repro ist genau richtig! Das erste, was mir auffiel, war, dass der Absturz zu völlig zufälligen Zeiten auftritt, manchmal mehrmals auf den Knopf gedrückt und gewartet wird. Deshalb habe ich ihn ein wenig optimiert, damit er früher abstürzt (konsistent nach 29 Entitäten):

Erhöhen Sie das PC-Ereignis einfach 80 Mal wie folgt:
c# for (var i = 0; i < 80; i++) RaisePropertyChanged(nameof(Entity));

Dadurch werden viel mehr Ereignisse für den Dispatcher geplant, wodurch sich die Ausfallrate erhöht.

Wenn Sie die XAML-Kompilierung für die Klassen View1 und View2 deaktivieren, wird in BindingExpression.cs ein NullReferenceException ausgelöst:

Immer noch auf der Suche nach einer einfachen Problemumgehung ...