Partage de fichiers entre Silverlight et "plain vanilla" .Net

Question

J'utilise des classes génériques comme conteneurs de données, et je les utilise pour transmettre des données depuis et vers un service wcf. En raison de la façon dont WCF mange les noms génériques du côté client dans une classe nommée quelque chose comme "ListOfBlah231546797646", j'ajoute une référence à l'assembly réel comme un "KnownType".

Silverlight doit consommer ces services, mais ne peut faire référence qu'à des "ensembles silverlight". J'ai déplacé les classes dans leur propre "assembly Silverlight" et je peux les référencer à partir de Silverlight, mais lorsque le service s'exécute, j'obtiens une erreur "Impossible de trouver l'assembly référencé" sur l'assembly System.Runtime.Serialization.

Il s'avère que Silverlight possède son propre ensemble de binaires, tous étiquetés version 2.0.5.0. Ceux-ci ne sont pas dans le GAC du service et donc l'exception est levée. Pour cette raison, je ne peux pas référencer mon "Silverlight Assembly" à partir du code de mon service. Est-ce que je peux contourner ce problème, rendant les deux saveurs compatibles croisées quand ils sont sérialisés?

Cette question est similaire, mais aucune des réponses ne vous aide. Des idées? similar question

Answer 1

La façon dont je partage le code entre Silverlight et CLR normal, est d'utiliser la fonction «ajouter en tant que lien» avec les projets C#. Donc, il finit par ressembler à ceci:

| SilverlightLib 
| File1.cs 
| File2.cs 
| ClrLib 
| File1.cs <as link> 
| File2.cs <as link> 

Alors VS fonctionne bien, et les deux ensembles de code sont compilés. La partie ennuyeuse est où le cadre Silverlight ne s'aligne pas. (WCF a certaines parties qui n'existent pas dans SL.) Dans ce cas, vous devrez utiliser le préprocesseur "#if SILVERLIGHT" pour que le code cible les deux plates-formes.

Cela a très bien fonctionné jusqu'à maintenant. De cette façon, je peux écrire du code, tester avec VSTS, mais le faire fonctionner sur SL depuis la même source.Quelques conseils:

• Toujours éditer à partir du projet SL - de cette façon, l'éditeur se limitera à SL, et vous n'obtiendrez pas de surprises plus tard.
• Parfois, vous devez fermer le fichier ouvert pour Intellisense à mettre à jour dans l'autre projet.

Answer 2

Il y a deux façons que j'ai fait par le passé.

Première et la plus simple. Ajoutez le service WCF en tant que ServiceReference dans Silverlight. Cela prendra soin de régénérer toutes les bibliothèques de classes et de les rafraîchir si nécessaire. Ensuite, stockez deux copies des classes, une en Silverlight et une dans le .net 3.5 clr. Assurez-vous ensuite que les noms et les espaces de noms DataContract correspondent. Si vous ajoutez le ServiceReference dans Silverlight, dans l'explorateur affichez le dossier ServiceReference et regardez le fichier Reference.cs, vous verrez les classes générées et pourrez les copier.

Answer 3

Vous ne savez pas si cela est possible dans votre scénario, mais avez-vous pensé à fournir vos objets sérialisés en JSON à votre client Silverlight? Ensuite, dans votre application Silverlight, vous pouvez utiliser le JsonObject dans Silverlight. De cette façon, vous évitez d'avoir un autre ensemble d'objets de modèle dans votre application Silverlight.

JsonObject user = (JsonObject)JsonObject.Load(responseStream); 
bool isMember = user["IsMember"]; 
string name = user["Name"]; 
int age = user["Age"]; 

L'exemple est de this msdn sample

La bonne chose au sujet de cette approche est que vous avez le soutien de LINQ dans silverlight, ce qui est utilisable par vos clients ajax ainsi. Il est également plus sûr que d'exposer vos objets réels à l'application Silverlight qui s'exécute sur le client.