Question

我有一个部署到Azure的简单服务。可通过以下方式访问：

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

WSDL的URL使用内部计算机名称而不是公共DNS：

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

显然，无法从机器外部访问WSDL。

如果您在IIS中运行此操作，或者您确实知道该服务的URL，我知道可以更改的一些内容。例如，更改<serviceMetadata>配置以指定httpGetUrl属性，但这不起作用，因为我必须包含绝对URL。使用相对URL，它仍然使用内部计算机名称。真正的问题是WSDL包含带有机器名的URL引用，因此使它无用。

有两个不合标准的解决方法：

有人建议我可以抓取WSDL，编辑它来修复URL，然后上传它，以便可以从不同的URL访问它。
我发现2010年初有一个修补程序可用，但必须有更好的方法。

如何解决使用面向公众的DNS而不是机器名？

Answer 1

确定。我已经看了将近一个星期了。我终于找到了答案，因为它不容易获得，我希望这可以编入索引并节省其他人的时间。

基本上这个整体行为是WCF 3.0 / 3.5的已知问题，为此他们发布了一个修补程序。您可以在此处找到更多信息：FIX: URIs in a WCF WSDL document refer to inaccessible internal instances instead of to the load balancer...

在我的研究过程中，我曾经遇到过几次，但从未给出第二个想法，主要是因为我不知道如何将修补程序部署到Azure中。

幸运的是，MSDN论坛的微软主持人指出，这已在.net 4.0中得到修复。这意味着上面知识库文章中推荐的“修复”仍然适用，但不必应用任何修补程序。那么解决方案是什么？很简单，将以下内容添加到配置文件中：

<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>

就是这样。如果能够更清楚地解决这个问题现在已得到解决，那将是一个更简单的搜索。也许我看起来不够努力。

Answer 2

博文Using Request Headers for Metadata Address类似于 Victor的answer，但解释默认端口是可选的并且可以省略：

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

它还说明了如何在代码中启用行为。

sh.Description.Behaviors.Add(new UseRequestHeadersForMetadataAddressBehavior());

Answer 3

您是否正在生成WSDL以便发布它，或者您只是想在另一个项目中添加引用？

如果是后者，我的建议是使用WCF ChannelFactory方法而不是“添加服务引用”。我发现它给了我更一致的可控结果。

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

我必须补充一点，我没有在Azure上试过这个。

如何将WSDL URL从内部机器名更改为public？

3 个答案: