我有一个部署到 Azure 的简单服务。可通过以下方式访问:
http://xxxxxxxxxxxxxxxxxxxxxxx.cloudapp.net/MyTestService.svc
WSDL 的 URL 使用内部计算机名称而不是公共(public) DNS:
svcutil.exe http://rd001520d328923a/MyTestService.svc?wsdl
显然,使用此方法无法从机器外部访问 WSDL。
我知道,如果您在 IIS 中运行此服务,或者您确实知道该服务的 URL,则可以更改一些内容。例如更改 <serviceMetadata>
配置指定 httpGetUrl
属性,但这不起作用,因为我必须包含绝对 URL。使用相对 URL,它仍然使用内部计算机名称。真正的问题是 WSDL 包含带有计算机名称的 URL 引用,因此使其无用。
有两种不合标准的解决方法:
有人建议我获取 WSDL,对其进行编辑以修复 URL,然后上传它,以便可以从不同的 URL 访问它。
我发现 2010 年初的修补程序可用,但必须有更好的方法。
如何解决这个问题,使用面向公众的 DNS 而不是机器名称?
最佳答案
好的。我已经看这个近一周了。我终于找到了答案,因为它不容易获得,我希望它能被索引并为其他人节省时间。
基本上,这种整体行为是 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>
就是这样。 如果更清楚地表明这个问题现在已经得到解决,那么搜索就会简单得多。也许是我看的不够仔细。
关于wcf - 如何将 WSDL URL 从内部计算机名称更改为公共(public)计算机名称?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/5007270/