WCF服务在IIS 7发布后无法访问，咨询IIS虚拟目录映射规则

兄弟，我懂你现在的糟心——明明用VS2013把WCF服务发布到本地IIS了，虚拟目录也建好了，但是怎么访问都报错，还想彻底搞明白IIS虚拟目录和物理目录到底是怎么映射的对吧？这就给你把规则说透，顺便结合你的情况排查下问题！

一、核心映射规则 #

这些是IIS处理虚拟目录和物理路径绑定的底层逻辑：

• 基础绑定逻辑：IIS里的虚拟目录就是父站点（比如你的"默认网站"）下的一个别名，直接关联你指定的物理路径（比如你的c:\inetpub\wwwroot\MyWCF_Service_On_IIS\）。当你访问localhost/MyWCF_Service_On_IIS/Service1.svc时，IIS会自动把这个请求转发到物理路径下的Service1.svc文件。
• 配置继承与优先级：虚拟目录会默认继承父站点的大部分配置（比如端口、身份验证规则、HTTP模块），但你也可以给它单独设置独立配置（比如不同的应用程序池、权限）。如果父站点和虚拟目录的配置冲突，虚拟目录的配置会覆盖父级。
• 应用程序池的关联：如果把虚拟目录标记为"应用程序"（WCF服务必须这么做），它会绑定到一个应用程序池。应用程序池的.NET版本、托管模式（集成/经典）必须和你的WCF服务兼容——这是很多人踩坑的点！
• 物理路径权限：IIS的应用程序池身份（默认是IIS AppPool\DefaultAppPool）必须对物理路径拥有读取权限，如果权限不足，会直接返回403或500错误，连基础请求都处理不了。
• URL匹配优先级：IIS遵循"最长匹配优先"的原则处理URL。比如你有虚拟目录MyWCF和子虚拟目录MyWCF/Test，访问localhost/MyWCF/Test/Service.svc时，会优先匹配子虚拟目录对应的物理路径。

二、结合你的WCF场景排查映射相关问题 #

既然你部署了WCF但访问失败，结合上面的规则，你可以按以下步骤排查：

1. 确认虚拟目录是否为"应用程序"：打开IIS管理器，右键你的MyWCF_Service_On_IIS虚拟目录，如果看到"转换为应用程序"的选项，说明它还只是普通虚拟目录，不是应用程序。WCF服务必须作为应用程序运行才能被正确解析，点击这个选项，选择对应的应用程序池（或新建）即可。
2. 检查应用程序池的.NET版本：如果你的WCF是用.NET Framework 4.x开发的，应用程序池的.NET CLR版本必须设置为v4.0.x，托管模式建议选集成（经典模式下需要手动配置WCF的处理程序映射，容易出问题）。
3. 验证物理路径权限：右键c:\inetpub\wwwroot\MyWCF_Service_On_IIS\，选择「属性」→「安全」，添加IIS AppPool\DefaultAppPool用户，给它分配「读取和执行」「列出文件夹内容」「读取」权限。
4. 检查.svc处理程序映射：在IIS的虚拟目录配置里，找到「处理程序映射」，看是否存在.svc对应的映射规则。如果没有，说明你没安装WCF的IIS激活组件——去「控制面板→程序→启用或关闭Windows功能」里，找到「WCF服务」下的「HTTP激活」并勾选安装。
5. 测试基础路径：先访问localhost/MyWCF_Service_On_IIS/，如果启用了目录浏览，应该能看到物理路径下的文件列表；如果没启用，会返回403。如果连这个基础路径都访问不了，那肯定是映射或权限的问题。

三、额外提示 #

• 就算你的WCF没配置元数据端点，访问.svc文件时也应该显示一个提示页面（告诉你需要启用元数据才能查看服务详情）。如果连这个页面都没出现，说明IIS根本没正确解析.svc请求，大概率是处理程序映射的问题。
• 可以查看IIS的日志文件（默认路径c:\inetpub\logs\LogFiles\W3SVC1），里面会有具体的错误代码（比如404.3表示没有对应的处理程序），能帮你快速定位问题根源。

内容的提问来源于stack exchange，提问作者Booji Boy