Runtime: Frage: Serialisierungsunterstützung ab .Net Core 1.0

https://github.com/dotnet/corefx/blob/2b15de70c1cf9f585c4878a722de4dbe42b4940b/Documentation/project-docs/porting.md#binary -serialization

Hallo @joshfree , ja leider war das das Dokument, das die Verwirrung verursacht hat. Von den dortigen Vorschlägen führt JSON.NET eine JSON-Serialisierung durch, Protobuf-Net eine Binärserialisierung und Datacontractserializer eine XML-Serialisierung. Das Problem dabei ist, wenn ich eine binäre Serialisierung durchführen möchte. Während protobuf-net eine großartige Bibliothek ist, ist es begrenzt. Von Protobuf-nets repo werden folgende Typen unterstützt:
benutzerdefinierte Klassen, die:
sind als Datenvertrag gekennzeichnet
habe einen parameterlosen Konstruktor
für Silverlight: sind öffentlich
viele gebräuchliche Grundelemente usw.
eindimensionale Arrays: T []
Liste / IList
Wörterbuch / IDictionary
Jeder Typ, der IEnumerable implementiert und über eine Add (T) -Methode verfügt
In der Vergangenheit war dies in Ordnung, da der Binärformatierer immer vorhanden war, aber dies wird nicht mehr der Fall sein? Was ist die empfohlene Methode zur binären Serialisierung nicht unterstützter Typen durch protobuf-net? Bauen Sie es selbst?
Ich bin bei all diesen Technologien noch ziemlich unerfahren, daher kann es sein, dass mir der Punkt bei etwas völlig entgeht.

Außerdem kann keiner von ihnen Ausnahmen zuverlässig serialisieren (und alle relevanten Daten behalten), wie dies beispielsweise bei verteilten Computern (Azure ...) erforderlich ist.

@cdrnet Punkt ist ein großer Knackpunkt für Leute wie die Orleans Jungs IIRC.

Hallo @SamuelCox , wie die Portierungsanleitung @joshfree zeigte, haben wir (Serialisierungsteam) keinen Plan, den binären Serializer auf .NET Core zu bringen. Ohne .NET-Remoting und das Konzept von AppDomain in .NET Core ist der binäre Serializer viel weniger nützlich. Bitte berücksichtigen Sie andere Serializer in .NET Core, z. B. DataContractSerializer (DCS), DataContractJsonSerializer (DCJS) und XmlSerializer, die in .NET Core unterstützt werden und werden. Natürlich können Sie auch Serializer von Drittanbietern in Betracht ziehen, die auf .NET Core basieren. Vielleicht sollte ich die Frage stellen - suchen Sie besonders nach einem Serializer mit binär serialisierter Nutzlast (wenn ja, warum) oder suchen Sie nur nach einem Serializer, der die Typen, die Sie interessieren, serialisieren / deserialisieren kann? Wir haben uns bemüht, die Serialisierung der meisten .NET-Typen mit DCS, DCJS und XmlSerializer zu unterstützen. Bitte zögern Sie nicht, uns mitzuteilen, wenn Sie auf bestimmte Probleme stoßen, bei denen diese Serializer für Sie nicht funktionieren.

@cdrnet und @ RichiCoder1 ,

Hallo @zhenlan , ich hätte es vielleicht ursprünglich erwähnen sollen. Der Hauptgrund, warum ich Binärformatierer haben möchte, ist die (De-) Serialisierung von Ausnahmen und benutzerdefinierten Klassen, die Ausnahmen enthalten.

Der Hauptanwendungsfall sind verteilte Systeme, die ein Objekt in ein Byte-Array serialisieren, damit ich es über TCP / IP senden kann. Mir ist klar, dass es wahrscheinlich üblicher ist, das Objekt über JSON.NET in JSON zu serialisieren, diese Zeichenfolge beispielsweise in ein Byte-Array zu konvertieren, diese über tcp / ip zu senden und den gesamten Prozess einmal am anderen Ende umzukehren. Dies hat jedoch viel mehr Aufwand als nur das Serialisieren in ein Byte-Array und das Deserialisieren von einem Byte-Array in das gewünschte Objekt.

Danke @SamuelCox für die Klarstellung. Ich glaube, ich verstehe jetzt Ihre Besorgnis. Die binäre Serialisierung ist ein enges System. Ich würde Ihnen empfehlen, andere offenere standardbasierte Serialisierungen wie XML oder JSON in Betracht zu ziehen. Möglicherweise benötigen Sie es heute nicht, aber es bietet Ihnen mehr Flexibilität, falls Sie in Zukunft die Serialisierung zwischen verschiedenen Plattformen oder mit verschiedenen Programmiersprachen / Skripten unterstützen müssen. Sie sind sich nicht sicher, wie groß Ihre Daten sein werden, aber wenn die Größe der Nutzdaten wirklich ein Problem darstellt, können Sie die Datenkomprimierung in Betracht ziehen, die heutzutage für viele Server eine integrierte Funktion ist.

Ich dachte mehr an den Leistungsaufwand als an alles andere. Scheint eine Menge verschwendeter Operationen zu sein, verglichen mit der Serialisierung und Deserialisierung direkt von Objekten zu Binär und zurück. Ich denke, ich bin froh, dies jetzt zu schließen, da ich zumindest eine Klarstellung erhalten habe. Ich denke immer noch, dass es eine Lücke zwischen 4.6 und Core 1.0 gibt, die hier geöffnet wird, aber ich verstehe warum.

Etwas spät zum Gespräch, aber hier sind meine zwei Cent:

Ich denke, es wäre ein Fehler zu glauben, dass das Dienstprogramm von BinaryFormatter auf .NET-Remoting und AppDomains beschränkt ist. Was den (veralteten) BinaryFormatter von seinen neueren Gegenstücken unterscheidet, ist seine bloße Fähigkeit, die exotischeren .NET-Objekte, einschließlich Abschlüsse, Subtypen und zyklische Diagramme, zu serialisieren. Keiner der anderen im aktuellen Thread aufgelisteten Serializer ist dazu in der Lage. Es ist kein Zufall, dass viele hochmoderne verteilte Frameworks, einschließlich Microsoft-Projekte wie Prajna und Mobius (auch bekannt als SparkCLR), auf BinaryFormatter angewiesen sind, um zu funktionieren. Dies gilt nicht nur für die .NET-Welt: Spark verwendet den alten und langsamen binären Java-Serializer zum Serialisieren von Abschlüssen.

Es gibt andere Serialisierer (nicht im Binärformat), die die Funktionen von BinaryFormatter replizieren, einschließlich unserer eigenen FsPickler-Bibliothek, die vom mbrace-Framework verwendet wird. CoreCLR hat jedoch viele wichtige APIs veraltet, so dass ich die Portierung der Bibliothek auf CoreCLR für ein unpraktisches Unterfangen halte.

Aus geschäftlicher Sicht wäre es großartig zu sehen, dass CoreCLR ein tragfähiger plattformübergreifender Konkurrent von JVM im Bereich verteilter Berechnungen / Big Data wird. Dies kann nicht ohne die Plattform geschehen, die zuverlässige Serialisierungsunterstützung für POCOs und Closures (binär oder anderweitig) bietet.

Möchten Sie, dass Benutzer .NET Core tatsächlich verwenden, oder ist dies nur Zeitverschwendung wie bei Silverlight? Wenn Sie möchten, dass Benutzer .NET Core tatsächlich verwenden, sorgen Sie dafür, dass es funktioniert. Wenn Leute Serialisierung brauchen, bauen Sie sie - kein Back-Talk! Dies sind die Personen, die Ihr Produkt tatsächlich verwenden, und ihre Meinung ist weit mehr wert als die kollektive Weisheit jedes Microsoft-Mitarbeiters. Sie sehen, dass diese Leute im Gegensatz zu Microsoft tatsächlich geschäftskritische Dinge in .NET erstellen. Wenn Sie möchten, dass .NET Core etwas ist, müssen Sie aufhören, seine Nützlichkeit zu beeinträchtigen. Niemand hat Sie gebeten, .NET zu verlassen, um ein vollständiges Umschreiben durchzuführen. Sie hätten das vollständige .NET-Framework im Laufe der Zeit einfach portieren können. Du wärst inzwischen fertig.

Siehe auch https://github.com/dotnet/coreclr/issues/2715

fwiw, CSLA .NET setzt auf Serialisierung mit voller Wiedergabetreue, da es auf dem Konzept mobiler Objekte beruht.

Als Silverlight auf den Markt kam und weder BinaryFormatter noch NetDataContractSerializer hatte und all diese unangenehmen Reflexionsbeschränkungen hatten, implementierten wir unseren eigenen Serializer , der nur minimale Reflexionen verwendet und nicht auf BF oder NDCS angewiesen ist.

In einer Post-Silverlight-Welt bleibt das Problem bestehen, da BF / NDCS in UWP, WinRT, .NET Core usw. nicht zuverlässig verfügbar sind.

Ich denke, es gibt ein Argument dafür, dass ein Serializer mit voller Wiedergabetreue existieren sollte, aber er ist nur dann wirklich nützlich (zumindest imo), wenn er in all den verschiedenen Inkarnationen von .NET existiert.

@rockfordlhotka @opinionmachine @eiriktsarpalis Freut mich zu hören, dass sich mehr Menschen gleich fühlen, obwohl ich der Meinung bin, dass es produktiver wäre, wenn es etwas höflicher gesagt würde @opinionmachine , aber jeder für sich. Da dieses Problem geschlossen ist, würde ich mir vorstellen, dass das corefx-Team es nicht mehr überwacht. Ich würde Ihnen raten, Ihre Bedenken in Bezug auf dotnet / coreclr # 2715 zu korrigieren, wie von @forki erwähnt

Ich muss zustimmen, dass das Löschen der Serialisierung (sowie der Appdomains) eine schreckliche Idee war. Ich glaube wirklich nicht, dass diese Entscheidung gut durchdacht war.

Was mich jedoch wirklich zum Laufen bringt, ist, dass MS den für die Unterstützung von Appdomains usw. erforderlichen Code nicht veröffentlicht und es der Community überlassen hat, damit zu tun, was sie wollen.

Angesichts der Tatsache, dass coreclr die "Server" -Version von .net sein soll, blieben viele Serverfunktionen auf dem Boden.

Ein typisches Beispiel: Es wurde beschlossen, StackTrace / StackFrame aus corefx herauszulassen, weil es von einigen Entwicklern "missbraucht" wurde und weil es (laut MS) selten verwendet wurde. Ich glaube, sie sind bei dieser Sache zur Besinnung gekommen (nach einer Menge Gegenreaktionen), aber ich meine wirklich? Wer denkt an dieses Zeug?

Für das, was es wert ist, bin ich wirklich sehr zufrieden mit .net Core und denke, es ist ein großer Fortschritt für .net, die Leistungsverbesserungen sind brillant, es hat immer noch so ziemlich alle Funktionen, die mir wichtig sind, und es ist plattformübergreifend. Dies ist wirklich das einzige Problem, das ich damit habe. Es ist sehr wertvoll, Funktionen gegebenenfalls zu löschen. Sehen Sie sich nur an, wie erfolgreich der minimalistische Ansatz war. Nicht, dass ich sage, dass .net so minimalistisch wie möglich sein sollte, das wäre lächerlich. Ich persönlich bin mit einem minimalistischen Design nicht einverstanden, ABER ich versuche zu sagen, dass MS nicht dafür verunglimpft werden sollte, bestimmte Funktionen fallen zu lassen.

@ SamuelCox , danke! :-)

Um es noch einmal zu wiederholen: APIs fehlen in .NET Core aus vielen Gründen. Einige dieser Lücken können leicht behoben werden (und wir beheben sie). Einige sind schwerer zu reparieren. Wir möchten jedoch von Ihnen über die Probleme hören, auf die Sie stoßen (wie diese ganze Reihe von Threads zur Serialisierung), und wir möchten einen Weg finden, Ihre Szenarien zu entsperren.

Die binäre Serialisierung beliebiger Objektgraphen über Versionen eines einzelnen Frameworks hinweg ist schwierig. über verschiedene Frameworks hinweg ist noch schwieriger. Und mit "hart" meine ich nicht, dass es für uns schwierig ist, die Arbeit zu erledigen. Ich meine, es hat weitreichende Auswirkungen auf andere Ziele der Plattform (Ziele, von denen ich denke, dass wir sie alle teilen): Sicherheit, Leistung, Zuverlässigkeit.

Mit Json.NET + TypeNameHandling.All + PreserveReferencesHandling.All + MemberSerialization.Fields gelangen Sie fast vollständig dorthin. Es gibt jedoch kein FormatterServices.GetUninitializedObject, daher muss ein Konstruktor verfügbar sein.

Es gibt kein FormatterServices.GetUninitializedObject

Dies ist meines Erachtens das Kernproblem: Externe, auf Reflexion basierende Serialisierungs-Frameworks können Sie weit bringen, aber diese spezifische API muss vorhanden sein, damit diese Frameworks geschrieben werden können. Meine Empfehlung an das CoreCLR-Team wäre, diese API wieder hinzuzufügen.

Irgendwann muss sich die .NET-Community (kommerziell oder anderweitig) nicht mehr darauf verlassen, dass Microsoft ständig die Hand hält. Wenn dies so massiv erforderlich ist und seit einiger Zeit bekannt ist, dass es nicht verfügbar ist, warum gab es dann keine Community-Aktivitäten zur Bereitstellung einer Alternative? Json.NET ist eine Community-Alternative, die wir ständig nutzen. Heck der Quellcode ist sogar auf Referenzquelle verfügbar

Es scheint für andere Plattformen zu funktionieren, und ich bin sicher, dass es in .NET einwandfrei funktioniert. So wie ich es sehe, ist dies eine hervorragende Gelegenheit, ein Projekt zu erstellen (für das es eine Nachfrage zu geben scheint) und es zu bekommen frühzeitig diese Lücke mit Community-Alternativen füllen

@thecodejunkie würden wir gerne, aber wir müssten noch zur Laufzeit, um entsprechende APIs

Zu Ihrer Information: Dies funktioniert unter .NET Core: Type appDomainType = Type.GetType("System.AppDomain"); . Und ja, damit können Sie viele Dinge tun ...

Um nur zu sagen, dass wir die Reaktionsfähigkeit unseres Front-End-Servers um 30% verbessert, von 12 Kernen bei maximaler Auslastung auf 2 Kerne bei maximaler Auslastung reduziert und die Redis-Cache-Größe von 1,7 GB auf 350 MB verringert haben. Insgesamt haben wir unser Azure-Hosting um 20% (Bit) reduziert mehr wirklich)

Sie haben es erraten BinaryFormatter!

Wir haben netdatacontractserializer verwendet

Ich bin hierher gekommen, um Antworten darauf zu suchen, dass .Net 4.6.1 mit BinaryFormatter so viel langsamer ist.

Nach meinem Verständnis werden diese APIs wieder verfügbar sein (Serialisierung). Obwohl es nicht ideal ist und einige Probleme mit der Sprödigkeit hat, sollte dies zumindest ermöglichen, dass vorhandener Code weiter ausgeführt wird.

Es ist auch sinnvoll, einen weiteren einfachen Objekt-Serializer für das Kernframework zu entwerfen, der ebenfalls leichtgewichtig ist, jedoch widerstandsfähiger gegenüber maschinen- und möglicherweise versionübergreifenden Problemen ist

Neben der Sprödigkeit gibt es auch Sicherheitsprobleme.

@blowdart WRT-Sicherheit, meinen Sie solche Dinge https://blog.scrt.ch/2016/05/12/net-serialiception/?

Ja, so etwas ist es. Jedes Serialisierungsformat, das den Typ enthält, ist gefährlich, wie Java in diesem Jahr herausfindet. Ich war unglaublich glücklich, als wir die binäre Serialisierung eingestellt haben, weil wir eine ganze Klasse von Schwachstellen entfernt haben.

@migueldeicaza @blowdart @SamuelCox
Serializer werden nicht nur zum Versenden von Dingen benötigt, sondern auch für In-Proc.
Wenn die binären Serialisierer ordnungsgemäß ausgeführt werden, übertreffen sie den gesamten nativen Objekthaufen insgesamt, wenn es darum geht, 10 Millionen Objekte in Bearbeitung zu speichern.
Sieh dir das an:
https://www.infoq.com/articles/Big-Memory-Part-2

Die Serialisierungs-APIs werden für eine vernünftige Cluster-Programmierung unbedingt benötigt.
Es ist äußerst unpraktisch, Objektinstanzen CLR -> Text -> CLR zu teleportieren. Dies ist ein enormer Aufwand.
Vielleicht ist es kein Fehler, BinaryFormatter herauszunehmen, da es SEHR langsam ist und Datagramme riesig sind, aber
Dies war neben NFX.Slim der einzige Serializer auf dem Markt, der die vollständige Semantik der CLR-Serialisierung unterstützte.
Siehe die detaillierten Geschwindigkeits- und Größentabellen:
http://aumcode.github.io/serbench/

ISerialisierbar mit der [OnSer / Deser] -Familie ist für die plattforminterne Teleportation sehr sinnvoll.
Es ist nicht obligatorisch, genau wie im alten NET. Warum nicht behalten?
Zumindest in komplexen Sammlungen (dh Wörterbuch) unterstützen, ist es überhaupt nicht schwer.

Es ist absolut eine schlechte Idee, alle dazu zu bringen, JSON zu verwenden, da es manchmal langsamer ist als der binäre Serializer (nicht BinaryFormatter).
Es sieht so aus, als ob jeder Twitter-ähnliche Apps ohne Geschäftslogik erstellt.

@itadapter muss eine

@ RichiCoder1
Ja natürlich. Wie in den folgenden Diagrammen zu sehen ist, ist JIL der schnellste JSON-Serilizer, jedoch kann keiner der textbasierten Serializer binäre Serilizer berühren. Protobuf ist sehr schnell auf Kosten seiner Unfähigkeit, echten Polymorphismus und komplexe Graphen zu unterstützen.

Ich sage nur:

• Binäre Serializer sind für Geschäftsdomänenobjekte immer leistungsfähiger, insbesondere wenn Sie über viele numerische Daten verfügen
• Serializer sind im Allgemeinen NICHT NUR zum Verschieben von Daten zwischen Systemen erforderlich, sondern sogar innerhalb des Prozesses, wie der Big Memory-Ansatz zeigt. Es ist kein typischer Ansatz, aber es macht jede Menge praktischen Sinn (dh Caches und In-Memory-Social-Graph-Traversals).
• "Teleportation" ist die Technik, die MS Remoting ähnelt und ehrlich gesagt verpfuscht wurde. Remoting im Allgemeinen ist in Clustersystemen SEHR nützlich, wenn es richtig gemacht wird (ohne schreckliche Komplexität). Wir verwenden diesen Ansatz ständig und die Programmierung ist mit nativen Objekten viel einfacher - wenn Sie DOMAIN-Objekte nehmen und sie einfach so wie sie sind an eine andere Methode senden können, sei es auf diesem oder einem benachbarten Computer im Rack

Benchmarks einer "typischen Person", die beliebte Serialisierer zeigen:
http://aumcode.github.io/serbench/Specimens_Typical_Person/web/overview-charts.htm

Für den Fall, dass jemand in diesem Thread nichts davon weiß, wurde in corefx ein binärer Serializer einschließlich ISerializable usw. zur Verfügung gestellt
https://github.com/dotnet/corefx/tree/master/src/System.Runtime.Serialization.Formatters

@zhenlan Teil der .NetStandard2.0-Arbeit, nehme ich an?

@ RichiCoder1 Ja, richtig.

@ Zhenlan ist großartig!

@zhenlan Ich kann das serialisierbare Attribut in der Vorschau von Standard anscheinend nicht finden. Vermisse ich es nur?

@justinhelgerson sollte es da sein.

Haben Sie das 2.0 Preview1 SDK gemäß den Anweisungen im Ankündigungsblogbeitrag installiert?

Können Sie nach dem Erstellen eines .NET Core-Projekts sicherstellen, dass die .csproj-Datei <TargetFramework>netstandard2.0</TargetFramework> wenn Sie eine Klassenbibliothek erstellt haben, oder <TargetFramework>netcoreapp2.0</TargetFramework> wenn Sie eine Konsolen-App erstellt haben?

Übrigens, da viele Leute in diesem Thread Interesse an einem binären Serializer haben, könnten Sie an einer Diskussion in dotnet / corefx # 19119 interessiert sein, in der es darum geht, [Serializable] für .NET Core 2.0 zu verkleinern. Bitte lassen Sie es uns dort wissen, falls Sie Feedback haben.

@ zhenlan Vielen Dank für Ihre schnelle Antwort. Ich hatte die Vorschau über NuGet installiert, aber meine .csproj-Datei nicht manuell aktualisiert. Das hat funktioniert! Ich werde über das Zurückskalieren lesen und Eingaben machen, wenn sich dies auf unseren Anwendungsfall auswirken würde.

@justinhelgerson , die Scale-Back-Änderungen sind nicht in Vorschau 1 enthalten (wir arbeiten noch daran!), aber Sie sollten sie bald mit täglichen Builds oder einer zukünftigen Vorschau ausprobieren können.