Asp.Net Core子应用由于配置中重复添加模块会引起IIS错误500.19

ASP.NET Core已经从IIS中解耦,可以作为自宿主程序运行,不再依赖IIS。

但我们还是需要强大的IIS作为前置服务器,IIS利用httpPlatformHandler模块来对后台的一些web服务器进行进程管理,比如Tomcat, Jetty, Node.exe, Ruby,当然还有dotnet,同时为它们代理分发网络请求。

httpPlatformHandler是通用的、闭源的,而且貌似迭代的很慢,半年了还停留在带着一个大BUG的v1.2,可能是由于这些原因吧,.NET小组从httpPlatformHandler分支出来一个专门针对dotnet的版本,改名为AspNetCoreModule并且准备把它开源,这样应该能更好地适应.NET Core的发展。

那么要使用IIS,则web.config是必须的,所以我们看到项目文件里的web.config是这样配置的:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified"/>
    </handlers>
    <aspNetCore processPath="dotnet" arguments=".\WebApplication6.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" />
  </system.webServer>
</configuration>

很好理解,<add ../> 添加了一个AspNetCoreModule模块,名字为"aspNetCore",后面的<aspNetCore .. /> 则对这个模块的必要参数进行简单配置。

这样就告诉了IIS,在处理这个站点/应用的时候,使用aspNetCore这个模块,而这个模块则会启动dotnet并分发请求。

不过,当我们在一个ASP.NET Core的站点下增加一个ASP.NET Core子应用的时候,

访问这个子应用会得到500.19错误:

HTTP 错误 500.19

错误代码:0x800700B7

配置错误:在唯一密钥属性“name”设置为“aspNetCore”时,无法添加类型为“add”的重复集合项

查看这个子应用程序的配置,无法显示system.webServer/handlers节点,提示的错误和上图500.19中的配置错误一致:

我们很容易想到,主站点的web.config里已经使用了"aspNetCore"这个名字,那么子应用就不能再用了。

试着修改subapp1的web.config,将"aspNetCore"随便改成其他的名字:

<add name="aspNetCore123" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />

这时再访问 /subapp1 就一切正常了。

但是这样改名字并不是一个正确的方法:

提示这种错误是IIS本身一个正常的行为,因为在“website”站点根目录的web.config里,已经用<add ../>添加了模块AspNetCoreModuel了,在子应用里实际上不再需要<add ../>来添加这个模块了,但是任然需要下面的<aspNetCore ../>来进行配置。

所以正确的做法是,在一个站点里,只在根目录web.config里保留<add ../>添加模块,其他子应用程序,都把这一节删除就可以了,即:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <aspNetCore processPath="dotnet" arguments=".\WebApplication6.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" />
  </system.webServer>
</configuration>

经@calvinK 提醒,更妥善的办法是先删除,再添加:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
   <handlers>
     <remove name="aspNetCore"/>
     <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
   </handlers>
   <aspNetCore processPath="dotnet" arguments=".\WebApplication6.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="false" />
  </system.webServer>
</configuration>

ps:可以加群 48082039 讨论C#,asp.net core相关话题。

时间: 2024-08-08 23:30:28

Asp.Net Core子应用由于配置中重复添加模块会引起IIS错误500.19的相关文章

Net Core子应用由于配置引起IIS错误500.19

Asp.Net Core子应用由于配置中重复添加模块会引起IIS错误500.19 ASP.NET Core已经从IIS中解耦,可以作为自宿主程序运行,不再依赖IIS. 但我们还是需要强大的IIS作为前置服务器,IIS利用httpPlatformHandler模块来对后台的一些web服务器进行进程管理,比如Tomcat, Jetty, Node.exe, Ruby,当然还有dotnet,同时为它们代理分发网络请求. httpPlatformHandler是通用的.闭源的,而且貌似迭代的很慢,半年了

[ASP.NET Core 3框架揭秘] 配置[5]:配置数据与数据源的实时同步

在<配置模型总体设计>介绍配置模型核心对象的时候,我们刻意回避了与配置同步相关的API,现在我们利用一个独立文章来专门讨论这个话题.配置的同步涉及到两个方面:第一,对原始的配置源实施监控并在其发生变化之后重新加载配置:第二,配置重新加载之后及时通知应用程序进而使应用能够及时使用最新的配置.要了解配置同步机制的实现原理,我们先得了解一下配置数据的流向. 一.配置数据流 通过前面的介绍,我们已经对配置模型有了充分的了解,处于核心地位的 IConfigurationBuilder对象借助注册的ICo

[ASP.NET Core 3框架揭秘] 配置[3]:配置模型总体设计

原文:[ASP.NET Core 3框架揭秘] 配置[3]:配置模型总体设计 在<读取配置数据>([上篇],[下篇])上面一节中,我们通过实例的方式演示了几种典型的配置读取方式,接下来我们从设计的维度来重写认识配置模型.配置的编程模型涉及到三个核心对象,分别通过三个对应的接口(IConfiguration.IConfigurationSource和IConfigurationBuilder)来表示.如果从设计层面来审视背后的配置模型,还缺少另一个名通过IConfigurationProvide

ASP.NET Core在Azure Kubernetes Service中的部署和管理

目录 ASP.NET Core在Azure Kubernetes Service中的部署和管理 目标 准备工作 注册 Azure 账户 AKS文档 进入Azure门户(控制台) 安装 Azure Cli 安装 Docker 进入正题 资源组 创建资源组 删除资源组 容器注册表 Azure Container Register (ACR) 创建 ACR 登录 ACR 服务主体 service principle 创建服务主体 给服务主体配置 ACR 的pull权限 K8s服务集群 Azure Ku

[ASP.NET Core 3框架揭秘] 配置[6]:多样化的配置源[上篇]

.NET Core采用的这个全新的配置模型的一个主要的特点就是对多种不同配置源的支持.我们可以将内存变量.命令行参数.环境变量和物理文件作为原始配置数据的来源.如果采用物理文件作为配置源,我们可以选择不同的格式(比如XML.JSON和INI等).如果这些默认支持的配置源形式还不能满足你的需求,我们还可以通过注册自定义IConfigurationSource的方式将其他形式数据作为配置来源. 一.MemoryConfigurationSource 在之前的实例演示都在使用MemoryConfigu

[ASP.NET Core 3框架揭秘] 配置[9]:自定义配置源

我们在前面对配置模型中默认提供的各种IConfigurationSource实现类型进行了深入详尽的介绍,如果它们依然不能满足项目中的需求,我们还可以通过自定义IConfigurationSource实现类型来支持我们希望的配置源.就配置数据的持久化方式来说,将配置存储在数据库中应该是一种常见的方式.接下来我们会创建一个针对数据库的IConfigurationSource实现类型,它采用Entity Framework Core来完成数据库的存取操作. 我们将这个自定义Configuration

关于 IIS 上运行 ASP.NET Core 站点的“HTTP 错误 500.19”错误

昨天回答了博问中的一个问题 —— “HTTP 错误 500.19 - Internal Server Error dotnetcore”,今天在这篇随笔中时候事后诸葛亮地小结一下. 服务器是 Windows Server 2008 R2 ,ASP.NET Core 版本是 2.1 ,错误信息如下: HTTP 错误 500.19 - Internal Server Error 无法访问请求的页面,因为该页的相关配置数据无效. 出现这个错误是由于 IIS 无法解析 Web.config 中的 xml

遭遇“HTTP 错误 500.19 无法访问请求的页面,因为该页的相关配置数据无效。”

windows 2008下IIS7 安装ASP.NET 遇到如下错误:  <!--[endif]--> HTTP 错误 500.19 - Internal Server Error 无法访问请求的页面,因为该页的相关配置数据无效. 详细错误信息模块 IIS Web Core 通知 BeginRequest 处理程序 尚未确定 错误代码 0x80070021 配置错误不能在此路径中使用此配置节.如果在父级别上锁定了该节,便会出现这种情况.锁定是默认设置的(overrideModeDefault=

IIS7 Asp.Net HTTP 错误 500.19 Internal Server Error

对网站进行访问时,提示如下错误: 出现"HTTP 错误 500.19" "Internal Server Error" 问题可能的原因如下: 1..Net安装.配置问题 参考:http://www.cnblogs.com/koeltp/archive/2012/02/08/2343394.html 2.网站目录权限问题 参考:http://blog.csdn.net/haoxueyi0507/article/details/6288877 3.Asp.Net注册问题