在单个Azure App Service部署ASP.NET应用：如何让虚拟应用加载自身Web.config

我之前也碰到过一模一样的问题——把站点设为根应用后，子虚拟应用的API总是去读根的Web.config，这本质上是IIS默认的配置继承机制在搞鬼。下面是几个亲测有效的解决步骤：

1. 在根应用的Web.config中限制配置继承 #

这是最关键的一步，我们可以通过<location>节点明确告诉IIS：根应用的核心配置不要被子虚拟应用继承。

打开根应用的Web.config，在<configuration>节点下添加如下配置：

<configuration>
    <!-- 根应用原有的其他配置 -->

    <!-- 阻止子虚拟应用继承当前节点下的配置 -->
    <location path="." inheritInChildApplications="false">
        <system.web>
            <!-- 这里放根应用的system.web相关配置，比如authentication、compilation等 -->
        </system.web>
        <system.webServer>
            <!-- 这里放根应用的system.webServer相关配置，比如handlers、modules等 -->
        </system.webServer>
        <!-- 其他需要隔离的配置段也可以放在这里，比如appSettings、connectionStrings -->
    </location>
</configuration>

inheritInChildApplications="false"这个属性会让该<location>节点内的所有配置仅作用于根应用，子虚拟应用会完全忽略这些配置，转而加载自己Web.config里的内容。

2. 确认虚拟应用的物理路径与配置完整性 #

在Azure Portal的App Service配置页面，进入配置 > 路径映射，检查虚拟应用的设置：

• 确保虚拟应用的物理路径指向独立的文件夹（比如site\wwwroot\api），不要和根应用的site\wwwroot重叠；
• 部署API项目时，要保证它的完整文件（包括自己的Web.config）都部署到了这个物理路径下，没有被根应用的部署文件覆盖。

3. 必要时在虚拟应用的Web.config中清除继承配置 #

如果还有个别配置段被意外继承（比如某些handler或module），可以在API的Web.config里用<clear />或<remove />来清除这些继承的配置，然后重新注册自己的配置项。

比如在API的system.webServer/handlers节点中清除所有继承的handler，再注册自己的：

<system.webServer>
    <handlers>
        <clear />
        <!-- 注册API自己的handler，比如ASP.NET Core的模块 -->
        <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
    </handlers>
</system.webServer>

4. 特殊场景：不同.NET版本的应用隔离 #

如果你的根应用和API用了不同的.NET版本（比如根是.NET Core，API是.NET Framework），除了上面的配置，还需要给虚拟应用配置独立的应用程序池：
在Azure Portal的路径映射设置中，给API虚拟应用指定一个新的应用程序池，设置对应的.NET版本和托管管道模式，确保两个应用的运行环境完全隔离。

按照这些步骤操作后，你的API虚拟应用应该就能正常加载自己的Web.config，和根应用独立运行了。

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