Senden von Objekten per TcpClient

[errox]

Hallo.

Ich möchte gerne eine gekapselte Version von einem TcpClient / TcpServer schreiben. Klappt soweit ganz Gut. Strings sende ich via Networkstream. Da Convertiere ich den String in ein bytearray und schick ihn los.

Was ich gerne machen will ist ein Objekt zu senden ( z.B. eine Instanz von einer Form oder einem Control )

Ich hab mir überlegt ich wandel das Objekt in ein Bytearray um und sende es durch den NetworkStream. Geht aber nicht so einfach.

Wie löst sowas eigentlich ein Webservice?

Gruß errox

[Mcolli]

Moin moin,

Es gibt 2 Möglichkeiten:

1. Das Debug-Atribut [serializable] der Klassen Deffinition voransetzten

[Serializable]

public class xxx

{

}

Damit kansnt Du innerhalbt Deines Programm-Codes dieser Anwendung z.B. wie folgt diese Klasse "abspeichern"

xxx meinObjekt = new xxx();

using (FileStream fs = File.Open("C:\test.xml", FileMode.OpenOrCreate))

{

[INDENT]

XmlSerializer ser = new XmlSerializer(typeof(xxx));

ser.Serialize(fs, meinObjekt );

[/INDENT]


}

und wie folgt wieder deserialisieren:

using (FileStream fs = new FileStream("C:\test.xml", FileMode.Open, FileAccess.Read))

{

[INDENT]

XmlSerializer ser = new XmlSerializer(typeof(xxx));

xxx geladen = (xxx)ser.Deserialize(fs);

[/INDENT]


}

Soweit ich weiss klappt das aber nur innerhalb des selben Projektes.

Ich bevorzuge:

2. ISerializable in Deine Klasse Implementieren:

Man erstellt ein Klassenbibilothek-Projekt das alle Klassendeffinition beinhaltet die man Serialisieren will enthält.

Sowohl bei der Sende-Anwendung als auch der Empfangsanwendung wird die DLL dieses Projektes als Verweis referenziert. Damit ist der Sende- und Empfangsanwendung der Selber Code / Bauplan für alle zu serialisierenden Objekte bekannt.

Ich habe schon mal ein Projekt dies bezüglich in dem Forum gepostet. Es dient als Beispiel und ist ---->hier <----- zu finden. Es ist nur eine DEMO d.h. es macht Schwachsinn und ist auch nicht sauber programmiert funktioniert aber wenn Du auf dem Testrechner schreibrechte auf C: hast. Unter Umständen ist bei der Sende-Anwendung ein anderer Dateipfad zum speichern der Objekt hinterlegt als bei der Empfangsanwendung..... ist easys zu finden.

Bearbeitet 21. Juni 2010 von Mcolli

[errox]

Danke für die Antwort.

ich muss mich wohl auf die erste Möglichkeit ausweisen, weil nicht jede Klasse von .NET aus das Interface ISerializable implementiert.

Was ich gerne machen will ist ein objekt an der einen Seite rein und an der anderen Seite raus. Richtig gut gekapselt halt Nicht speziell "SendDataTable" oder sonst was.

Das Serializieren vom Objekt klappt ganz gut:

        public string SerializeObject(Object input)

        {

            System.Xml.Serialization.XmlSerializer xmls = new System.Xml.Serialization.XmlSerializer(input.GetType());

            System.IO.TextWriter txt = new System.IO.StringWriter();

            xmls.Serialize(txt, input);


            return txt.ToString();

        }

Das Problem ist das Deserializieren. Woher soll die andere Seite wissen was das ist?

            XmlSerializer ser = new XmlSerializer(typeof(Object));

            System.IO.TextReader sjioj = new System.IO.StringReader(s);

            Object geladen = ser.Deserialize(sjioj);

Gibt es dafür eine Lösung?

Gruß errox

[Pointerman]

Moin!

Ersteinmal denke ich, dass die "andere Seite" schon wissen sollte, was sie fuer Objekte haben moechte, wenn sie sie anfragt.

Du Koenntest in Deinen Klassen den Klassennamen abspeichern und mitserialisieren. Beim empfangen kannst Du dann den Klassennamen auslesen und ueber Reflection an die Klasse auf dem Zielsystem kommen.

Funktioniert dann natuerlich nur mit eigenen Klassen.

[Mcolli]

Moin!

Ersteinmal denke ich, dass die "andere Seite" schon wissen sollte, was sie fuer Objekte haben moechte, wenn sie sie anfragt.

Du Koenntest in Deinen Klassen den Klassennamen abspeichern und mitserialisieren. Beim empfangen kannst Du dann den Klassennamen auslesen und ueber Reflection an die Klasse auf dem Zielsystem kommen.

Funktioniert dann natuerlich nur mit eigenen Klassen.

Das ist ne gute Idee leider fehlen dann die Eigenschaften. Es gibt aber ne Möglichkeit NICHT als Serializable gemarkte klassen trotzdem zu Speichern .... auch Controls:

Man köntne eine Schnittstelle schreiben, die zwei Methoden beinhaltet.

Eine Methode liest mittels eines übergebenen Objektes und Reflektion die Properties der Klasse aus und speichert diese dann in einer Serializationinfo und gibt diese dann zurück. Mit der Serializationinfo und einemBinarryFormatter kann man das Objekt dann serialisieren.

Die andere Methode nutzt die SerialisationInfo und erzeugt ein Objekt des angegebenen Typs und versucht zu die in den SerialisationInfo angebenen Properties zu finden (mittels Reflection) und entsprechend zu belegen(mittels Reflection).

Weit aus besser funktioniert alles, was in den zwei Absätzen hierdrüber^^, steht zu vergessen und die SCHON EXISTIERENDE SCHNITTSTELLE

ISerializationSurrogate zu nutzen.:uli

Die Schnittstelel erzeugt nämlich so eine SerializationInfo und erinnert zudem noch an einen guten Bruce Willis film... was will man mehr?!?!

Ah ja ein Sample Code ..... ich schreib bei gelegenheit mal einen .... muss mich aber selber durchlesen wie das mit der SChnittstelle genau klappt .... ich weiss nur dass es klappt.

Bearbeitet 22. Juni 2010 von Mcolli

[Mcolli]

Wieso selber arbeiten wenn andere das für tun ... und man noch nicht mal bezahlt wird ;(

Habe bei unsern Freunden von "www.codeproject.com" einen guten SamplCode gefunden.

Je mehr Properties eine Klasse hat die man so Serialisieren will desto mehr "arbeit" hat man natürlich beim erstellen des Surrogates.