Physikalische Addresse mit WCF übertragen

Hallo,

ich habe eine relativ komplexe Datenstruktur, die ich mittels WCF von einem Rechner zu einem anderen übertragen will.
Die Übertragung funktioniert aber nicht, wenn ich folgende Eigenschaft im Datenvertrag definiert habe:

        [DataMember]
        public PhysicalAddress MacAddress { get; set; }

Ich habe das gelöst, indem ich einfach nur den String übertrage.

        [DataMember]
        public string MacAddress { get; set; }

Aber es würde mich trotzdem interessieren, wie ich die Klasse PhysicalAddress übertragen bekomme.
Mit der Klasse IPAddress habe ich dagegen keine Probleme.

        [DataMember]
        public List<IPAddress> IPAddresses { get; set; }

Da du nicht schreibst, warum es nicht geht, lässt sich nur vermuten, dass PhysicalAddress nicht serialisierbar ist.
Da es auch kein Serializable Attribute hat, dürfte es nicht klappen.

IPAddress hingegen hat das Attribute und kann deshalb auch Problemlos über WCF verteilt werden.

T-Virus

Es ist allgemein eine extrem schlechte Idee solche Typen (egal ob IPAddress oder PhysicalAddress) übertragen zu wollen.
Bau Dir dazu eigene, serialisierbare Daten-Objekte.

Diese sollten immer so klein und so neutral (Basis-Datentypen!) wie möglich sein, dann sind sie einfach, schnell und sicher übertragbar.
Und PhysicalAddress ist definitiv kein Basis-Datentyp! Wozu auch, wenn der einzelne Wert einfach per String darstellbar ist.

Für die MAC Adresse sollte ein einfacher String reichen oder braucht man da mehr?

T-Virus

Hallo,

danke für die Rückmeldungen!
Wie eingangs schon erwähnt, habe ich die Eigenschaft schon vor dem Post als string umdefiniert. Deshalb habe ich die Fehlermeldung nicht mehr parat. Hatte aber bei Stackoverflow schon gelesen, dass das etwas mit der Serialisierung zu tun haben könnte.
IPAddress muss ich übrigens auch rausschmeissen, denn das funktioniert nicht so, wie ich mir das vorstelle.
(Offtopic:Ich wollte eigentlich die IP vom Server haben. Aber der Server hat mehrere IP-Addressen und ich muss da irgendwie die richtige rausfinden. Wahrscheinlich ist es besser ich pinge den Server an und ermittle so die IP. Muss ich mir noch überlegen. Ist für die Anwendung nebensächlich. Fällt unter "Nice to have!")

Wie gesagt, auch das IPAddress Objekt hat in einem WCF Contract nichts zu suchen.
Das ist ein absoluter, fataler Missbrauch.

Weil wir gerade dabei sind.
Wie sieht es dann mit Collections aus? Gibt es da auch welche, die man nicht verwenden sollte?

Frag bitte konkret was Du meinst; wir können nicht hellsehen, was Du alles meinst.
Ansonsten schau Dir die WCF Basics bitte an; WCF bildet Listen als Arrays ab.
Hast Du Collections, die als Array abbildbar sind, funktioniert's.

Nun ist es ja so, dass wenn ich einen Datenvertrag zwischen zwei Rechnern habe, ich die Datenobjekte in einer separaten Assembly definieren soll/muss, damit von beiden Seiten darauf zugegriffen werden kann.
Ich habe nun in Klassen NichtBasistypen enthalten, wie z.B. PhysicalAddress, welche erst auf der Clientseite belegt werden.
Reicht es dann, wenn ich einfach nur kein DataMember-Attribut drauf setze?
Oder soll ich auf der Clientseite die Klasse umkopieren? Also die Eigenschaften des Datenvertrags kopieren und die zusätzlichen Eigenschaften hinzufügen.

Wenn es um WCF weiterhin geht, braucht nur der Server das Datenobjekt.
Der Client muss ja die Referenz des Service beziehen und hat dann über die WCF Referenz dann das Datenobjekt ebenfalls.

Wenn du deinen Code sauber umsetzt, dann kapselst du deine Übertragungsdaten in Datentransfer Objekte (DTO) die dann alle Daten für den Client enthalten.
Diese sollten dann auch auf einfachen Datentypen/Strukturen basieren.
Eben wie von Abt geschrieben, keine PhysicalAddress oder IPAdress Eigenschaften.
Wenn du solche Daten benötigst, dann bau dir eigene DTO Klassen, die eben diese Informationen als Eigenschaften liefern.

T-Virus

Hallo,

danke für die Antwort.
Ich habe es aber leider immer noch nicht kapiert.
Das ist für mich alles viel zu abstrakt.

Ich versuche es bei Gelegenheit nochmals mit einem Beispiel.
Erstmal weitergoogeln. Vielleicht finde ich doch noch den Aha-Effekt.