Ich habe eine Xamarin.Forms App basierend auf .NET Standard 1.4, die protobuf-net verwendet, um Objekte in der Datenbank zu speichern, die zu einem späteren Zeitpunkt an einen WCF-Dienst gesendet werden.
Auf Android und UWP "verwaltet" funktioniert alles gut, aber - nach dem Durchsuchen von Repositories, Artikeln und Blogposts, auf die nicht mehr zugegriffen werden kann, und auch nachdem ich versucht habe, das Precompilations-Tool zum Laufen zu bringen, habe ich einen einfache (wahrscheinlich nicht) Frage: Wie kann ich mit protobuf-net in "eingeschränkten" Umgebungen wie UWP / .NET Native und iOS / Xamarin arbeiten?
Im Moment habe ich keine großartige Lösung für dieses Szenario. Ich weiß, einige Leute haben es geschafft, aber ich bin nicht Experte genug in UWP / Native / iOS, um Ihnen zuverlässige Anweisungen "hier ist der Weg zum Erfolg" zu geben.
UWP / .NET Native und iOS teilen (wie Sie wissen) ein häufiges Problem: Mangel an voller Laufzeit emittieren. Ich verstehe warum das ist. Es ist nur: schwierig.
In der Vergangenheit hat protobuf-net versucht, dieses Problem mit einem Build-Tool zu lösen, das die vorhandenen IL-Emitters zur Laufzeit wiederholt - als Build-Time-Tool. Das war hässlich und eklig, aber es hat funktioniert . So'ne Art. Um einige Einschränkungen der Plattform zu umgehen, hat protobuf-net einige der IKVM-Tools verwendet, aber da die .NET-Framework-Szene weiter expandiert, ist dies im Grunde genommen nicht praktikabel. Plus: Das IKVM-Tool ist jetzt verlassen und wird nicht beibehalten.
Parallel dazu gibt es einen zunehmenden Anstoß, einige neuere Konzepte zu untersuchen:
async / await für asynchrone IO-Quellen: Beachten Sie, dass dies extrem unfreundlich für IL ist, aber es ist fast peinlich einfach, es in C # async / await
Im Moment bin ich sehr der Meinung, dass der beste Weg dahin ist, dass das Pre-Gen-Szenario über Build-Time-Tools auf die Ausgabe von C # umschaltet. Ich habe wiederholt bei MS um verbesserte automatisierte C # -Emissionen gebeten, die auf Roslyn basieren, aber bisher: keine Freude (ärgerlich: das asp.net-Zeug hatte sogar einen voll funktionsfähigen Proof-of-Concept, aber es ist auf Eis gelegt). So jetzt denke ich: wir müssen davon ausgehen, dass das nicht passieren wird, und schreiben es im Grunde unabhängig. Dies ist nicht unbedingt so komplex wie es klingt (und: Codegen verschiedener Formen ist mir sehr vertraut). Der Vorteil von C # liegt darin, dass ich nicht die Komplexität jedes Frameworks bekämpfen muss - ich muss es nur kompilieren (na ja, und natürlich laufen).
Also: Was hält mich zurück? In der Theorie: nichts. Ich muss dieses Zeug nur schreiben und einsetzen. In der Realität: Leben, Zeit usw. Ich bin schuldig, Dinge zu priorisieren, die mich täglich beeinflussen , und die Realität ist, dass ich nicht wirklich ein täglicher Benutzer dieser Plattformen bin, was bedeutet, dass ich es nicht bin den Schmerz fühlen, den du fühlst. Aber: Ich höre Sie laut und deutlich, und ich versuche, die v3-Arbeit zu intensivieren, die diese Punkte ansprechen sollte. Ich möchte wirklich eine gute Geschichte für diese Dinge haben - und mein Ziel ist, dass ich zu einem C # -Eitem-Modell übergehe (zumindest für Pre-Gen): es hilft mir em>. Und wenn es mir hilft, weiß ich, dass es nicht das vergessene Spielzeug auf dem Dachboden sein wird, von dem ich weiß, dass es dort ist, aber es ist schwer die Motivation zu finden zu den Schwierigkeiten des Findens.
Tags und Links c# ios xamarin.forms protobuf-net .net-native