.NET Core独立部署（Self Contained）在IIS中运行异常求助

先给你吃个定心丸——这个问题我之前也踩过坑，大概率是对SCD在IIS上的运行逻辑理解有偏差，或者发布/配置环节有疏漏，咱们一步步排查：

1. 先澄清一个关键误区：SCD也需要ASP.NET Core Hosting Bundle #

很多人误以为自包含部署就完全不需要服务器上的任何.NET组件，其实不对：ASP.NET Core Module（Hosting Bundle里的核心组件）是必须的，它负责把IIS的请求转发给.NET Core的Kestrel进程，不管你是SCD还是框架依赖部署（FDD）。所以你装了Hosting Bundle后能正常运行，这部分是合理的，但你疑惑的“为啥还需要Runtime”，大概率是发布包或IIS配置的问题。

2. 先确认你的发布包是真正的完整SCD #

先去你发布的文件夹里检查这几点：

• 有没有和项目同名的可执行文件（.exe）？比如mywebsite.exe——这是SCD的核心标识，框架依赖部署只有.dll
• 文件夹里是不是有一大堆Runtime相关文件？比如coreclr.dll、各种System.*.dll，还有win10-x64的native文件，这些都是自包含的Runtime文件
• 打开runtimeconfig.json看看，SCD的配置里虽然会有framework节点，但发布包已经包含了所有需要的Runtime文件，不需要系统安装的Runtime

快速验证方法：直接双击那个.exe文件，看能不能正常启动（会弹出控制台，显示Kestrel启动的日志）。如果能启动，说明发布包本身没问题，问题出在IIS配置上；如果不能启动，那就是发布过程有问题。

3. 排查IIS的核心配置问题（HTTP 500.19的常见原因） #

500.19错误通常是IIS配置或权限问题，重点检查这几点：

• web.config里的aspNetCore节点：一定要确保processPath指向你的.exe文件，而不是.dll！比如：

  <aspNetCore processPath=".\mywebsite.exe" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="InProcess" />
  

  如果指向的是.dll，IIS会尝试用系统安装的Runtime来运行，这就会要求你安装Runtime——这很可能是你的问题！
• 应用程序池设置：把应用程序池的**.NET CLR版本设置为无托管代码**，因为.NET Core应用不依赖IIS的传统托管CLR
• 物理路径权限：确保应用程序池的身份（比如IIS AppPool\你的站点名）有发布文件夹的读取+执行权限

4. 关于你提到的'l1-1-0'版本疑惑 #

你怀疑的版本号问题，可能是混淆了SDK版本和Runtime版本：你的dotnet SDK是2.1.500，对应的Runtime版本是2.1.12左右（SDK和Runtime版本不是严格一一对应，SDK会包含特定版本的Runtime）。你可以去发布包的shared/Microsoft.NETCore.App文件夹里查看实际的Runtime版本，或者用dotnet --info命令查看本地的Runtime版本。如果版本不符，可能是发布时缓存了旧文件，或者参数指定有误。

5. 重新发布的正确姿势 #

建议你删除旧的发布文件夹，用完整的参数重新发布，避免缓存干扰：

dotnet publish "mydirectory\mywebsite.csproj" --self-contained true --framework netcoreapp2.1 -r win10-x64 -c Release -o "D:\MyPublishedSite"

• 明确加上--self-contained true（虽然默认是true，但写清楚更保险）
• 用-o指定单独的输出路径，避免和旧文件混合
• 你的csproj里的<RuntimeIdentifiers>win10-x64</RuntimeIdentifiers>是没问题的，单数<RuntimeIdentifier>也可以用，不影响

最后一步：查看详细日志 #

如果还是有问题，开启web.config里的stdout日志：把stdoutLogEnabled="true"，然后在发布文件夹里创建logs文件夹，之后访问站点，查看logs里的日志文件，里面会有更详细的错误信息，帮你精准定位问题。

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