你遇到的这个0x8007000d错误，本质是IIS无法识别或解析web.config里的配置节点，结合.NET Core部署IIS的场景，我给你梳理一套从基础到进阶的排查步骤，应该能帮你定位问题：

一、先确认核心依赖是否安装到位 #

这个是最容易踩坑的点，很多人会忽略：

• 必须安装对应版本的.NET Core Hosting Bundle：它包含了.NET Core Runtime和关键的AspNetCoreModule（ANCM），IIS就是靠这个模块来托管.NET Core应用的。如果只装了SDK没装Hosting Bundle，IIS根本认不出web.config里的<aspNetCore>节点，直接报0x8007000d。安装后一定要重启IIS（命令行敲iisreset生效）。
• 检查Windows功能里的ASP.NET Core模块：去「控制面板→程序→启用或关闭Windows功能」，找到Internet Information Services→万维网服务→应用程序开发功能，确认「ASP.NET Core 模块」（对应.NET Core 2.x/3.x可能是v2版本）已经勾选。

二、核对web.config的细节配置 #

你的web.config结构没问题，但几个关键参数要仔细核对：

• processPath="dotnet"：如果服务器上dotnet命令不在系统环境变量里，或者装了多个.NET版本，建议写绝对路径，比如C:\Program Files\dotnet\dotnet.exe，避免IIS找不到dotnet执行文件。
• arguments=".\DishbooksAPI.dll"：确认这个DLL的路径是相对于网站根目录的，比如你发布后DLL在根目录就没问题，如果在子文件夹（比如bin），要改成.\bin\DishbooksAPI.dll。
• 开启stdout日志：把stdoutLogEnabled="false"改成true，然后在网站根目录手动创建logs文件夹，给应用程序池标识分配读写权限。重启站点后访问，去logs文件夹看日志，里面会有.NET Core应用启动的详细错误信息，这往往能直接定位问题（比如依赖缺失、appsettings.json配置错误）。

三、应用程序池的硬性配置要求 #

• .NET CLR版本必须设为「无托管代码」：这是.NET Core部署IIS的强制要求，因为.NET Core不依赖IIS的托管CLR环境，要是选了其他版本，肯定会出配置解析错误。
• 权限测试：如果怀疑是权限问题，可以临时把应用程序池的标识改成「LocalSystem」（最高权限），测试能不能正常访问。如果能，再调回ApplicationPoolIdentity并给网站目录、数据库等配置对应权限。

四、直接测试应用本身是否能运行 #

在服务器上打开命令行，切换到网站根目录，直接运行dotnet DishbooksAPI.dll：

• 如果命令行能正常启动应用，并且能通过http://localhost:端口访问，说明问题出在IIS和ANCM的交互上，回到前面的模块安装、web.config配置排查。
• 如果命令行启动报错，那就是应用本身的问题（比如缺失依赖包、appsettings.json里的连接字符串错误），先解决这个问题再部署到IIS。

五、进阶排查：检查applicationHost.config #

如果上面的步骤都试过还是不行，可以去IIS的全局配置文件C:\Windows\System32\inetsrv\config\applicationHost.config里检查：

• 确认里面注册了AspNetCoreModule，比如：

<globalModules>
  <add name="AspNetCoreModuleV2" image="%ProgramFiles%\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll" />
</globalModules>

• 检查站点对应的应用程序池配置，有没有冲突的模块或配置节点。

按照这个顺序排查，应该能找到问题所在，重点推荐先开stdout日志，很多时候看似是IIS的错误，实际是应用启动时的内部问题。

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