Why it is needed to remove then add the aspNetCore handler for sub application?

[Kimserey]

In order to make ASP.NET Core sub application of another ASP.NET Core application accessible, the web.config must remove then add the aspNetCore.

<system.webServer>
  <handlers>
    <remove name="aspNetCore"/>
    <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified" />
  </handlers>
  <aspNetCore processPath="dotnet" arguments=".\HelloWorld.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout">
  </aspNetCore>
</system.webServer>

If the handler is not removed, I will get a 500 internal error while if the handler is removed without adding back aspNetCore after, I would get a 403 Forbidden access.

I did not find any explanation in the documentation. Could someone provide details on why it is needed remove then add the aspNetCore handler?

[Tratcher]

https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/?tabs=aspnetcore2x#sub-application-configuration

Because web.config settings are inherited from from the root application to sub applications, and adding the handler twice isn't allowed by IIS.

[Kimserey]

Could you just confirm my understanding, it is because to be able to add the aspNetCore pointing to the dll for my sub-application, here .\helloWorld.dll, I need to remove the parent (inherited aspNetCore handler originally pointing to the dll of the parent application) then add the module for my current application.

Is that the way the configuration works?

What I missed from the documentation is something pointing me to "If your parent is an ASP.NET Core application, you must remove then add back the aspNetCore module" or something equivalent.

[Tratcher]

Not exactly, your dll isn't in the handlers section. IIS just doesn't want any two registered handlers to use the same name. The remove and re-add pattern is the verbose, foolproof version that should work in any scenario. The docs have simpler versions that either remove or skip adding the handler as needed for specific scenarios.

[Kimserey]

The docs have simpler versions that either remove or skip adding the handler as needed for specific scenarios.

None of the two solutions in the documentation work for hosting an ASP.NET Core sub application under another ASP.NET Core application.

1. The following config yield a 403 forbidden:

<system.webServer>
  <aspNetCore processPath="dotnet" arguments=".\HelloWorld.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout">
  </aspNetCore>
</system.webServer>

2. The following config also yield a 403 forbidden:

<system.webServer>
  <handlers>  
    <remove name="aspNetCore"/>
  </handlers>
  <aspNetCore processPath="dotnet" arguments=".\HelloWorld.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout">
  </aspNetCore>
</system.webServer>

3. The following config yield a 500 Internal server error:

<system.webServer>
  <handlers>
    <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModule" resourceType="Unspecified"/>
  </handlers>
  <aspNetCore processPath="dotnet" arguments=".\HelloWorld.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout">
  </aspNetCore>
</system.webServer>

Only removing and adding together would make it work. So I am trying to understand what is the logic and how does it work?

IIS just doesn't want any two registered handlers to use the same name

If this is the case, shouldn't 1 be working then?

[Tratcher]

Yes, case 1 should work. @jkotalik, @pan-wang?

[pan-wang]

case 1 should work. I just tested with my app.
The recommendation is to use "location" tage with setting inheritInChildApplications=" false" as discussed in https://stackoverflow.com/questions/782252/avoid-web-config-inheritance-in-child-web-application-using-inheritinchildapplic. I am pushing this setting as part of web.config template

[Kimserey]

Thanks for the confirmation! I just re-tested and it actually works as expected. Not sure where I somehow saw the 403 forbidden. Thanks!