我试图用无扩展名/ .SVC少WCF服务。任何人都可以证实或否认这个问题我遇到？

I'm trying to use extension-less / .svc-less WCF services. Can anyone else confirm or deny the issue I'm experiencing?

我用code路由，并为此在的global.asax.cs中的Application_Start：

I use routing in code, and do this in Application_Start of global.asax.cs:

RouteTable.Routes.Add(new ServiceRoute("Data", new WebServiceHostFactory(), typeof(DataDips)));

我已经测试这两个IIS 6和IIS 7.5，我可以使用的服务就好了（也就是我的扩展名的通配符映射处理程序的配置是否正确对准了ASP.NET）。然而，元数据生成完全搞砸了。我的可以的打了我的/ MEX端点与WCF测试客户端（和我presume svcutil.exe的） - 但WSDL生成你通常得到与.SVC是烤面包？我不能用一个浏览器（得到400错误的请求）打它，我不能Wsdl.exe用打它，等元数据的产生是在web.config中正确配置。

I have tested in both IIS 6 and IIS 7.5 and I can use the service just fine (ie my extension-less wildcard mapping handler config is correctly pointed at ASP.NET). However, metadata generation is totally screwed up. I can hit my /mex endpoint with the WCF Test Client (and I presume svcutil.exe) -- but the ?wsdl generation you typically get with .svc is toast. I can't hit it with a browser (get 400 bad request), I can't hit it with wsdl.exe, etc. Metadata generation is configured correctly in web.config.

这当然是一个问题，因为该服务公开为basicHttpBinding的，这样一个古老的风格ASMX客户端可以得到它。但当然，客户端无法产生无WSDL描述代理。

This is a problem of course, because the service is exposed as basicHttpBinding so that an old style ASMX client can get to it. But of course, the client can't generate the proxy without a WSDL description.

如果我改用serviceActivati​​on路由的配置是这样的，而不是注册在code路线：

If I instead use serviceActivation routing in config like this, rather than registering a route in code:

<serviceHostingEnvironment aspNetCompatibilityEnabled="true">
  <serviceActivations>
    <add relativeAddress="Data.svc" service="DataDips" />
  </serviceActivations>
</serviceHostingEnvironment>

然后瞧......它的工作原理。

Then voila... it works.

但我没有一个干净的扩展名的URL。如果我从Data.svc改变relativeAddress到的数据，然后我得到的是不支持的配置配置例外，因为它。 （必须使用注册到WCF的扩展名）。

But then I don't have a clean extensionless url. If I change relativeAddress from Data.svc to Data, then I get a configuration exception as this is not supported by config. (Must use an extension registered to WCF).

我也试图利用这个code结合上面的配置：

I've also attempted to use this code in conjunction with the above config:

RouteTable.Routes.MapPageRoute("","Data/{*data}","~/Data.svc/{*data}",false);

我的想法是，我可以只点了扩展名的URL在配置.SVC URL。这不起作用 - 在/Data.svc继续工作，但/数据返回404

My thinking is that I can just point the extensionless url at the configured .svc url. This doesn't work -- the /Data.svc continues to work, but /Data returns a 404.

我没有使用urlMappings在配置这样找到一个变通的话，结合serviceActivati​​on上面的：

I did find a work-around if using urlMappings in config like this, in conjunction with serviceActivation above:

<urlMappings>
   <add url="~/Data" mappedUrl="Data.svc"/>
</urlMappings>

这样做的问题是双重的 - 1.这似乎令人费解 2.在生成的WSDL，操作终端仍然会参考Data.svc /，而不是数据/ - 因此那里有上Data.svc依赖实际存在/响应

The problem with this is twofold - 1. It seems convoluted 2. In the generated WSDL, the operation endpoints still refer to Data.svc/, rather than Data/ -- therefore theres dependency on Data.svc actually existing / responding.

这是不是真的是我想要的，即使它还挺/八九不离十解决了这个问题。

This is not really what I want, even if it kinda / sorta solves the problem.

有没有得到扩展名的WCF服务的URL正确生成WSDL的正确方法？

Is there a proper way of getting extension-less WCF service urls to generate WSDL correctly?

推荐答案

哇，我觉得愚蠢。

我应该已经举办我与ServiceHostFactory服务，而不是WebServiceHostFactory。

I should have been hosting my service with ServiceHostFactory, NOT WebServiceHostFactory.

当我搬回从配置code ...，并交换到这条线的code：

As soon as I moved back to code from config... and swapped to this line of code:

RouteTable.Routes.Add(new ServiceRoute("Data", new ServiceHostFactory(), typeof(DataDips)));

我在业务与扩展名的URL提供了WSDL和帮助页面。

I was in business with an extensionless URL serving up WSDL and help pages.

这太糟糕了，我浪费了太多时间在这。这是我使用WebServiceHostFactory一个意外，但有MSDN中的工厂页关于精简功能上没有任何声明。 （我认为，取消WSDL是有道理的，但在取出的帮助页面没有因为他们可以简单地提供配置重命名帮助页面应该有这个名字的REST操作的属性......叹气）。

It's too bad I wasted so much time on this. It was an accident that I was using WebServiceHostFactory, but there's no disclaimer on the factory page in MSDN about the reduced functionality. (I would argue that removing WSDL makes sense, but removing the Help pages does not as they could simply provide an attribute in config to rename the 'Help' page should there be a REST operation with that name... sigh).

有一个在WebServiceHost文档的说明 http://msdn.microsoft.com/en-us/library/system.servicemodel.web.webservicehost.aspx

There is a note in the WebServiceHost docs http://msdn.microsoft.com/en-us/library/system.servicemodel.web.webservicehost.aspx