WCF Transférer la classe d'un assembly ?

Bonjour,

Je souhaite transférer une classe clsPlugin en WCF chargée à partir d'un assembly.
Dans clsPlugin, j'ai positionné les DataContract et DataMember. Cela fonctionne correctement si je transferts une instance de test créée dans la classe qui implémente mon service ; par contre si dans cette dernière je charge une DLL avec

Code:

---

plugin = CType(Activator.CreateInstanceFrom(path, "plugin.clsMain").Unwrap, clsPlugin)

---

et que je veux transmettre ma classe, là j'ai une exception :

Citation:

---

Une exception de première chance de type 'System.ServiceModel.CommunicationException' s'est produite dans mscorlib.dll
L'exception System.ServiceModel.CommunicationException n'a pas été gérée
Message=Le serveur n'a pas fourni de réponse pertinente*; ceci peut être causé par des contrats qui ne correspondent pas, un arrêt prématuré de la session ou une erreur interne du serveur.

---

Auriez vous une idée ?

Merci !

Edit :
Je me demande si c'est pas un problème sur le fait que l'assembly n'est pas serializable dans l'état...

Est ce que vous avez créer un contrat et des methodes pour le transfert des instances de cette classe ? Par ce que jusqye sur vos explications je vois que vous avez simplement créer un DataContrat dans votre assembly et ce n'est pas suffisant.

Oui, j'ai tout mis dans mon service pour le transfert (ABC), et cela fonctionne bien si je ne charge pas l'assembly donc tout est bien en place : Je transferts une instance de ma classe Plugin si je l'ai instancié dans mon service comme une classe normale. Par contre si cette instance est créée par la fonction citée dans mon 1er post, le transfert échoue ensuite.
Je n'ai pas mis quoi que ce soit dans ma DLL assembly Plugin... peut être est ce la l'erreur...

Il faut maintenant se poser la question sur la nécessité d'utiliser ta fabrique d'instance. Est ce que tu ne peux pas faire autrement ?

Merci de ton intérêt.
Et bien je me suis fait une passerelle mais c'est pas le top, et c'est plus long comme code à maintenir.
En gros je charge mon assembly dans mon service, mais au lieu de le transmettre, j'ai créé plusieurs méthodes qui accèdent aux méthodes internes et qui me renvoi les données...
Sachant que mon plugin à une interface, y a t il un moyen que mon client WCF accède directement aux méthodes de l'interface Plugin sans créer une passerelle dans le service ?

Tu risques de perdre tout l'interêt de l'utilisation des WCF, tu n'auras plus affaire à des appels distants !

Passe par l'injection de dépendance via Enterprise Librairy par exemple.

Bonjour Laurent,
Ok je ne connais pas l'injection de dépendance et Enterprise Librairy. Mais si c'est des patterns, ça oblige à réécrire quand même toutes les entetes des méthodes ce qui revient même plus long que de faire "une passerelle" où dans le service je réécris aussi mes méthodes mais en plus simple :

a() implements iContrat.a
return plugin.a()

non ?

J'ai pas tout compris au problème mais pour que WCF puisse travailler avec des interfaces y'a un peu de gymnastique:

Prenons le contrat de service suivant:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

[ServiceContract] public interface IMyService { [OperationContract] IMyObj GetMyObj(); }   [DataContract] public interface IMyObject { [DataMember] String MyAttribute {get;set;} }

---

WCF ne pourra pas renvoyer un objet MyObjImpl implémentant IMyObj car en fait s'il ne connait pas les différentes implémentations il ne saura pas créer le contrat dans le WSDL.
Il faut passer par l'attribut [KnownType] comme ceci:

Code:

---

1 2 3 4 5 6 7

[DataContract] [KnownType(typeof(MyObjImpl))] public interface IMyObject { [DataMember] String MyAttribute {get;set;} }

---

Citation:

---

Envoyé par Betof

Bonjour Laurent,
Ok je ne connais pas l'injection de dépendance et Enterprise Librairy. Mais si c'est des patterns, ça oblige à réécrire quand même toutes les entetes des méthodes ce qui revient même plus long que de faire "une passerelle" où dans le service je réécris aussi mes méthodes mais en plus simple :

a() implements iContrat.a
return plugin.a()

non ?

---

Non, ta classe dois simplement implementer une interface et ensuite, ta classe doit avoir la visibilité internal voila pour commencer.

Nathanael, apparemment, le principe a été suivi, ce n'est que lorsqu'il utilise la fabrique de classe qu'il y'a des soucis, c'est pour cette raison que je lui ai proposer l'injection de dépendance.

Citation:

---

Envoyé par WOLO Laurent

Nathanael, apparemment, le principe a été suivi, ce n'est que lorsqu'il utilise la fabrique de classe qu'il y'a des soucis, c'est pour cette raison que je lui ai proposer l'injection de dépendance.

---

Généralement, lorsque l'on utilise le pattern factory c'est qu'on a une classe de base abstraite/interface et que les implémentations sont à la charge de la factory. Si il déclare juste la classe de base et pas les implémentations dans le contrat ca pose un soucis. Y'a notamment la notion de plugin qui me semble bizarre.

Nathanael,
Ah je ne connaissais pas l'attribut [KnownType], je vais voir si je m'en sors avec cette notion pour la transmission de l'interface.
En fait au début c'est pas ça que je voulais faire, je ne voulais pas passer une interface, mais directement une instance Plugin de classe clsPlugin qui se trouvait être connu dans mon client grace à une interface iPlugin intégrée en dur dans celui-ci. Mais comme l'instance chargée ne semble pas être serializable (bien qu'a ce niveau je ne sais pas ce qu'il faut faire), on est parti ensuite sur l'idée de transmettre cette interface iPlugin.

Laurent,
Je ne comprend pas le but de rendre la classe internal ou je ne vois pas de quelle classe on parle. Reprenons ce que j'ai :
iPlugin - Interface plugin
clsPlugin - Instance plugin implementant iPlugin mais instancié par un assembly load d'une classe en visibilité Public
iService - Interface service WCF
clsService - Service visibilité public

Est ce que tu peux mettre toutes tes definitions de classe et d'interfaces (sans le contenu des méthodes).

Le tag KnownType devrait être suffisant cependant utilisé de la sorte statiquement ne le sera probablement pas à moins que tu connaisses tous les types implémentant l'interface/classe abstraite à l'avance; le tag pourrait se positionner dynamiquement au moment de la fabrique d'une classe puisque c'est à ce moment que tu connais le type

Bon et bien je ne sais pas si c'est parceque je fais du Vb mais l'ide me refuse les <DataContract()> _ et autre <DataMember>_ sur une interface.

Voici un extrait de mes définitions (en vb...) :

Code:

---

1 2 3 4 5 6

Public Interface intPlugin   Function getTTL() As Integer   End Interface

---

Code:

---

1 2 3 4 5

Public MustInherit Class clsPlugin Implements intPlugin Public MustOverride Function getTTL() As Integer Implements intPlugin.getTTL End Class

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11

<ServiceContract()> _ Public Interface intPPCS   <OperationContract()> _ Function getTTL() As Integer   <OperationContract()> _ Function getPlugin() As intPlugin   End Interface

---

Code:

---

1 2 3 4 5 6 7 8 9 10

<ServiceBehavior(InstanceContextMode:=ServiceModel.InstanceContextMode.Single, IncludeExceptionDetailInFaults:=True)> _ Public Class clsPPCS Public Function getTTL() As Integer Implements intPPCS.getTTL Return plugin.getTTL End Function Public Function getPlugin() As intPlugin Implements intPPCS.getPlugin Return plugin End Function End Class

---

Voila tout le principe est en place, et getPlugin ne fonctionne pas uniquement parceque je charge un assembly. Si je crée une instance directement dans mon service, ça fonctionne. Du coup, si je ne peux pas transférer directement l'instance, je voulais transférer directement l'interface plugin pour acceder au plugin sans avoir à me réécrire toutes les méthodes (ici il n y a que getTTL pour l'exemple).
Enfin depuis l'autre jour je les ai réécrite donc ne vous embetez pas trop ;)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

<System.Runtime.Serialization.KnownType(GetType(clsPlugin))> _ <ServiceContract()> _ Public Interface intPPCS   <OperationContract()> _ Function getTTL() As Integer   <OperationContract()> _ Function getPlugin() As intPlugin   End Interface

---

Devrait marcher. Ooops ne marchera pas.

Il faudrait que tu mettes une classe de base qui encapsule ton interface intPlugin et c'est cette classe qui devrait avoir l'attribut KnownType

Citation:

---

Envoyé par Betof

Laurent,
Je ne comprend pas le but de rendre la classe internal ou je ne vois pas de quelle classe on parle. Reprenons ce que j'ai :
iPlugin - Interface plugin
clsPlugin - Instance plugin implementant iPlugin mais instancié par un assembly load d'une classe en visibilité Public
iService - Interface service WCF
clsService - Service visibilité public

---

C'était au cas ou tu voulais utiliser l'injection des dépendances.