Change to IIS hosting model

[DamianEdwards]

Background

Up to and including beta7, ASP.NET 5 applications run in IIS have been hosted by a component named "Helios", contained in the Microsoft.AspNet.Server.IIS package. This component facilitated the bootstrapping of the DNX and subsequently the .NET CLR or Core CLR by way of utilizing a hook in the existing System.Web hosting model to replace the runtime after the application had started (from IIS's point of view).

This effectively made "Helios" a second DNX host, meaning it contained its own logic pertaining to locating, booting, and loading the runtime. It also meant a second set of logic to enable things like runtime servicing, as well as configuration of certain DNX-level settings.

What's changing?

In beta8, we're discontinuing the "Helios" IIS host. Hosting ASP.NET 5 applications in IIS will now be achieved using the IIS HttpPlatformHandler configured to forward through to the ASP.NET 5 Kestrel server. This native IIS module, manages the launching of an external application host process (in this case dnx.exe) and the routing of requests from IIS to the hosted process.

Our default templates, Visual Studio tooling, and Azure deployment stories, will be updated to reflect this change.

Note that as the HttpPlatformHandler is an IIS native module, it needs to be installed by an Administrator on the server running IIS. There will be an update to the module released to enable some new functionality (e.g. flowing of Windows authentication handles from IIS to the application host process) as well as support the module on Windows Server 2008 R2.

Why?

Having two distinct hosting models for ASP.NET 5 introduced a number of complexities and inconsistencies that were difficult or impossible to resolve.

Simplifying the model with a single host option (but the same scenarios still supported) means less things for developers to code for and test. And it's easier for us to build!

Some added benefits of this approach:

• The IIS AppPool doesn't need to run any managed code (you can literally configure it to not load the CLR at all)
• The existing ASP.NET Windows component does not need to be installed to run on Windows Servers
• Existing ASP.NET 4.x modules can run in IIS alongside the HttpPlatformHandler since the ASP.NET 5 process is separate
• You can set environment variables per process since HttpPlatformHandler supports it. It will make setting things like the ASP.NET 5 "environment" configuration possible on local IIS servers.
• Unified error handling for startup errors across all servers
• Code and behavior unification
  • Support for app.config when running on .NET Framework (full CLR) whether self-hosted or in IIS (no more web.config even for .NET Framework compatibility)
  • Unified servicing story
  • Unified boot-up story (no odd AspNetLoader.dll in the bin folder)

What won't work anymore?

• The HttpPlatformHandler currently does not forward client certs (this will be a future enhancement)
• The raw performance is lower than using Helios in-process, but in reality will likely not change the real-world performance of applications (i.e. you'll see differences in micro-benchmarks like "Hello World")

What about self-host on Windows?

The Microsoft.AspNet.Server.WebListener server will continue as an option for HTTP.SYS-based hosting on Windows machines for DNX applications. Additionally, traditional .NET Framework applications will be able to use Microsoft.Net.Http.Server in place of the built-in HttpListener API.

Of course, Kestrel can also be used as a self-host server for DNX applications on Windows.

Use this thread for questions, concerns & discussions