Mixage dll System.Xml.Linq spécifique à Silverlight avec dll non-Silverlight System.Xml.Linq dll

Question

J'ai une couche logique qui fait référence à System.Xml.Linq dll de Silverlight et une interface graphique qui est dans WPF (d'où l'utilisation de Silverlight System.Xml.Linq dll). Lorsque je tente de passer un projet XElement de l'interface graphique à une méthode dans le projet Logic, j'obtiens (fondamentalement) des erreurs "XElement n'est pas de type XElement". Pour compliquer la matière, je suis incapable d'éditer le projet de couche logique.

La DLL non-Silverlight est à l'adresse: C: \ Program Files (x86) \ Reference Assemblies \ Microsoft \ Framework \ v3.5 \ System.Xml.Linq.dll

Silverlight DLL est à l'adresse: C: \ Program Files (x86) \ SDK Microsoft \ Silverlight \ v3.0 \ Bibliothèques \ Client \ System.Xml.Linq.dll

Je suis nouveau en C# mais je suis assez sûr que mon problème est que je Je référence différentes DLL pour accéder à l'espace de noms System.Xml.Linq. J'ai essayé de remplacer mon System.Xml.Linq.dll non-Silverlight avec System.Xml.Linq.dll de Silverlight, mais a reçu des erreurs d'assembly.

Est-il possible de résoudre ce problème en mettant au rancart mon projet d'interface graphique WPF et en créant un projet Silverlight?

Answer 1

Ils ne sont pas compatibles. Une grande partie du cadre fondamental est identique entre les deux, mais ils ne sont pas, en fait, la même chose.

Le partage de code dans différents projets, comme suggéré ci-dessus, est probablement la meilleure solution, mais faites attention à la compilation conditionnelle. Cela entraîne souvent beaucoup de complexité. Des approches comme un modèle de décorateur avec injection de dépendances pourraient être plus appropriées pour masquer les différences. Edit: Suppression de certaines informations erronées sur le profil client par rapport à Silverlight.

Answer 2

La solution est d'avoir deux versions de votre projet logique. L'une référence les bibliothèques .NET 3.5 et l'autre les bibliothèques Silverlight. Les deux projets partagent un ensemble commun de fichiers de code.

Par conséquent, vous obtenez une version pour WPF et une version pour Silverlight. Si vous avez besoin de changer le code de la logique, vous pouvez le faire une fois puis reconstruire la solution qui créera les deux versions de la bibliothèque.

Par défaut, un projet de bibliothèque Silverlight a déjà le symbole de compilation conditionnelle "SILVERLIGHT". Par conséquent, lorsque votre code logique doit gérer les différences entre les bibliothèques .NET 3.5 et silverlight, vous pouvez utiliser la compilation conditionnelle pour contourner ces différences.

Answer 3

Pouvez-vous clarifier les "erreurs d'assemblage reçues"? Vous pourrait être en mesure de faire référence à la fois en utilisant extern alias, mais c'est difficile et confuse. Avec le recul, peut-être placer cette dépendance dans l'API était une erreur. Alternativement: pouvez-vous éventuellement reconstruire la DLL logique pour le framework cible? Silverlight et WPF utilisent des frameworks fondamentalement différents.