Aspnetcore.docs: ASP.NET Core project templates use Kestrel by default. In Program.cs, the app calls ConfigureWebHostDefaults, which calls UseKestrel behind the scenes.

[Rick-Anderson]

See How to use Kestrel in ASP.NET Core apps

ASP.NET Core project templates use Kestrel by default. In Program.cs, the app calls ConfigureWebHostDefaults, which calls UseKestrel behind the scenes.

Isn't UseKestrel the default config? You don't need to change the the ConfigureWebHostDefaults call to use IIS or HTTY sys, you change config. -- Right?

@guardrex please comment. cc @serpent5

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: f22dcddb-0c25-be1a-9a02-9e71dce86bdb
• Version Independent ID: 3e0e12c2-e544-5655-e001-d2ec180b11a8
• Content: Kestrel web server implementation in ASP.NET Core
• Content Source: aspnetcore/fundamentals/servers/kestrel.md
• Product: aspnet-core
• Technology: aspnetcore-fundamentals
• GitHub Login: @guardrex
• Microsoft Alias: riande

[guardrex]

I don't quite follow the question ... Kestrel and IIS Integration are provided via calls behind ConfigureWebHostDefaults, but not HTTP.sys. If you trace it out, you come out here ...

https://github.com/aspnet/AspNetCore/blob/1480b998660d2f77d0605376eefab6a83474ce07/src/DefaultBuilder/src/WebHost.cs#L217

... and for IIS bits, a little further down ... here ...

https://github.com/aspnet/AspNetCore/blob/1480b998660d2f77d0605376eefab6a83474ce07/src/DefaultBuilder/src/WebHost.cs#L256-L257

Are you saying that you'd like the topic to also show a more manual host set up that doesn't call ConfigureWebHostDefaults and thus ends up literally calling UseKestrel? It's not the happy path, but it could be shown, of course.

Otherwise, maybe "How to" should be taken off of the section title. It's more like just _use it_ given that we rely on the magic bits ✨.

Yeah ... I wouldn't call this a doc-bug tho. AFAIK, the coverage is good. It's been thoroughly reviewed by engineering.

Last bit ... HTTP.sys ... the set up is here :point_right: https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/httpsys?view=aspnetcore-3.0#configure-the-aspnet-core-app-to-use-httpsys

[Rick-Anderson]

@guardrex much simpler. I'm saying the following:
ASP.NET Core project templates use Kestrel by default. In Program.cs, the app calls ConfigureWebHostDefaults, which calls UseKestrel behind the scenes.

SHould be changed to

ASP.NET Core project templates use Kestrel by default. In Program.cs, the app calls ConfigureWebHostDefaults, which BY DEFAULT calls UseKestrel behind the scenes.

But even ASP.NET Core project templates use Kestrel by default. is not correct. The same templates run from VS use IIS Express.

[Rick-Anderson]

I want to make How to use Kestrel in ASP.NET Core apps consistent for the 85% who use IIS Express from VS. What's written there doesn't make sense for that use case.

[guardrex]

That's cool, except that this is just the Kestrel topic. It's really quite heavily focused on the OOB ... no IIS ... basic CLI tooling ... way of the world.

OOB ... dotnet run the template, you get Kestrel. There's no IIS/Express there to integrate.

These topics were written to compartmentalize things quite a bit. The incremental improvement might be worth it ... or not ... hard to say. The statement is accurate in the simplest case tho.

I want to make How to use Kestrel in ASP.NET Core apps consistent for the 85% who use IIS Express from VS. What's written there doesn't make sense for that use case.

I have a concern about that ... again, based on the xplat/xtooling scenarios involved. Engineering probably will shed helpful light on it tho. I'm just remarking from the historical perspective on why these topics adopted their current approach.

[Rick-Anderson]

What about
ASP.NET Core project templates use Kestrel by default. In Program.cs, the app calls ConfigureWebHostDefaults, which BY DEFAULT calls UseKestrel behind the scenes.

[serpent5]

ConfigureWebHostDefaults will _always_ call UseKestrel (source). It'll also call UseIIS and UseIISIntegration (source). The magic seems to be in those IIS methods detecting if IIS is running and replacing the IServer implementation in DI accordingly (among other services, it seems).

[guardrex]

Always "call," yes. Always "use," no ... depends on what the dev picks (e.g., HTTP.sys server).

That's correct @serpent5. All the juicy details (most of them anyway) are over at https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/iis/?view=aspnetcore-3.0#in-process-hosting-model.

[guardrex]

Just again from the historical perspective here ...

All of the server, host, publish, and deployment topics have been written and maintained to compartmentalize things fairly strictly. It was done (fair enough to say 'by me' ... I guess with engineering's blessings lol) ... it was done because we're so xplat/xtooling these days. It virtually demands that each subject area take most of its own set up and config explanations unto itself.

The good question here that you're asking I think is how to handle those first few contact docs ... extensions ... fundamentals.

This is why I say today that the host coverage isn't so good. I pitched right at the start ... and thought that engineering was on-board with it ... to have _one_ Host topic. The current Web Host topic goes off to Advanced or someplace to die ⚰️. The IWebHostBuilder bits that we need to keep under the Generic Host are in that topic ... in a section dedicated to the Web Host living inside of the Generic Host. All of the chat today about "switching" and "depreciated" for the Web Host ... well :smile: ... IWebHostBuilder ... still there ... still kick'in.

But final word on the server stuff ...

A reader needs to figure out what tech they want to use, then engage the docs exactly in those areas. The high level docs are rather general ... often speak to base/default scenarios (e.g., dotnet run a template from CLI). The dirty details are in each topic down in the TOC.

[Rick-Anderson]

See https://github.com/aspnet/AspNetCore/issues/13145