Question

总结
在Azure上的IIS中托管时，如何在localhost上访问WCF服务？ Azure不会将localhost或127.0.0.1绑定到我的网站。

详情
我在Azure上托管了一个ASP.Net应用程序。我添加了一个.svc和一些我想通过WCF使用的工作流程。为了简单起见，我的网络应用程序只是在localhost上调用服务，所以我在web.config中有这样的端点;

<client>
  <endpoint address="http://localhost:8080/Router.svc/Case" binding="basicHttpBinding" contract="NewOrbit.ExVerifier.Model.Workflow.Case.ICaseWorkflow" name="Case" />
  <endpoint address="http://localhost:8080/Workflow/Case/Case_default1.xamlx" binding="basicHttpBinding" contract="*" name="Case_default1" />
</client>

这在我的本地机器上运行正常。问题是，当我将此发布到Azure时，IIS中的网站不会绑定到localhost，而是绑定始终是服务器的实际IP地址。它最终在applicationHost.config中看起来像这样：

<bindings>
   <binding protocol="http" bindingInformation="10.61.90.44:80:" />
   <binding protocol="https" bindingInformation="10.61.90.44:443:" />
   <binding protocol="http" bindingInformation="10.61.90.44:8081:" />
</bindings>

因此，只要我的网络应用尝试在localhost（或127.0.0.1）上调用该服务，它就会立即失败。不用说，如果我转到服务器并更改绑定，那么一切都很好。

我觉得奇怪的是，有很多例子，人们在Azure上的localhost上访问WCF服务，所以我无法弄清楚为什么会这样。我已经设置了osFamily到2并且为了调试这个我启用了Web发布和远程桌面访问，我认为理论上可能会搞砸了。

我已经查看了

我可以在运行时在代码中重写端点地址，用localhost替换实际地址，或者如Ron在答案中所描述的那样动态创建端点。不幸的是我正在使用WCF路由服务，因此我可以对工作流进行版本控制。这意味着我的代码调用路由器端点，而WCF路由器依次使用web.config中指定的端点调用实际的服务/工作流。我没有控制路由服务端点解析，我想，编写一整套路由逻辑，当我想要的只是调用localhost时，这似乎是很多工作：）
切换到使用命名管道;唉，它会导致工作流程出现一些奇怪的问题，可能是由于双工，而且我处于截止日期，所以没有时间在那一刻到达底层。

Answer 1

您必须动态构建端点地址。

第1步： 在ServiceDefinition.csdef中，您需要声明一个端点。

<ServiceDefinition name="MyFirstAzureWorkflow" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
  <WebRole name="WorkflowWeb" vmsize="ExtraSmall">
    <Sites>
      <Site name="Web">
        <Bindings>
          <Binding name="Endpoint1" endpointName="WorkflowService" />
        </Bindings>
      </Site>
    </Sites>
    <Endpoints>
      <InputEndpoint name="WorkflowService" protocol="http" port="80" />
    </Endpoints>
    <Imports>
      <Import moduleName="Diagnostics" />
    </Imports>
  </WebRole>
</ServiceDefinition>

第2步： 当您想要呼叫服务时

var endpoint = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["WorkflowService"].IPEndpoint;
var uri = new Uri(string.Format(
    "http://{0}:{1}/MyService.xamlx",
    endpoint.Address,
    endpoint.Port));
var proxy = new ServiceClient(
    new BasicHttpBinding(),
    new EndpointAddress(uri));

Answer 2

好的，这就是我解决它的方式。恕我直言，这是一个黑客，但至少它是有效的。

基本上，我需要添加＆＃34; *＆＃34;绑定，所以我可以在Powershell中做到这一点。一般食谱在这里：http://blogs.msdn.com/b/tomholl/archive/2011/06/28/hosting-services-with-was-and-iis-on-windows-azure.aspx

这涉及添加命名管道支持，但原理是相同的。我刚刚将Powershell脚本更改为：

import-module WebAdministration
# Set up a binding to 8080 for the services 
Get-WebSite "*Web*" | Foreach-Object { 
  $site = $_;
  $siteref = "IIS:/Sites/" + $site.Name;
  New-ItemProperty $siteref -name bindings -value @{protocol="http";bindingInformation="*:8080:"}
}

现在允许我使用http://127.0.0.1:8080/service.svc来访问我的服务。

注意：您需要按照配方的其余部分设置提升的执行上下文并更改powershell执行模式，因此请务必遵循它

在Azure上的Localhost上使用WCF

2 个答案: