如何解决跨两个Web API/域的Microsoft.AspNetCore.Routing.Matching.AmbiguousMatchException

可能的根因 #

两个独立Web App出现对方控制器的路由冲突，核心原因是当前Web App的运行环境中加载了另一个服务的程序集，导致ASP.NET Core的路由系统扫描到了重复的根路径端点。具体可能场景：

• 部署包混入其他服务程序集：CI/CD流程出错，将两个服务的dll打包到同一部署包，部署后Web App加载了不属于自身的控制器。
• 共享存储/部署槽污染：两个Web App使用了共享文件存储（如同一Azure Storage挂载到wwwroot），或部署槽配置错误，导致程序集互相覆盖或加载。
• 错误的控制器扫描配置：服务的Startup/Program.cs中，误将另一个服务的程序集添加为控制器扫描范围。
• 程序集名称冲突：两个服务的程序集名称重复，部署时未正确覆盖，导致多个同名程序集被加载。

排查与解决步骤 #

1. 检查Web App部署目录
   登录Azure Portal，进入目标Web App的「高级工具」→「Kudu」→「调试控制台」→「站点/wwwroot/bin」，查看是否存在不属于当前服务的dll（比如Access服务的bin目录出现Migration服务的程序集）。若有，删除多余程序集并重新部署。

2. 验证CI/CD打包流程
   检查部署脚本（如Azure DevOps Pipeline、GitHub Actions），确认打包步骤仅包含当前服务的项目输出，未引入其他服务文件。比如在dotnet publish命令中，确保指定了正确的项目文件，无通配符错误包含其他项目。

3. 检查控制器扫描配置
   打开服务的Program.cs/Startup.cs，查看控制器注册代码：

   builder.Services.AddControllers()
       // 检查是否存在错误添加其他服务的ApplicationPart
       // .AddApplicationPart(Assembly.Load("其他服务的程序集名称"));
   

   若有错误的AddApplicationPart调用，直接删除即可。

4. 检查存储与部署槽配置
   确认两个Web App未共享同一Azure Files存储或部署槽，避免文件互相污染。若使用了共享存储，改为各自独立的存储资源。

5. 临时应急方案
   若需快速恢复服务，修改其中一个服务的AlwaysOn路由，将根路径改为特定路径：

   [HttpGet]
   [Route("/always-on")] // 替换原有的[Route("/")]
   public void AccessAlwaysOn()
   {
       // Root Url is used by Azure's "Always on" feature.
   }
   

   同时更新Azure Portal中对应Web App的「始终启用」配置，将检测路径改为新地址。

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