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

Question

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

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

L'URL du WSDL utilise la machine interne nom à la place d'un DNS public:

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

Évidemment, le WSDL n'est pas accessible depuis l'extérieur de la machine avec cette.

Je suis au courant de quelques choses qui peuvent être changées si vous exécutez ce dans IIS, ou si vous connaissez l'url du service. Par exemple, l'évolution de l' <serviceMetadata> config pour spécifier l' httpGetUrl de la propriété, mais cela ne fonctionne pas comme je l'aurais pour inclure l'URL absolue. À l'aide d'une URL relative, il utilise toujours l'interne le nom de la machine. Le vrai problème est que le WSDL comprend des références d'URL avec le nom de la machine, par conséquent, le rendant inutilisable.

Il y a deux déplorables des solutions de contournement:

• Il a été suggéré que je pourrais prendre le WSDL, de l'éditer pour corriger les Url et puis la télécharger afin d'être accessible à partir d'une URL différente.

• J'ai trouvé un correctif à partir du début de 2010 a été disponible, mais il doit y avoir une meilleure façon.

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

Answer 1

Ok. J'ai été regarder cela pendant presque une semaine. J'ai enfin trouvé la réponse, car il n'est pas facilement disponible, je l'espère, c'est indexée, et économiser du temps pour les autres.

Fondamentalement, l'ensemble de ce comportement comme un problème connu avec WCF 3.0/3.5, pour lequel ils ont publié un correctif. Vous pouvez en savoir plus ici: CORRECTIF: les Uri dans un WCF document WSDL reportez-vous à inaccessibles instances internes au lieu de l'équilibreur de charge...

J'étais venu dans ce à quelques reprises au cours de ma recherche, mais ne lui a jamais donné une 2ème pensée, surtout parce que je n'avais aucune idée de comment je pourrais déployer un correctif dans Azure.

Heureusement, Microsoft modérateur sur les forums MSDN souligné que cela avait été corrigé dans .net 4.0. Cela signifiait que le "fix" recommandé dans l'article base de connaissances ci-dessus, encore appliquées, à l'exception qu'aucun correctif n'a dû être appliquée. Quelle est donc la solution? Simple, ajoutez la ligne suivante 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 qu'il a été. Cela aurait été beaucoup plus simple de recherche si elle avait été plus clair que ce problème avait été résolu. Peut-être que je n'ai pas l'oeil assez dur.

Answer 2

Le billet de blog Utilisation des en-têtes de demande pour l'adresse des métadonnées est similaire à
La réponse de Victor , 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());
 

Answer 3

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

Si c'est la dernière, 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.