2010-10-21 7 views
4

Peut-être que je ne comprends pas, mais j'ai un service qui est déployé sur une machine IIS 6. Cette machine a une adresse LAN et une adresse Internet publique.Les points de terminaison WCF me rendent fou

Comment diable suis-je censé pouvoir publier ce service à la fois accessible?

Au début, je pensais: Pas grand-chose, 2 points d'extrémité. J'ai donc

<endpoint 
    address="Address 1" 
    binding="wsHttpBinding" 
    bindingConfiguration="DefaultBindingConfiguration" 
    name="RemoteEndpoint" /> 

<endpoint 
    address="Address 2" 
    binding="wsHttpBinding" 
    bindingConfiguration="DefaultBindingConfiguration" 
    name="LocalEndpoint" /> 

Le code client ressemble alors à:

public void createServiceProxy() 
{ 
    if (Util.IsOperatingLocally()) 
     this.proxy = new ProxyClient("LocalEndpoint"); 
    else 
     this.proxy = new ProxyClient("RemoteEndpoint"); 
} 

Pas de dés. Impossible d'ajouter la référence de service.

Aucune liaison de protocole ne correspond à l'adresse donnée 'Adresse 1'. Les liaisons de protocole sont configurées au niveau du site dans la configuration IIS ou WAS.

Ensuite, j'ai pensé: Peut-être que la balise de l'hôte et son tag DNS aidera. Non, c'est pour l'authentification.

Ensuite, j'ai pensé: j'utiliserai net.tcp pour le point de terminaison local. Oups ... IIS 6 ne prend pas en charge net.tcp.

Puis j'ai pensé: Je sais, le constructeur ProxyClient prend une chaîne remoteAddress comme son deuxième paramètre. Maintenant, ça va ressembler à:

<endpoint 
    address="" 
    binding="wsHttpBinding" 
    bindingConfiguration="DefaultBindingConfiguration" 
    name="MyEndpointName" /> 

public void createServiceProxy() 
{ 
    if (Util.IsOperatingLocally()) 
     this.proxy = new ProxyClient("MyEndpointName", "Address 1"); 
    else 
     this.proxy = new ProxyClient("MyEndpointName", "Address 2"); 
} 

Apparemment non. Lorsque vous essayez de instancier le ProxyClient ...

Impossible de trouver le point final élément dans la section de configuration du client ServiceModel avec le nom de « MyEndpointName » et le contrat MyService.IService.

Ce qui me conduit à la app.config dont la section client généré ressemble à ceci:

<client> 
    <endpoint address="http://localhost:3471/Service.svc" binding="customBinding" 
     bindingConfiguration="MyEndpointName" contract="MyService.IService" 
     name="MyEndpointName"> 
     <identity> 
      <userPrincipalName value="DevMachine\UserNa,e" /> 
     </identity> 
    </endpoint> 
</client> 

Ce qui ne vous regarde pas droit à moi.

Ma prochaine pensée n'est pas saine. S'il vous plaît aider.

Répondre

4

Voici ce que je fais:

etc.

+1

Si vous avez raison, je nommer mon premier enfant né Otávio. –

+0

Un jour, je pourrais vous présenter le petit Otávio. Merci. –

+0

@SnOrfus - Heureux d'être de l'aide et merci pour l'honneur :-) –

1

Avez-vous réellement mettre les chaînes "Adresse 1" et "Adresse 2" dans le fichier de configuration?

Le framework analyse toujours l'adresse pour connaître le transport à utiliser. Par exemple, "http: // myurl" utilisera http, "net.pipe: // localhost/MyNamedPipeExample" utilisera IPC.

L'erreur a été provoquée car il n'y avait pas de préfixe dans la chaîne "Adresse 1".

Je crois que cela aurait fonctionné, sans avoir besoin de coder les adresses:

<endpoint 
    address="http://serverName/ServiceName/Service.svc" 
    binding="wsHttpBinding" 
    bindingConfiguration="DefaultBindingConfiguration" 
    name="RemoteEndpoint" /> 

<endpoint 
    address="http://www.companyName.com/ServiceName/Service.svc" 
    binding="wsHttpBinding" 
    bindingConfiguration="DefaultBindingConfiguration" 
    name="LocalEndpoint" /> 
+0

Non, je les appelais http: //serverName/ServiceName/Service.svc (local) et http://ServiceName.CompanyName.com/ Service.svc (distant) où il y avait forwarding setyo à l'isp pour que l'adresse distante passe à: http: //ip.ServiceNam/Service.svc. Les adresses étaient consultables. –

+0

Désolé, juste être absolument sûr (parce que le balisage pourrait avoir englouti votre commentaire). Avez-vous mis le préfixe "http: //" dans les noms d'adresses? Sinon, cela expliquerait l'erreur. –

Questions connexes