将ASP.NET Core以应用程序（而非站点）形式部署并运行于IIS

我之前在部署ASP.NET Core子应用时也碰到过一模一样的502问题，这种情况大多是Kestrel进程启动失败或者IIS与应用的通信链路出了问题，咱们一步步拆解排查：

1. 先看日志！找到具体错误根源 #

502只是个表面错误，ASP.NET Core自带的stdout日志能帮你定位真实问题。修改子应用目录下的web.config，开启日志：

<aspNetCore 
  processPath="dotnet" 
  arguments=".\YourApp1.dll" 
  stdoutLogEnabled="true" 
  stdoutLogDir=".\logs" 
  hostingModel="inprocess" />

保存后重新访问http://myapplication.net/app1，然后去子应用目录下的logs文件夹看生成的日志文件——里面会明确告诉你是权限不足、DLL缺失还是路径配置错误。

2. 配置路径基址（Path Base） #

当应用作为子部署在/app1路径下时，ASP.NET Core默认不知道自己处于子路径，会导致路由、静态资源等请求匹配失败，甚至启动报错。有两种解决方式：

方式一：代码中配置 #

在Program.cs里添加路径基址设置：

var builder = WebApplication.CreateBuilder(args);
// 其他服务配置...

var app = builder.Build();

// 关键：告诉应用它的根路径是/app1
app.UsePathBase("/app1");

// 后续中间件（路由、静态文件等）...
app.Run();

方式二：通过web.config传递参数（无需改代码） #

修改web.config的arguments，加上--path-base /app1：

<aspNetCore 
  processPath="dotnet" 
  arguments=".\YourApp1.dll --path-base /app1" 
  stdoutLogEnabled="true" 
  stdoutLogDir=".\logs" 
  hostingModel="inprocess" />

3. 检查权限是否到位 #

虽然你已经给了应用池权限，但要确认：

• 子应用的根目录（包含web.config的那个文件夹）是否给IIS AppPool\myapplicationpool分配了「读取和执行」「列出文件夹内容」「读取」权限；
• 日志目录（logs）是否给应用池账号分配了「写入」权限；
• 如果应用用到了本地文件存储（比如上传目录），也要确保对应目录有写入权限。

4. 确认应用池配置正确 #

子应用的应用池必须满足：

• .NET CLR版本设置为「无托管代码」（因为ASP.NET Core是自托管的，不需要IIS托管）；
• 应用池的身份权限足够（如果用的是默认的ApplicationPoolIdentity，那之前的权限配置就没问题；如果是自定义账号，要确保账号有对应目录权限）；
• 子应用的物理路径必须指向包含web.config的发布目录，不要指向wwwroot子文件夹。

5. 排查Kestrel启动失败的其他可能 #

• Runtime版本不匹配：服务器上必须安装和应用发布时目标框架一致的.NET Core Runtime（比如应用是.NET 6，服务器就得装.NET 6 Runtime）。如果不想依赖服务器的Runtime，可以选择「自包含」模式发布（发布时勾选自包含，会把Runtime一起打包）；
• 端口或进程冲突：虽然子应用用的是IIS反向代理，Kestrel端口由ASP.NET Core模块动态分配，但如果服务器上有防火墙限制，或者其他进程占用了相关资源，也可能导致启动失败——不过这种情况日志里会明确提示。

总结 #

完全可以实现同一个站点下部署多个ASP.NET Core子应用（/app1、/app2...），我自己就部署过好几个。核心是先通过stdout日志找到真实错误，再针对性解决路径基址、权限或应用池的问题。

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