échec de cohabitation tcp http binding wcf [Résolu]

[splinternabs]

bonjour à tous.

je passe direct au sujet sans tergiverser, le titre est assez explicite je pense :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
<system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior name="ConfService">
          <serviceMetadata httpGetEnabled="false"/>
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <services>
      <service name="EFSolution.EFService" behaviorConfiguration="ConfService">
        <endpoint address="httpFirst" binding="netTcpBinding" contract="EFSolution.IEFService"  bindingConfiguration="tcpBind" />
        <endpoint address="netFirst" binding="wsHttpBinding" contract="EFSolution.IEFService" />
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
        <host>
          <baseAddresses>
            <add baseAddress="net.tcp://localhost:1501/EFNabs" />
            <add baseAddress="http://localhost:1500/EFNabs" />
          </baseAddresses>
        </host>
      </service>
    </services>
 
    <bindings>
      <netTcpBinding>
        <binding name="tcpBind">
          <security mode="None">
            <transport clientCredentialType="None" protectionLevel="None" />
            <message clientCredentialType="None"/>
          </security>
        </binding>
      </netTcpBinding>
    </bindings>
  </system.serviceModel>

voila mon app.conf, depuis mon client si je vais chercher l'adresse en http j'arrive à trouver mon service, si je fourni celle en tcp il me sort ceci :

'net.tcp://localhost:1501/EFNabs'.
Il n'existait pas de point de terminaison à l'écoute sur net.tcp://localhost:1501/EFNabs pouvant accepter le message. Ceci est souvent dû à une adresse ou une action SOAP incorrecte. S'il est présent, voir l'élément InnerException pour plus d'informations.
Si le service est défini dans la solution actuelle, essayez de générer la solution et d'ajouter de nouveau la référence du service.

qu'est ce que j'ai bien pu rater selon vous ?

merci de votre aide les gars

[h2s84]

Tu utilises quoi comme adresse pour accéder à ton service (côté client) via le protocole tcp net.tcp://localhost:1501/EFNabs ou net.tcp://localhost:1501/EFNabs/httpFirst ?

[splinternabs]

la 2eme adresse que tu cites n'existe pas il me semble, ce serait plutot net.tcp ... /netFirst je pense que tu voulais dire ?

si c'est le cas pour répondre à ta question j'ai essayé les 2 adresses qui me génèrent le meme message.

merci a toi.

[splinternabs]

petite correction tu avais raison en fait c'est moi qui avait inversé au niveau des adresses des endpoint, autant pour moi

donc j'ai corrigé ca, le endpoint wsHttpBinding a pour address "httpFirst" et le netTcpBinding a pour address "netFirst". et malgré cette correction les tests ne sont pas plus fructifiants ...

[h2s84]

Envoyé par splinternabs

malgré cette correction les tests ne sont pas plus fructifiants ...

Active l'exposition des métadonnées. Regarde si tu y accèdes via le navigateur. Si oui. Vérifie que dans le wsdl que tu as bien le endpoint TCP. Si oui alors regarde quelle est son adresse

[splinternabs]

à priori l'adresse est la meme que celle qu'on a cité, je te rapporte la partie qui nous interesse du wsdl :

Code :

1
2
 
<wsdl:binding name="NetTcpBinding_IEFService" type="tns:IEFService"><wsp:PolicyReference URI="#NetTcpBinding_IEFService_policy"/><soap12:binding transport="http://schemas.microsoft.com/soap/tcp"/><wsdl:operation name="getListApplications"><soap12:operation soapAction="http://tempuri.org/IEFService/getListApplications" style="document"/><wsdl:input><soap12:body use="literal"/></wsdl:input><wsdl:output><soap12:body use="literal"/></wsdl:output></wsdl:operation></wsdl:binding><wsdl:binding name="WSHttpBinding_IEFService" type="tns:IEFService"><wsp:PolicyReference URI="#WSHttpBinding_IEFService_policy"/><soap12:binding transport="http://schemas.xmlsoap.org/soap/http"/><wsdl:operation name="getListApplications"><soap12:operation soapAction="http://tempuri.org/IEFService/getListApplications" style="document"/><wsdl:input><wsp:PolicyReference URI="#WSHttpBinding_IEFService_getListApplications_Input_policy"/><soap12:body use="literal"/></wsdl:input><wsdl:output><wsp:PolicyReference URI="#WSHttpBinding_IEFService_getListApplications_output_policy"/><soap12:body use="literal"/></wsdl:output></wsdl:operation></wsdl:binding><wsdl:service name="EFService"><wsdl:port name="NetTcpBinding_IEFService" binding="tns:NetTcpBinding_IEFService"><soap12:address location="net.tcp://localhost:1501/EFNabs/netFirst"/><wsa10:EndpointReference><wsa10:Address>net.tcp://localhost:1501/EFNabs/netFirst</wsa10:Address></wsa10:EndpointReference></wsdl:port><wsdl:port name="WSHttpBinding_IEFService" binding="tns:WSHttpBinding_IEFService"><soap12:address location="http://localhost:1500/EFNabs/httpFirst"/><wsa10:EndpointReference><wsa10:Address>http://localhost:1500/EFNabs/httpFirst</wsa10:Address><Identity><Dns>localhost</Dns></Identity></wsa10:EndpointReference></wsdl:port>

j'ai tout de meme essayé l'adresse indiquée dans le wsdl (net.tcp://localhost:1501/EFNabs/netFirst) toujours pareil, mais cette fois j'ai ce message :

Metadata contient une référence qui ne peut pas être résolue*: 'net.tcp://localhost:1501/EFNabs/netFirst'.
Metadata contient une référence qui ne peut pas être résolue*: 'net.tcp://localhost:1501/EFNabs/netFirst'.
Si le service est défini dans la solution actuelle, essayez de générer la solution et d'ajouter de nouveau la référence du service.

a savoir que l'hote et le client ne font pas partie de la meme solution

[h2s84]

Mets-nous le code que tu utilises pour communiquer avec le service côté client.

[splinternabs]

tres simple, j'ai rien codé encore mdrrr. mon client c'est une appli console a laquelle j'essaie de rajouter une référence de service, et c'est à ce niveau que ca gueule, quand je fourni l'adresse en question pour la recherche du service

[h2s84]

Envoyé par splinternabs

tres simple, j'ai rien codé encore mdrrr. mon client c'est une appli console a laquelle j'essaie de rajouter une référence de service, et c'est à ce niveau que ca gueule, quand je fourni l'adresse en question pour la recherche du service

Boulet ! L'ajout de service référence marche qu'avec l'exposition des métadonnées. Dans le post où tu as mis le contenu de ton fichier config, tu as désactivé l'exposition des métadonnées. Pour que Visual Studio puisse générer ton proxy il faut lui fournir l'url d'accès aux métadonnées.

[splinternabs]

tu parles du

httpGetEnabled="false"

je suppose ?

si c'est ca, alors c'est négatif parce que je l'ai activé je ne sais quand mais quand tu m'as parlé du wsdl je voulais le mettre à true et m'étais rendu compte qu'il était déja dans cet état. . en gros j'ai fais les tests avec cette propriété a true, après si il s'agit d'une autre propriété ...

[h2s84]

tu mets à true cet attribut. Ensuite dans la fenêtre d'ajout de service de reférence tu mets l'url : http://localhost:1500/EFNabs et normalement ça devrait marcher.

[splinternabs]

ca je confirme que ca marche, mais je passe dans ce cas par le http, si je souhaite passe par le tcp, devrais je comprendre que je peux pas le faire par ajout de référence à mon client ?

[h2s84]

Envoyé par splinternabs

devrais je comprendre que je peux pas le faire par ajout de référence à mon client ?

via cette méthode à travers VS, il s'attend toujours à recevoir une url avec le protocole http(s) pour avoir accès au WSDL et donc aux métadonnées. Ce n'est pas aussi parce qu’on utilise http que cela ne marchera pas avec un bindind tcp.

[splinternabs]

justement c'est ce que je me disais aussi. on a la possibilité de faire du multibinding je ne comprenais pas pourquoi je n'arrivais pas à référencer mon service par l'adresse en tcp, jusqu'a ce que je découvre que j'avais oublié ceci :

Code :

<endpoint address="mex" binding="mexTcpBinding" contract="IMetadataExchange" />

et la c'est nickel !

merci a toi pour ton aide

[Bluedeep]

Bonjour

Ta question n'était donc pas très bien posée, car l'absence du mex n'entraine en aucun cas l'impossibilité de contacter le service.

Elle implique juste l'impossibilité de créer le client dynamiquement (impossible de requêter le WSDL).