Utilisation de la bibliothèque de classes .NET 2.0 du service Silverlight WCF, propriétés publiques restent non exposés

Question

Voici un peu subtile question que je traite, et apprécierait toute aide.

Nous avons notre projet sur le mode de production, construit avec .NET 2.0. Nous avons récemment développé une application Silverlight externe à la solution 2.0, et il est « parlant » avec un service WCF. Ce service consomme DLLs nous copions de notre solution 2.0 publier des dossiers, afin d'accéder aux fonctionnalités de notre solution originale.

Le service WCF expose plusieurs méthodes et des objets provenant de notre solution 2.0. De toute évidence, il utilise [DataContract] s et [DataMember] s en interne et ceux qui ne sont pas disponibles dans notre solution originale (car il est .NET 2.0, et à cette mise à niveau du point à 3,5 est pas une option). Heureusement assez, WCF est capable de traiter nos objets sérialisables comme si elles étaient définies comme des contrats, mais pour une raison bizarre que les variables membres (même si elle est définie comme privée!) sont en cours de sérialisation; propriétés, même public et sont réglables jamais sérialisés.

Nos classes d'objets dont nous avons besoin exposés ont [Serializable ()] définis sur eux. J'ai regardé autour et ne pouvait pas trouver une bonne solution / explication à ce sujet. Il a probablement à voir avec la façon dont 3.0 / .NET 3.5 est « voir » mes objets 2.0 (il suppose [DataMember] que sur les variables et jamais sur les propriétés).

Ma question est surtout comment exposer les propriétés publiques que, et jamais des variables privées?

Merci d'avance pour toute idée à ce sujet.

Itamar.

Answer 1

La raison de cette demeure inconnue. Nous avons contourné ce problème en dérivant de l'objet exposé (résidant dans les DLL compilés que nous utilisons à travers le projet WCF), puis recréer les propriétés et les fonctions d'aide dont nous avons besoin. Nous ajoutons également de nouvelles propriétés ou variables membres en cas de besoin. Ensuite, nous utilisons ce nouvel objet en interne (ce qui nécessite parfois d'avoir un constructeur spécialisé pour faire des copies ou des ajustements). Pas idéal, mais travailler.