WCF Configuration des ordinateurs d'Extrémité d'Erreur: Le "contrat" de l'attribut n'est pas valide?

J'ai un service WCF appelons UserService. Le UserService a une référence à une bibliothèque de classe. Appelons ça de la DoWork.dll. Le DoWork.dll a un service WCF référence à un autre service que nous appellerons CompanyService.

Maintenant, quand j'ai essayé d'appeler le UserService je voudrais obtenir un point de terminaison n'est pas configuré message d'erreur. Après lecture sur le web, j'ai trouvé que j'ai besoin d'ajouter le CompanyService les liaisons et les informations sur le client dans le UserService's web.config en vertu de la <system.serviceModel> nœud.

Ici, il est:

<system.serviceModel>
    <bindings>
      <basicHttpBinding>
        <binding name="BasicHttpBinding_IComapnyService" />
      </basicHttpBinding>
    </bindings>
    <client>
      <endpoint name="BasicHttpBinding_ICompanyService"
          address="http://it-dev.company.local:81/Project/Copmpany/CompanyService.svc"
          binding="basicHttpBinding" 
          bindingConfiguration="BasicHttpBinding_IComapnyService"
          contract="CompanyService.ICompanyService"  />
    </client>

Le problème que j'ai est le contract="CompanyService.ICompanyService" me montre le message d'erreur:

Le "contrat" de l'attribut n'est pas valide, La valeur " CompanyService.ICompanyService' est pas valide selon son type de données 'clientContractType' - L'Énumération contrainte échoué.

Maintenant, si j'ajoute le CompanyService référence directement à la UserService WCF projet, l'erreur disparaît (évidemment). Cependant, je ne devrais pas avoir à le faire. J'ai essayé pleinement la qualification de l'espace de noms de la ICompanyService de contrat et qui ne fonctionne pas non plus. J'ai supprimé le .suo fichier et de reconstruire le projet et que cela ne fonctionne pas (proposé ailleurs sur le web). Aussi, si je tape contract=, j'obtiens la liste déroulante, mais CompanyService.ICompanyService est nulle part pour être trouvée (uniquement lorsque je fais appel à ce service directement dans le UserService projet).

J'ai essayé de la configurer à l'aide de Tools > WCF Service Configuration Editor et qui n'aide pas.

Je note que tout semble bien fonctionner, mais je n'aime pas le fait que cette fonctionnalité est de me donner le bleu enchevêtrées souligner et que le message d'erreur. J'ai un sentiment que j'ai besoin de quelque chose d'autre dans la web.config pour obtenir que cela fonctionne depuis le UserService références de la DoWork.dll, qui à son tour référence les CompanyService dont le contrat je ne peux pas voir correctement.

Toutes les suggestions sont appréciés. Merci à l'avance.

Je suis tombé sur cette récemment et a constaté que en fait y compris l'espace de nom complet est de contribuer à mes questions. Utile de noter pour quelqu'un d'autre à ce problème.

OriginalL'auteur BBauer42 | 2013-08-16

  1. 3

    Vous avez raison, vous ne devriez pas avoir à le faire.

    L'architecture d'avoir une DLL (DoWork.dll) avec un "service de référence" (ComanyService) est mauvais. Si la DLL est codé en dur le point de terminaison de client (dans le code) pour appeler la CompanyService pour vous, alors n'importe qui à l'aide de la DLL, il faut essayer de comprendre comment configurer le client de point de terminaison pour un service qu'ils ne connaissent pas. Qui est ce que votre course.

    La raison pour laquelle cela fonctionne lorsque vous ajoutez une référence de service directement à partir de votre UserService est que lorsque vous faites cela, vous obtenez une copie de la ServiceContract de la CompanyService métadonnées. Pour le prouver, regardez dans la Référence.cs fichier qui est généré, recherche pour CompanyService et vous trouverez qu'il a le [ServiceContract] attribut, l'identifiant comme un service WCF. En outre, vous pourrez voir le [OperationContract] attributs pour les méthodes, en plus de toute [DataContracts] le service my également l'échange. En d'autres termes, tous ces "types" a été importé dans votre projet et lors de la compilation, WCF est maintenant en mesure de trouver ces types lors de l'instanciation de la client endpoint.

    Si CompanyService est l'un de vos services, puis envisager l'extraction de la ServiceContract définition (interface) dans une DLL. Ensuite, vous pouvez faire référence à ces types comme "assemblée références" du service (CompanyService) et le client applications, telles que UserService. Au moins de cette façon, vous n'êtes pas avoir à ajouter une référence de service. Mais, vous devez remplir l' .... section dans votre application pour un service que vous techniquement ne peut pas savoir les détails. Pas la meilleure approche.

    Une meilleure approche consiste à déplacer la dépendance de service de la DoWork.dll. Vous pouvez le faire en déplaçant la logique dans le UserService mise en œuvre.

    Ou, si vous avez besoin de garder DoWork.dll indépendant, puis envisager d'emballage DoWork avec sur Service WCF, qui prend une dépendance sur le CompanyService. Puis, à partir de UserService, ajouter une référence de service à la nouvelle DoWork service. C'est plus en accord avec les locataires de la SOA et permettra à votre services pour évoluer indépendamment.

    Merci pour l'info. Peut-être que mon architecture est mauvais. Le CompanyService est SEULEMENT un service WCF parce que j'ai besoin de fonctionner comme un singleton avec le comportement en service de InstanceContextMode.Unique. Dans mon système, maintenant, la seule méthode de service dans CompanyService ne doit JAMAIS être appelée à partir de n'importe où d'autre que le DoWork.DLL. Donc mon suivi de la question est dois-je coder en dur le point de terminaison dans le DoWork.DLL ou dois-je faire disparaître le ComapnyService tous ensemble et en quelque sorte à déplacer sa logique dans le DoWork.dll (en quelque sorte de maintenir le singleton comportement)? Merci.
    Non, ne pas coder en dur le point de terminaison. La dernière option, je vous avais présenté est probablement va fonctionner le mieux pour votre scénario. Il y a des façons (paramètres de sécurité) pour assurer le service d'emballage DoWork.DLL est le seul service que l'on peut appeler CompanyService. Donc, quelque chose comme ça. UserService <--> NewWrapperService (dowork) <--> CompanyService

    OriginalL'auteur Rick Rainey