Serialize/Deserialize

inflames2k

Könnte sich eventuell auch um reine Datenübertragung handeln, wo es sowieso direkt nach Empfang weggespeichert wird und nie wieder verwendet wird. - Könnt ich mir so vorstellen.

Beziehungsweise das nie wieder - bezieht sich auf das Programm intern. - Vielleicht kann der gegenüber ansonsten ja noch was mit der Datei dann anfangen.

Danke für eure Antwortet, aber leider weiß ich noch nicht genau, wie ich das machen muss. Also meine Anwendung bekommt übers Netzwerk in einem Stream die Bytes von einem Objekt dessen Typendefinition unbekannt ist. Wenn ich jetzt mit BinaryFormatter.Deserialize versuche, diesen Stream in ein Objekt umzuwandeln, dann gibt es eine Exception, dass er diesen Typ nicht kennt.
Und wie mir jetzt die Klasse Activator da weiterhelfen soll ist mir noch nicht ganz klar.

Auch wenn mein Programm diesen Typ noch nicht kennt, kann es sehr wohl damit was anfangen, da die Typen gemeinsame Schnittstellen haben, die auch beiden Programmen bekannt sind.

mogel

Also meine Anwendung bekommt übers Netzwerk in einem Stream die Bytes von einem Objekt dessen Typendefinition unbekannt ist. Wenn ich jetzt mit BinaryFormatter.Deserialize versuche, diesen Stream in ein Objekt umzuwandeln, dann gibt es eine Exception, dass er diesen Typ nicht kennt.

ist ja auch klar ... die Typdefinition kennt Dein Programm ja auch nicht ... hast Du ja schon richtig geschrieben ... wieso ist Dir jetzt unklar ist das da die entsprechende Exception kommt - ist mir unklar

Auch wenn mein Programm diesen Typ noch nicht kennt, kann es sehr wohl damit was anfangen, da die Typen gemeinsame Schnittstellen haben, die auch beiden Programmen bekannt sind.

was denn nun ?! ... kennt Dein Programm nun die Schnittstellen (bzw. Typ) oder kennst es die nun nicht ... beides geht nicht

Gibt es nun eine Möglichkeit, dass unbekannte Klasse dynamisch zur Laufzeit z.B. über Reflection erstellt werden?

nein ... ohne entsprechenden Bauplan (z.B. Definition) kann kein Computer oder Mensch etwas bauen ... Du wirst also den Bauplan schon entsprechend mitliefern müssen

hand, mogel

Hallo,

mogel schrieb:

Also meine Anwendung bekommt übers Netzwerk in einem Stream die Bytes von einem Objekt dessen Typendefinition unbekannt ist. Wenn ich jetzt mit BinaryFormatter.Deserialize versuche, diesen Stream in ein Objekt umzuwandeln, dann gibt es eine Exception, dass er diesen Typ nicht kennt.

ist ja auch klar ... die Typdefinition kennt Dein Programm ja auch nicht ... hast Du ja schon richtig geschrieben ... wieso ist Dir jetzt unklar ist das da die entsprechende Exception kommt - ist mir unklar

Wo schreibe ich das mir das unklar ist

mogel schrieb:

Auch wenn mein Programm diesen Typ noch nicht kennt, kann es sehr wohl damit was anfangen, da die Typen gemeinsame Schnittstellen haben, die auch beiden Programmen bekannt sind.

was denn nun ?! ... kennt Dein Programm nun die Schnittstellen (bzw. Typ) oder kennst es die nun nicht ... beides geht nicht

Wieso soll beides nicht gehen? Mein Programm kenn den Typ (Klasse) nicht, aber der unbekannte Typ implementiert ein Interface, das mein Programm sehr wohl kennt.

mogel schrieb:

Gibt es nun eine Möglichkeit, dass unbekannte Klasse dynamisch zur Laufzeit z.B. über Reflection erstellt werden?

nein ... ohne entsprechenden Bauplan (z.B. Definition) kann kein Computer oder Mensch etwas bauen ... Du wirst also den Bauplan schon entsprechend mitliefern müssen

Volltreffer, genau das war eigentlich meine Frage. Wie mache ich das? Oder gibt es dafür im keine fertige Lösung, und ich darf das mit Reflection selbst implementieren?

Gruß

mogel

CSharp6874 schrieb:

Wieso soll beides nicht gehen?

weil Du entweder den Weg nach Hause kennst oder nicht ... aber Beides geht nicht ... Dein Programm kennt also den Typ (bzw. die Typen) was über das Netzwerk kommt oder nicht ... was kennt denn Dein(e) Programm(e)?

mogel schrieb:

Volltreffer, genau das war eigentlich meine Frage. Wie mache ich das? Oder gibt es dafür im keine fertige Lösung, und ich darf das mit Reflection selbst implementieren?

wenn Du die erste Frage richtig beantwortet hast, dann kann man auch dazu was sagen

hand, mogel

PS: code ist immer gut

mogel schrieb:

CSharp6874 schrieb:

Wieso soll beides nicht gehen?

weil Du entweder den Weg nach Hause kennst oder nicht ... aber Beides geht nicht ... Dein Programm kennt also den Typ (bzw. die Typen) was über das Netzwerk kommt oder nicht ... was kennt denn Dein(e) Programm(e)?

Du weißt aber schon was Interfaces sind
Beide Anwendung implementieren eine Bibliothek, die u. a. die Interfaces definieren.

Jetzt definiert Anwendung1 eine Klasse, die dieses Interface aus der Bibliothek implementiert. Wenn diese Klasse über das Netzwerk geschickt wird, dann kennt Anwendung2 logischerweise diese Klasse nicht. Aber trotzdem kann über das gemeinsame Interface das Objekt verwendet werden.

mogel

Du kennst doch die Lösung schon - wieso machst Du es nicht einfach

CSharp6874 schrieb:

Jetzt definiert Anwendung1 eine Klasse, die dieses Interface aus der Bibliothek implementiert. Wenn diese Klasse über das Netzwerk geschickt wird, dann kennt Anwendung2 logischerweise diese Klasse nicht. Aber trotzdem kann über das gemeinsame Interface das Objekt verwendet werden.

Und wie soll Anwendung2 wissen, wie die Methoden des Interface von diesem Objekt implementiert sind? Sowas wird nicht in den Informationen eines Objekts übermittelt. Dort drin steht nur der Zustand und der Typ des Objektes. Deshalb geht das, was du vorhast, schlicht und einfach nicht.

Was du womöglich suchst sind RPCs (Remote Procedure Calls) oder schlicht und einfach .Net Remoting. Damit kannst du verteilte Objekte erstellen und auf einem Client eine Referenz zu einem Objekt auf dem Server bekommen, in dem du nur die Schnittstelle kennst. Methodenaufrufe gehen dann über den Stream, was auch immer der darstellt. Ist ein recht umfangreiches und komplexe Themengebiet.

Bekannter Vertreter dürfte wohl auch CORBA sein, unter .Net wird aber, soweit mein spärliches Wissen vorhanden ist, .Net Remoting verwendet.

Grüssli

mogel

Dravere_logoff schrieb:

Was du womöglich suchst sind RPCs (Remote Procedure Calls) oder schlicht und einfach .Net Remoting.

nein ... damit hat er immernoch das gleiche Problem ... die andere Seite kennt ads Object nicht was er durch die Leitung pustet ... eigentlich kennt er die Lösung schon - will sie aber nicht umsetzen

Dravere

mogel schrieb:

Dravere_logoff schrieb:

Was du womöglich suchst sind RPCs (Remote Procedure Calls) oder schlicht und einfach .Net Remoting.

nein ... damit hat er immernoch das gleiche Problem ... die andere Seite kennt ads Object nicht was er durch die Leitung pustet ...

Er will das Objekt ja gar nicht, er will nur die Schnittstelle/Interface ansteuern. Zumindest hat es bisher auf mich so gewirkt. Wenn er wirklich das Objekt haben will, dann bleibt ihm natürlich keine andere Wahl

Grüssli

mogel

Dravere schrieb:

Er will das Objekt ja gar nicht,

natürlich - er brauchts das Object

er will nur die Schnittstelle/Interface ansteuern.

sonst kann er es nicht ansteuern

er hat eine Klasse mit Interfaces ... das andere Programm kennt die Interfaces - aber nicht die Klasse ... er will aber die Klasse haben ... das funktioniert nicht ... er muss auch die Klasse auf der anderen Seite bekannt machen ... allerdings will es ihm nicht in den Kopf wieso er die ganze Klasse (also mit Logik) im zweiten Programm bekannt machen soll

Das Problem ist, dass ich später mal über 50 Anwendungen habe, die im Netzwerk kommunizieren werden. Jetzt kommen aber erst nach und nach die ganzen Klassendefinitionen hinzu, sodass eine Anwendung erst später die Klassendefinition "erfahren" muss.

Natürlich könnte ich diese Definitionen in eigene Bibliotheken auslagern und die den Anwendungen schicken oder anderweitig verfügbar machen, sodass ein späteres Nachladen möglich ist. Aber dann habe ich zum Schluss 20 - 30 verschiedene Bibliotheken von den ganzen Anwendungen, was auch nicht gerade schön ist. Auch kann ich nicht einfach eine einzige Bibliothek immer erweitert, weil ich dann jede Anwendung erst neu starten dürfte, bevor diese die erweitere Bibliothek kennt. Und das ist nicht möglich!

CSharp6874 schrieb:

Das Problem ist, dass ich später mal über 50 Anwendungen habe, die im Netzwerk kommunizieren werden. Jetzt kommen aber erst nach und nach die ganzen Klassendefinitionen hinzu, sodass eine Anwendung erst später die Klassendefinition "erfahren" muss.

Natürlich könnte ich diese Definitionen in eigene Bibliotheken auslagern und die den Anwendungen schicken oder anderweitig verfügbar machen, sodass ein späteres Nachladen möglich ist. Aber dann habe ich zum Schluss 20 - 30 verschiedene Bibliotheken von den ganzen Anwendungen, was auch nicht gerade schön ist.

An der Stelle hört sich das eher danach an das das zu grundeliegende Design nochmal überdacht werden muß. Dein Ansatz über Serializing wird hier wohl nicht klappen, Interface hin oder her, weil allein aufgrund eines Interfaces kein konkretes Objekt de-serializiert werden kann (wie denn auch). Beispielsweise implementiert jedes Haus das Interface Tür, aber man kann kaum das Haus "instanziieren" wenn man nur die Tür kennt...

CSharp6874 schrieb:

Auch kann ich nicht einfach eine einzige Bibliothek immer erweitert, weil ich dann jede Anwendung erst neu starten dürfte, bevor diese die erweitere Bibliothek kennt. Und das ist nicht möglich!

Das stimmt so nicht. DLL (Dynamic Link Libraries) oder auch Assemblies kann man sowohl zur Laufzeit laden als auch entladen. unmöglich ist es also nciht, jedoch könnte es "tricky" werden.

loks schrieb:

CSharp6874 schrieb:

Auch kann ich nicht einfach eine einzige Bibliothek immer erweitert, weil ich dann jede Anwendung erst neu starten dürfte, bevor diese die erweitere Bibliothek kennt. Und das ist nicht möglich!

Das stimmt so nicht. DLL (Dynamic Link Libraries) oder auch Assemblies kann man sowohl zur Laufzeit laden als auch entladen. unmöglich ist es also nciht, jedoch könnte es "tricky" werden.

Das mit dem Entladen wird aber wahrscheinlich nicht klappen, da ich die komplette Anwendungsdomäne entladen müsste. Aber das muss ich mir noch mal durch den Kopf gehen lassen, ob das in meinem Projekt so klappen könnte.

Du baust einfach eine klare trennung zwischen interface und implementation in deine Objekte ein, indem du die Implementationen, die nicht jeder kennt, einfach in eine Unterklasse verpackst, welche dann in der Interface-Klasse enthalten ist. Im einfachsten Fall einfach nur als pointer.

Dann verschickst du übers Netz jedesmal zwei Objekte. Zuerst das Interface das alle problemlos erzeugen können und direkt danach die Implementation mit whatevermethoden die einfach nur als Binärdaten behandelt und weitergeleitet werden können.

Beim resurrecten eines Interface-Objektes wird ein pointer auf ein unbekanntes Objekt kein Problem sein, kann in dem Fall mit null initialisiert werden.
Ist das Implementations-Objekt bekannt kannst du es erzeugen und den Pointer setzen.

bbetter
Breakfaster