The hosting architecture of ASP.NET Core has changed significantly compared to the previous version. In this video, examine the three major choices you'll need to make for your application: which framework to build against, which server to choose, and how to expose that server to the internet.
- [Instructor] In previous versions of ASP.NET, your options were limited to Windows and iOS server. With ASP.NET Core, you have many more options for how to build and host your applications. There are three main choices you'll need to make for your application. Which framework to build against, which server to host with, and also how to expose that server to handle internet traffic. ASP.NET Core can run on a full .NET framework or on .NET Core. .NET framework is Windows only while .NET Core is cross platform.
If you need to maintain compatibility with older code or older libraries written for .NET, you may need to use the full .NET framework and your application will be limited to only running on Windows. Otherwise, using .NET Core will mean that you have the option of running your application on Windows, Linux, inside a Docker container, or elsewhere. .NET Core also contains some extra optimizations that help ASP.NET applications run really fast. I'd recommend using .NET Core unless you specifically have legacy code that only runs on .NET framework.
ASP.NET Core applications themselves run as a self-contained process with the help of a server library. If you've developed self-hosted OWIN applications in the past with ASP.NET, you'll find this pattern familiar. The server itself contains the code that translates raw HTTP requests into the structures that ASP.NET Core is looking for. ASP.NET Core 2.0 and later ships with two different servers. HTTP.sys and Kestrel. HTTP.sys is Windows only server while Kestrel is cross platform and runs on Windows, Mac, or Linux.
HTTP.sys includes a couple of features that Kestrel doesn't have like Windows authentication. Consider using HTTP.sys if you exclusively run on Windows servers and need these additional features. The ASP.NET Core documentation outlines all the features that HTTP.sys supports. For most projects though, Kestrel is the best choice. It's been highly optimized and it's incredibly fast. When you create a new project from the built-in templates in Visual Studio or the .NET cli, you get Kestrel by default.
Both Kestrel and HTTP.sys can serve traffic directly, sometimes called acting as an edge server, or sit behind a load balancer or reverse proxy. Which configuration and architectural model you choose depends on the needs of your application. If you have a simple application and a single server, you can tell the server to listen on port 80 and connect it directly to internet traffic. In this scenario, you need to add a certificate to Kestrel or HTTP.sys to enable HTTPS. Running an edge server like this could make it hard to scale later because you don't have any way to balance load and send traffic to another server.
Another approach is to put your server behind a reverse proxy like IIS or Nginx. The reverse proxy can act as a load balancer and it also acts as a single place to configure certificates for HTTPS even if you have multiple servers behind the proxy. I'll demonstrate this approach in this course, but you can find instructions for either scenario in the ASP.NET Core documentation. The next step is to decide on a deployment strategy for getting your application code onto the server machine itself.
- Setting up your ASP.NET project
- Choosing a deployment strategy
- Configuring HTTPS and forwarding
- Deploying to IIS
- Deploying to Azure
- Deploying to Linux
- Deploying with Docker