WCF Contrats multiples avec noms de méthode en double

J’ai un service avec plusieurs contrats, comme ça.

[ServiceContract] public partial interface IBusinessFunctionDAO { [OperationContract] BusinessFunction GetBusinessFunction(Int32 businessFunctionRefID); [OperationContract] IEnumerable GetProjects(Int32 businessFunctionRefID); } [ServiceContract] public partial interface IBusinessUnitDAO { [OperationContract] BusinessUnit GetBusinessUnit(Int32 businessUnitRefID); [OperationContract] IEnumerable GetProjects(Int32 businessUnitRefID); }

J’ai ensuite explicitement implémenté chacune des interfaces comme ça.

 public class TrackingTool : IBusinessFunctionDAO, IBusinessUnitDAO { BusinessFunction IBusinessFunctionDAO.GetBusinessFunction(Int32 businessFunctionRefID) { // implementation } IEnumerable IBusinessFunctionDAO.GetProjects(Int32 businessFunctionRefID) { // implementation } BusinessUnit IBusinessUnitDAO.GetBusinessUnit(Int32 businessUnitRefID) { // implementation } IEnumerable IBusinessUnitDAO.GetProjects(Int32 businessUnitRefID) { // implementation } }

Comme vous pouvez le constater, j’ai deux méthodes GetProjects (int), mais chacune d’elles est implémentée explicitement, donc la compilation est parfaite et parfaitement valide. Le problème se pose lorsque je commence réellement cela en tant que service. Cela me donne une erreur en restant que TrackingTool contient déjà une définition GetProject. Bien que ce soit vrai, cela fait partie d’un contrat de service différent. WCF ne fait-il pas la distinction entre les contrats de service lors de la génération des noms de méthodes? Existe-t-il un moyen de le différencier des contrats de services?

Mon App.Config ressemble à ceci

Toute aide serait appréciée.

Merci Raul

Je pense avoir trouvé la raison. Dans le WSDL, la fonction est exposée comme suit:

Ensuite, dans le xsd qui définit l’espace de nom tns:, nous avons ce qui suit:

Ainsi, la raison de la collision, même si le service expose deux contrats différents, est que tous les éléments de la pièce wsdl se trouvent dans le même espace de noms. Ainsi, lorsque vous créez deux noms de fonction identiques, vous obtenez des éléments en double portant le même nom, ce qui pose problème. La solution au problème consiste donc à append un atsortingbut d’espace de nom à chaque contrat de service. Si nous prenons notre contrat de service initial et le modifions comme tel.

 [ServiceContract(Namespace="Tracking/BusinessFunction")] public partial interface IBusinessFunctionDAO { [OperationContract] BusinessFunction GetBusinessFunction(Int32 businessFunctionRefID); [OperationContract] IEnumerable GetProjects(Int32 businessFunctionRefID); } [ServiceContract(Namespace="Tracking/BusinessUnit")] public partial interface IBusinessUnitDAO { [OperationContract] BusinessUnit GetBusinessUnit(Int32 businessUnitRefID); [OperationContract] IEnumerable GetProjects(Int32 businessUnitRefID); }

Lorsque nous générons le WSDL, nous obtenons un WSDL pour chaque espace de nom créé. Cet espace de noms a chaque port identifié avec toutes ses opérations et ses éléments. Ainsi, dans chacun de nos WSDL séparés, nous obtenons les éléments suivants:

 //File: Tracking.BusinessFunction.wsdl    //File: Tracking.BusinessUnit.wsdl

comme vous pouvez le constater, ils portent tous deux le même nom d’élément, mais comme ils se trouvent dans des espaces de noms différents, les éléments ne sont plus en conflit. Si nous examinons les xsd, ils ont maintenant les mêmes éléments mais avec des parameters différents:

 //File: Tracking.BusinessFunction.xsd        //File: Tracking.BusinessUnit.xsd

Donc, la réponse à ma question initiale est de faire en sorte que chaque contrat de service réside dans un espace de noms séparé afin d’éviter les éléments de port en conflit. Cela vous donne également la possibilité d’avoir vos contrats dans des WSDL distincts, qui sont plus faciles à gérer si vous en dissortingbuez des parties.

Vous pourriez peut-être utiliser un alias:

[OperationContract(Name = "YourMethodNameHere")] IEnumerable GetProjects(Int32 businessUnitRefID);

Voir: http://jeffbarnes.net/blog/post/2006/09/21/Overloading-Methods-in-WCF.aspx

Essayez de définir la propriété Action sur l’atsortingbut OperationContract pour les deux méthodes portant le même nom afin de supprimer le conflit, comme suit:

 [ServiceContract] public partial interface IBusinessFunctionDAO { [OperationContract] BusinessFunction GetBusinessFunction(Int32 businessFunctionRefID); [OperationContract(Action="GetBusinessFunctionProjects")] IEnumerable GetProjects(Int32 businessFunctionRefID); } [ServiceContract] public partial interface IBusinessUnitDAO { [OperationContract] BusinessUnit GetBusinessUnit(Int32 businessUnitRefID); [OperationContract(Action="GetBusinessUnitProjects")] IEnumerable GetProjects(Int32 businessUnitRefID); }