多子项目IIS部署异常：ASP.NET认证功能失效求助

兄弟，我之前部署多项目ASP.NET解决方案到IIS的时候也踩过一模一样的坑——VS里跑的好好的，一到IIS就各种功能失效。结合你的情况，按下面的步骤排查，应该能快速定位问题：

• 确保site、api、auth三个项目对应的应用程序池都使用集成模式，并且.NET版本和你项目的目标框架完全匹配（比如项目用的是.NET Framework 4.8，池就不能选.NET 6）。VS自带的IIS Express会自动适配，但手动部署很容易在这里出错。
• 检查应用程序池的标识权限：如果你的auth或api项目需要访问数据库、文件系统，默认的ApplicationPoolIdentity可能没有足够权限。可以临时改成LocalSystem测试（测试完记得改回更安全的标识），或者给C:\inetpub\wwwroot\prj目录添加对应池标识的读写权限。

你现在只配置了指向site的网站，但api和auth不能只当普通文件夹处理，必须转成IIS应用程序：

• 打开IIS管理器，找到你的site站点，右键点击api文件夹，选择「转换为应用程序」，关联到和api项目匹配的应用程序池。同理处理auth文件夹。
• 确认每个应用程序的虚拟路径：api的虚拟路径要设为/api，auth设为/auth——这样前端调用接口时的路径才会正确映射到对应的ASP.NET路由逻辑，而不是被当成静态文件处理。

因为site是前端页面，调用auth/api接口时很容易遇到跨域或地址错误的问题：

• 检查auth项目的CORS配置：VS里可能默认允许了本地所有地址，但部署到IIS后，要明确允许http://localhost（或你实际使用的域名）访问。比如在Startup.cs里的配置要类似：

  services.AddCors(options =>
  {
      options.AddPolicy("AllowLocalSite",
          builder => builder.WithOrigins("http://localhost")
                            .AllowAnyMethod()
                            .AllowAnyHeader());
  });
  

  并且要确保app.UseCors("AllowLocalSite");的位置在UseRouting()之后、UseAuthorization()之前，顺序错了会直接失效。
• 检查前端login页面的表单提交地址：别用VS调试时的硬编码端口（比如https://localhost:5001/auth/login），要改成相对路径/auth/login，这样才能正确指向IIS里的auth应用程序。

ASP.NET的中间件顺序是核心，部署后可能因为配置文件差异导致顺序错乱：

• 检查auth项目的Startup.cs（或Program.cs，.NET Core/6+）：UseAuthentication()必须在UseAuthorization()之前，而且要放在UseRouting()之后——顺序反了的话，认证逻辑根本不会触发。
• 确认MVC项目的路由配置：确保login页面的表单提交动作指向正确的auth接口，比如action="/auth/Login"，避免相对路径导致的接口地址错误。

如果上面的检查都没问题，就得靠日志找具体问题：

• 启用IIS的失败请求跟踪：在站点级别开启这个功能，重现认证失败的操作后，生成的跟踪日志会详细展示请求的每一步（比如哪个模块报错、是权限问题还是路由匹配失败）。
• 查看Windows事件查看器：在「应用程序」日志里找ASP.NET相关的错误记录，比如未处理的异常、数据库连接失败等。
• 在auth/api项目里添加详细日志：用Serilog或NLog把认证过程的关键步骤输出到本地文件，看看是请求根本没到达auth接口，还是接口内部抛出了未捕获的错误。

内容的提问来源于stack exchange，提问作者J.Doe