web-dev-qa-db-fra.com

Comment changer l'URL WSDL du nom de la machine interne en public?

J'ai un service simple que j'ai déployé sur Azure. Il est accessible via:

http://xxxxxxxxxxxxxxxxxxxxxxx.cloudapp.net/MyTestService.svc

L'URL du WSDL utilise le nom de la machine interne au lieu d'un DNS public:

svcutil.exe http://rd001520d328923a/MyTestService.svc?wsdl

De toute évidence, le WSDL n’est pas accessible de l’extérieur de la machine avec cela.

Je suis conscient de certaines choses qui peuvent être changées si vous utilisez ceci dans IIS ou si vous connaissez l'URL du service. Par exemple, changer la configuration <serviceMetadata> pour spécifier la propriété httpGetUrl, mais cela ne fonctionnera pas car je devrais inclure l'URL absolue. En utilisant une URL relative, il utilise toujours le nom de la machine interne. Le vrai problème est que le WSDL inclut des références d’URL avec le nom de la machine, ce qui le rend inutilisable.

Il existe deux solutions de contournement insuffisantes:

  • Il a été suggéré que je puisse récupérer le WSDL, le modifier pour corriger les URL, puis le télécharger afin qu'il soit accessible à partir d'une autre URL. 

  • J'ai trouvé un correctif du début 2010 disponible, mais il doit y avoir un meilleur moyen.

Comment cela peut-il être résolu si le public faisant face à DNS est utilisé à la place du nom de la machine?

wcfazurewsdl
39
Victor

D'accord. Je regarde cela depuis presque une semaine. J'ai finalement trouvé la réponse, car ce n'est pas facile à trouver. J'espère que cela sera indexé et permettra de gagner du temps pour les autres.

Fondamentalement, ce comportement général est un problème connu de WCF 3.0/3.5, pour lequel ils ont publié un correctif. Vous pouvez en savoir plus ici: CORRECTIF: les URI dans un document WCF WSDL font référence à des instances internes inaccessibles plutôt qu'à l'équilibreur de charge ...

Je l'avais déjà rencontré à quelques reprises au cours de mes recherches, mais je n'y avais jamais pensé, surtout parce que je ne savais pas comment déployer un correctif dans Azure. 

Heureusement, un modérateur de Microsoft sur les forums MSDN a signalé que cela avait été corrigé dans .net 4.0. Cela signifiait que le "correctif" recommandé dans l'article de la Base de connaissances ci-dessus était toujours d'application, à l'exception du fait qu'aucun correctif ne devait être appliqué. Alors, quelle est la solution? Simple, ajoutez ce qui suit au fichier de configuration:

<serviceBehaviors>
   <behavior name="<name>">
     <!-- Other options would go here -->
     <useRequestHeadersForMetadataAddress>
       <defaultPorts> <!-- Use your own port numbers -->
          <add scheme="http" port="81" />
          <add scheme="https" port="444" />
        </defaultPorts>
      </useRequestHeadersForMetadataAddress>
   </behavior>
</serviceBehaviors>

Et ça y était ... La recherche aurait été beaucoup plus simple s’il avait été plus clair que ce problème avait maintenant été résolu. Peut-être que je n'ai pas cherché assez fort.

64
Victor

Le blog Utilisation des en-têtes de demande pour l'adresse de métadonnées est similaire à
Victor 's answer , mais explique que les ports par défaut sont facultatifs Et peuvent être omis:

<system.serviceModel>
  <behaviors>
       <serviceBehaviors>
          <behavior>
            <useRequestHeadersForMetadataAddress/>
          </behavior>
        </serviceBehaviors>
  </behaviors>
</system.serviceModel>

Il montre également comment activer le comportement dans le code.

sh.Description.Behaviors.Add(new UseRequestHeadersForMetadataAddressBehavior());
22
Michael Freidgeim

Générez-vous le WSDL afin de le publier ou essayez-vous simplement d'ajouter une référence à un autre projet?

Si c'est le dernier cas, ma suggestion est d'utiliser l'approche WCF ChannelFactory plutôt que "ajouter une référence de service". Je trouve que cela me donne des résultats contrôlables plus cohérents.

http://msdn.Microsoft.com/en-us/library/ms734681.aspx

Je dois ajouter que je n'ai pas essayé cela sur Azure.

0
Doobi