我有一个简单的服务,我部署到Azure.可通过以下方式访问:
http://xxxxxxxxxxxxxxxxxxxxxxx.cloudapp.net/MyTestService.svc
Run Code Online (Sandbox Code Playgroud)
WSDL的URL使用内部计算机名称而不是公共DNS:
svcutil.exe http://rd001520d328923a/MyTestService.svc?wsdl
Run Code Online (Sandbox Code Playgroud)
显然,无法从机器外部访问WSDL.
我知道如果你在IIS中运行它,或者你知道服务的url,可以改变一些事情.例如,更改<serviceMetadata>配置以指定httpGetUrl属性,但这不起作用,因为我必须包括绝对URL.使用相对URL,它仍然使用内部计算机名称.真正的问题是WSDL包含带有机器名的URL引用,因此使它无用.
有两个不合标准的解决方法:
有人建议我可以抓取WSDL,编辑它来修复URL,然后上传它,以便可以从不同的URL访问它.
我发现2010年初有一个修补程序可用,但必须有一个更好的方法.
如何解决公共面向DNS使用而不是机器名称?
Vic*_*tor 65
好.我已经看了将近一个星期了.我终于找到了答案,因为它不容易获得,我希望它被索引并节省其他人的时间.
基本上这个整体行为是WCF 3.0/3.5的一个已知问题,为此他们发布了一个修补程序.您可以在此处找到更多信息:FIX:WCF WSDL文档中的URI引用无法访问的内部实例而不是负载均衡器...
在我的研究过程中,我曾经遇到过几次,但从未给出过第二个想法,主要是因为我不知道如何在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>
Run Code Online (Sandbox Code Playgroud)
就是这样.如果能够更清楚地解决这个问题现在已得到解决,那将是一个更简单的搜索.也许我看起来不够努力.
MiF*_*vil 23
博客文章使用元数据地址请求标题类似于
Victor的答案,但解释默认端口是可选的,可以省略:
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior>
<useRequestHeadersForMetadataAddress/>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
Run Code Online (Sandbox Code Playgroud)
它还说明了如何在代码中启用行为.
sh.Description.Behaviors.Add(new UseRequestHeadersForMetadataAddressBehavior());
Run Code Online (Sandbox Code Playgroud)
| 归档时间: |
|
| 查看次数: |
28285 次 |
| 最近记录: |