Verwenden von .NET 2.0 -Klassenbibliothek aus Silverlight WCF Service bleiben öffentliche Immobilien nicht exponiert

Question

Hier ist ein bisschen subtiles Problem, mit dem ich es zu tun habe, und würde jede Hilfe schätzen.

Wir haben unser Projekt im Produktionsmodus mit .NET 2.0. Wir haben kürzlich eine Silverlight -Anwendung extern zur 2.0 -Lösung entwickelt, und es "spricht" mit einem WCF -Dienst. Dieser Service verbraucht DLLs Wir kopieren aus unseren Ordnern der 2.0 -Lösung, um über unsere ursprüngliche Lösung auf Funktionen zuzugreifen.

Der WCF -Dienst enthält verschiedene Methoden und Objekte, die aus unserer 2.0 -Lösung stammen. Offensichtlich verwendet es [DataContract] s und [DataMember] s intern, und diese sind in unserer ursprünglichen Lösung nicht verfügbar (da es .NET 2.0 und zu diesem Zeitpunkt auf 3.5 keine Option ist). Glücklicherweise kann WCF unsere serialisierbaren Objekte so behandeln, als wären sie als Verträge definiert, aber aus irgendeinem seltsamen Grund werden nur die Mitgliedsvariablen (auch wenn sie als privat definiert!) Serialisiert; Immobilien, sogar einsetzbar und öffentlich, werden nie serialisiert.

Unsere Objektklassen, die wir exponiert müssen, haben auf ihnen [serialisierbar ()] definiert. Ich habe mich umgesehen und konnte dafür keine gute Lösung / Erklärung finden. Es hat wahrscheinlich damit zu tun, wie .NET 3.0/3.5 meine 2.0 -Objekte "sehen" (es wird [DataMember] nur für Variablen und niemals auf Eigenschaften angenommen).

Meine Frage ist hauptsächlich, wie man nur öffentliche Eigenschaften enthüllt und niemals private Variablen?

Vielen Dank im Voraus für einen Einblick dazu.

Itamar.

Answer 1

Grund dafür bleibt unbekannt. Wir haben dieses Problem umgangen, indem wir aus dem exponierten Objekt (in kompilierten DLLs, die wir über das WCF-Projekt verwenden, abgeleitet haben) und dann die von uns benötigten Eigenschaften und Helferfunktionen neu erstellt haben. Bei Bedarf fügen wir auch neue Eigenschaften oder Mitgliedsvariablen hinzu. Dann verwenden wir dieses neue Objekt intern (dies erfordert manchmal einen speziellen Konstruktor, um Kopien oder Anpassungen vorzunehmen). Nicht ideal, aber arbeiten.