ASP.NET Core如何部署同解决方案下的Razor与API项目

你已经在解决方案内拆分出公共Model、Repository层的前提下，把API项目放在同一个解决方案下是当前阶段的最优选择，远好于单独新建解决方案开发：

• 公共层引用无额外成本：不需要把Model、Repository打包成私有NuGet包做跨解决方案调用，直接通过项目引用关联Web和API项目，彻底避免两边引用的公共逻辑出现版本错位的问题——后续修改Repository层的业务校验规则时，Web端和API端能同步拿到最新逻辑，不会出现两个入口行为不一致的问题
• 统一版本管控：所有关联项目的迭代节奏可以对齐，比如要做字段调整、业务规则更新，在同一个解决方案里一次改完全量编译验证，不用来回切换解决方案同步代码
• 只有满足以下条件时，才值得拆成独立解决方案：API要交给完全独立的团队维护、迭代节奏和Web端完全脱钩、未来要独立部署到不同的服务器集群且配置差异极大，否则同解决方案的维护成本最低

你已经排查过web.config配置问题的前提下，90%以上的报错都来自这几个点：

• 托管组件版本不匹配：服务器上安装的ASP.NET Core 3.1托管捆绑包版本不对，很多老服务器上之前只装过2.1或者5.0以上版本的托管包，in-process模式下模块加载失败就会直接返回500.0；需要注意安装完对应3.1版本的托管组件后，必须手动重启W3SVC服务，不能只重启应用池
• 应用池配置冲突：部署API的子域名对应的应用池，没有选择「无托管代码」的.NET CLR版本配置，或者直接复用了原有Razor主站的应用池——两个ASP.NET Core应用同时在同一个应用池跑in-process托管时，很容易出现模块加载、内存隔离的冲突，必须给每个独立站点配置专属的应用池
• 应用启动阶段异常：in-process模式下，应用如果在启动阶段抛错（比如数据库连接串配置错误、依赖注入的服务解析失败、硬编码的固定端口和IIS绑定冲突），不会返回详细的异常信息，只会抛出通用的500.0错误
• 快速定位技巧：
  • 先做模式切换验证：临时在web.config的aspNetCore节点里把hostingModel改成OutOfProcess，如果切换后站点能正常访问，就可以确定是in-process模式下的组件加载、应用池配置问题
  • 开启日志定位真实异常：配置stdoutLogEnabled="true"、stdoutLogFile=.\logs\stdout，重新发起请求后就能在日志文件里看到完整的启动异常栈，排查效率比手动核对配置高很多

针对你当前解决方案里包含Razor主站、API两个独立对外站点的场景，正确的部署流程是：

• 每个项目单独发布配置：分别对Razor主站、API项目执行发布操作，单独选定每个项目的输出目录，不要把所有项目的文件混在同一个发布包里——比如API的发布包里不需要包含主站的视图文件、前端静态资源，主站的发布包里也不需要带API的控制器逻辑文件
• IIS站点绑定规则：两个站点分别绑定独立的域名（比如主站对应www.xxx.com，API对应api.xxx.com），分别指向各自的物理文件目录，不要在同一个站点下通过虚拟目录的形式部署API，这种结构下in-process托管的冲突概率极高
• 权限配置：给两个站点的物理目录分别配置应用池对应的独立用户读取权限，不要交叉引用目录文件，避免因为权限不足导致的程序集加载失败

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